maps the executable to memory, and if an elf interpreter (/lib/ld-linux.so) is specified (which it normally is) also the elf interpreter.
It then jumps to the entry point of the raw binary or of the elf interpreter.
Its easy to sometimes conceptually think or talk about "a loader" as if its some standalone entity. However this can be misleading(at least to me anyway.) Because in reality its linked into every dynamically-linked binary, along with crt0.o which as the other poster mentioned takes care of some ABI requirements and the setting up of the stack.
For anyone else who might be interested this also an illuminating source code file to read, libc-start. Which would be part of crt0.o
http://repo.or.cz/glibc.git/blob/HEAD:/csu/libc-start.c#l105
I don't have to think this low level on any kind of regular basis but its a great thought exercise to do so from time to time.
I think your "normally" means "in case of dynamically linked executables".