objdump -W видит номера строк, objdump -drl и gdb нет?

Есть много вопросов с отсутствующими исходными файлами и т. д., и я перепробовал все, что мог найти, но безрезультатно.

Речь идет о моей библиотеке с некоторыми вспомогательными приложениями. Я использую автоинструменты (и libtool).

Я скомпилировал свой код с -g и без оптимизации (позже пробовал и с -ggdb3 без заметной разницы по этому вопросу). Я пробовал gdb на установленном файле, а также libtool --mode=execute gdb build/dir/file без разницы.

Если я использую objdump -W, я вижу следующее (давайте возьмем случайную функцию и отследим только ее):

$ objdump /usr/bin/that_file

 ...
 <1><a11>: Abbrev Number: 38 (DW_TAG_subprogram)
    <a12>   DW_AT_name        : (indirect string, offset: 0xbcc2): fill_memory  
    <a16>   DW_AT_decl_file   : 4       
    <a17>   DW_AT_decl_line   : 98      
    <a18>   DW_AT_prototyped  : 1       
    <a18>   DW_AT_type        : <0x3c>  
    <a1c>   DW_AT_low_pc      : 0x4010ce        
    <a24>   DW_AT_high_pc     : 0x92 0x0        
    <a2c>   DW_AT_frame_base  : 1 byte block: 9c        (DW_OP_call_frame_cfa)
    <a2e>   DW_AT_GNU_all_tail_call_sites: 1    
    <a2e>   DW_AT_sibling     : <0xa83> 
 ...

 The Directory Table:
 ...
 ../../../apps/calibrator
 ...

 The File Name Table:
 ...
 4     2       0       0       main.c
 ...

Вы можете видеть, что символ находится в строке 98 ../../../apps/calibrator/main.c относительно того места, где был создан файл. Если я использую gdb и делаю info sources (перед запуском), я получаю:

(gdb) info sources
Source files for which symbols have been read in:



Source files for which symbols will be read in on demand:

..., /path/to/my/library/apps/calibrator/main.c

Это означает, что gdb правильно видит исходный файл. Если я прерываю функцию в main.c (например, main), я вижу, что этот файл все еще находится в файлах, которые «будут прочитаны по запросу», а не в тех, которые уже прочитаны.

Если я сделаю info source, в этот момент он скажет мне «Нет текущего исходного файла». Если я использую objdump -dl, я вижу:

00000000004010ce <fill_memory>:
fill_memory():
  4010ce:       55                      push   %rbp
  4010cf:       48 89 e5                mov    %rsp,%rbp
  ...

Таким образом, objdump -dl также не видит номеров файлов/строк, связанных с этим символом. Если в gdb я делаю list main, я получаю «Нет известного номера строки для main».

Почему objdump -dl не видит номера строк, а objdump -W видит? Что мне не хватает?


person Shahbaz    schedule 13.02.2015    source источник
comment
Примечание. Я только что попробовал -gstabs+ вместо -ggdb3, и, похоже, это работает. Почему? Разве -ggdb3 не должен лучше подходить для gdb?   -  person Shahbaz    schedule 13.02.2015
comment
Примечание к посту: используя -gstabs+, я вижу несоответствия. Например, параметр функции (указатель) сообщается как 0x0 в gdb, но немедленный printf печатает его правильно. На самом деле printf с &param показывает другой адрес, чем p &param в gdb. Значения, напечатанные gdb, имеют правильный тип, и ни одна другая переменная с таким же именем не определена глобально.   -  person Shahbaz    schedule 13.02.2015
comment
Не используйте удары. Они старые и, как правило, более глючные и почти не поддерживаются в gdb и gcc.   -  person Tom Tromey    schedule 14.02.2015
comment
Кроме того, вы не показали, что именно произойдет, если вы попытаетесь, например, сломать fill_memory.   -  person Tom Tromey    schedule 14.02.2015
comment
Возможно, вы используете относительно новый GCC и binutils с относительно старой GDB? См. этот ответ: stackoverflow.com/a/28132451/50617   -  person Employed Russian    schedule 14.02.2015
comment
@TomTromey, break fill_memory работает как положено. gdb останавливается на функции, но не показывает никакой информации о файле/строке.   -  person Shahbaz    schedule 14.02.2015
comment
@EmployedRussian, знаете что, может быть. Я работал на Ubuntu 12.04, и мне пришлось обновить gcc и g++ до более новой версии для функций C++11 для другого проекта. Поскольку gcc в Ubuntu 12.04 в противном случае застрял на 4.6, весьма вероятно, что gdb, который я использовал, на пару лет старше, чем gcc.   -  person Shahbaz    schedule 14.02.2015
comment
Пожалуйста, закройте этот вопрос как дубликат.   -  person Shahbaz    schedule 14.02.2015