Почему GDB не разрешает этот символ до тех пор, пока он не ударит `main`? Почему не может решить эту проблему?

Question

Я пытаюсь использовать issue, где Valgrind не может разрешать символы функций, которые проходят через определенные библиотеки. Я получаю такой вывод:

==83597== 920 bytes in 1 blocks are possibly lost in loss record 750 of 864 
==83597== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==83597== by 0x548EF93: myproject_malloc (mysourcefile.c:48) 
==83597== by 0x4F13FD5: ??? (in /path/to/project/library-version.so) 
==83597== by 0x54542FF: ??? (in /path/to/project/library-version.so) 
==83597== by 0x4F536CA: ??? (in /path/to/project/library-version.so) 
==83597== by 0x54542FF: ??? (in /path/to/project/library-version.so) 

Одна из функций внутри library-version.so является do_init(). library-version.so загружается через LD_PRELOAD. Я обнаружил, что, когда я запускаю свою программу под gdb, если я попытаюсь поставить точку останова на do_init, как только я запустил программу, она жалуется, что не может найти символ, но если бы я поставил точку останова на main и дождитесь, пока это не ударит, тогда это сработает.

Например:

(gdb) break do_init 
Function "do_init" not defined. 
Make breakpoint pending on future shared library load? (y or [n]) n 
(gdb) break main 
Breakpoint 1 at 0x400b50: file runner.c, line 13. 
(gdb) run 
... a bunch of output from the stuff in LD_PRELOAD ... 
Breakpoint 1, main (argc=1, argv=0x7fffffffe028) at myprogram.c:13 
13  return do_some_stuff(); 
(gdb) break do_init 
Breakpoint 2 at 0x7ffff7658de0: file my/library/initializer.c, line 25. 

Так что это приводит меня к двум вопросам:

1. Казалось, что do_init становится затянуты в компоновщика. Как узнать, на каком этапе процесса инициализации происходит? В этом проекте используется множество библиотек, которые определяют функции с помощью __attribute__((constructor)), и они склеиваются со сценарием компоновщика.

2. Почему Valgrind не видит символы, загруженные динамическим компоновщиком, например GDB? Я на 99% уверен, что ничего нет dlclose 'd, и я думал, что что-нибудь под LD_PRELOAD останется видимым для Valgrind независимо от того, что.

Answer 1

Оказалось, что из-за целой кучей странных вариантов конфигурации, которые произошли присутствовать в то же время, программа секции заголовка library-version.so, который содержал раздел .text был помечен с разрешениями RWX, а не разрешений гх , Valgrind считает, что разделы .text не могут иметь разрешения rwx на машинах amd64, поэтому игнорируют их при попытке загрузить символы отладки.

Я считаю, что это ошибка в Valgrind, потому что разделы .text с разрешениями rwx отлично подходят в соответствии с соответствующими стандартами; получается, что отчет уже был filed here, который я расширил.