Determine address of _dl_start - gdb

Question

I want to get the address of function _dl_start (entry point of the dynamic linker). I am able to set a breakpoint using gdb. I expected to find the symbol using readelf but I did not. How can I get the address / how does the gdb resolve _dl_start?
The example source (main.cpp) to set the breakpoint using the gdb is
int main( int argc, char** argv, char** envp )
{
return 0;
}
I compiled it with
g++ main.cpp -o teststart
The gdb output when running the program was
(gdb) b _dl_start
Function "_dl_start" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (_dl_start) pending.
(gdb) r
Starting program: /tmp/teststart
Breakpoint 1, 0x00007fa7ee8c4fc4 in _dl_start () from /lib64/ld-linux-x86-64.so.2

Answer 1

The _dl_start symbol is in ld-linux-x86-64.so.2 (the dynamic loader), and that symbol is private to ld-linux. This means that the only way to find it from inside the program is to do the same thing GDB does: read the symbol table of ld-linux, and search it for the "_dl_start" function (by name). Linking to it directly (as Martin suggested) can not and will not work (as you've already discovered).
Reading ELF symbol tables is not very complicated -- you just have to find .symtab and .strtab sections, and read the .symtab as a table of Elf64_Sym entries. Or use libelf (start here).
An additional complication is that ld-linux could be stripped (the symbol table is not required for it to work). If it is stipped, neither GDB, nor your program will be able to find _dl_start.
Finally, it is somewhat likely that your attempt to find _dl_start is pointless: you do realize that this function is called long before the first instruction of your program is executed. By the time you hit main, _dl_start has long finished, never to be called again.
Upate:
I still wonder how gdb gets the address of _dl_start in ld-linux (it is stripped)
If ld-linux is stripped, GDB will not be able to find _dl_start in it. Since you GDB does find it, either
your ld-linux is not actually stripped, or
you have "separate debuginfo" package for glibc installed.
To verify that ld-linux is really fully stripped, run nm /lib64/ld-linux-x86-64.so.2 | grep _dl_start and readelf -S /lib64/ld-linux-x86-64.so.2 | grep symtab. Both commands should produce no output.
To see where GDB is loading symbols from, you can use set print symbol-loading on command (before running the executable).
I wanted to to call _dl_start (after preparing the stack and adjusting the auxiliary vector) to create an executable image of a program stored already in memory (file representation)...
I don't see how that could possibly work. _dl_start expects certain state (e.g. its global variables to be zeroed out) before it is called, so calling it for a second time is very likely to result in assertion failure even if you don't adjust the aux vector. And assert is even more likely if you do adjust aux vector in some non-trivial way, which is (apparently) your goal.

Answer 2

_dl_start is not part of your program itself, it is contained in the runtime loader (as you can see from the output "..._dl_start () from /lib64/ld-linux-x86-64.so.2").
GDB initially cannot set a breakpoint, because it is not contained in your executable.
It is a bit unclear to me, if you want to know the address of _dl_start from inside the program or from outside? From the inside, you should be able to simply assign it e.g. to a void* variable like this:
void* address = dl_start;