Warum wird _init aus glibcs csu / init-first.c vor _start aufgerufen, auch wenn _start der ELF-Einstiegspunkt ist?

Ich habe es zum ersten Mal bemerkt, als ich mit GDB's gespielt haberbreak . und dann ein minimales Beispiel:

(gdb) file hello_world.out
Reading symbols from hello_world.out...done.
(gdb) b _init
Breakpoint 1 at 0x4003e0
(gdb) b _start
Breakpoint 2 at 0x400440
(gdb) run
Starting program: /home/ciro/bak/git/cpp/cheat/gdb/hello_world.out

Breakpoint 1, _init (argc=1, argv=0x7fffffffd698, envp=0x7fffffffd6a8) at ../csu/init-first.c:52
52  ../csu/init-first.c: No such file or directory.
(gdb) continue
Continuing.

Breakpoint 2, 0x0000000000400440 in _start ()
(gdb) continue
Continuing.

Breakpoint 1, 0x00000000004003e0 in _init ()
(gdb) info breakpoints
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>
    breakpoint already hit 2 times
1.1                         y     0x00000000004003e0 <_init>
1.2                         y     0x00007ffff7a36c20 in _init at ../csu/init-first.c:52
2       breakpoint     keep y   0x0000000000400440 <_start>
    breakpoint already hit 1 time

Beachten Sie, dass es 2_init: eins incsu/init-first.c, und der andere scheint von @ zu kommsysdeps/x86_64/crti.S. Ich spreche über dascsu einer

Ist nicht_start soll der Einstiegspunkt sein, der vom Linker festgelegt und im ELF-Header gespeichert wurde? Welcher Mechanismus macht_init zuerst laufen? Was ist seine Aufgabe

Getestet auf GCC 4.8, glibc 2.19, GDB 7.7.1 und Ubuntu 14.04.

Antworten auf die Frage(2)

Ihre Antwort auf die Frage