¿Por qué la dirección de __libc_start_main siempre es la misma dentro de GDB aunque ASLR esté activado?

Breakpoint 1, 0x00007ffff7de8060 in __libc_start_main () from /usr/lib/libc.so.6
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/firstlove/projects/org-ioslide/example/a.out 

Breakpoint 1, 0x00007ffff7de8060 in __libc_start_main () from /usr/lib/libc.so.6
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/firstlove/projects/org-ioslide/example/a.out 

Breakpoint 1, 0x00007ffff7de8060 in __libc_start_main () from /usr/lib/libc.so.6
(gdb) Quit
(gdb) quit
A debugging session is active.

        Inferior 1 [process 16372] will be killed.

Quit anyway? (y or n) y
firstlove-pc% cat /proc/sys/kernel/randomize_va_space
2

IIUC, ASLR debería aleatorizar todas las direcciones, incluida la de libc.so, pero descubrí que la dirección de __libc_start_main()siempre está 0x00007ffff7de8060en mi máquina Linux, ¿por qué? ¿Qué está mal?

— 陳力
fuente

¿La aleatorización del espacio de direcciones también aleatoriza las direcciones de función o solo las de las variables?

— rubenvb

¿Ve el mismo resultado si inicia una nueva sesión de gdb en la que verificar la dirección, en lugar de volver a ejecutar el programa en la misma sesión de gdb?

— John Bollinger

@JohnBollinger Lo he intentado definitivamente

— 陳力

Cuando ejecuta un programa dentro gdb, gdbintenta ayudarlo a depurar deshabilitando la asignación aleatoria de direcciones. Puede usar el siguiente comando para habilitarlo (efectivo desde la próxima ejecución del programa):

set disable-randomization off

— Marco Bonelli
fuente