0

There are a lot of questions with missing source files etc, and I tried all that I could find to no avail.

This is about a library of mine, with some helper applications. I use autotools (and libtool).

I have compiled my code with -g and no optimization (later tried with -ggdb3 as well with no observable difference w.r.t this question). I have tried gdb on the installed file, as well as libtool --mode=execute gdb build/dir/file with no difference.

If I use objdump -W, I can see the following (let's take a random function and track only that):

$ 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
 ...

You can see that the symbol is at line 98 of ../../../apps/calibrator/main.c relative to where the file was built. If I use gdb, and do info sources (before running), I get:

(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

Which means gdb is correctly seeing that source file. If I break on a function in main.c (such as main), I see that file still in files that "will be read in on demand", not in the ones that are already read.

If I do info source, at this point, it tells me "No current source file". If I use objdump -dl, I see:

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

So objdump -dl also doesn't see the file/line numbers associated with that symbol. If in gdb, I do list main, I get "No line number known for main."

Why doesn't objdump -dl see the line numbers when objdump -W does? What am I missing?

Shahbaz
  • 46,337
  • 19
  • 116
  • 182
  • Note: I just tried `-gstabs+` instead of `-ggdb3` and it seems to work. Why? Shouldn't `-ggdb3` be better suited to gdb? – Shahbaz Feb 13 '15 at 11:10
  • Post note: using `-gstabs+`, I see inconsistencies. For example, a function parameter (pointer) is reported as `0x0` in gdb, but an immediate `printf` prints it correctly. In fact, `printf` with `&param` shows a different address that `p &param` does in `gdb`. The values as printed by `gdb` have the correct type and no other variable with the same name is defined globally. – Shahbaz Feb 13 '15 at 11:18
  • Don't use stabs. They are old and generally buggier and barely maintained in gdb and gcc. – Tom Tromey Feb 14 '15 at 02:31
  • Also, you didn't show exactly what happens if you try, e.g., "break fill_memory". – Tom Tromey Feb 14 '15 at 02:34
  • Are you perhaps using relatively new GCC and binutils with a relatively old GDB? See this answer: http://stackoverflow.com/a/28132451/50617 – Employed Russian Feb 14 '15 at 05:45
  • @TomTromey, `break fill_memory` works as expected. `gdb` stops on the function, but doesn't show any file/line info. – Shahbaz Feb 14 '15 at 17:22
  • @EmployedRussian, you know what, that may be it. I was on an Ubuntu 12.04 and had to update gcc and g++ to a newer version for C++11 features for a different project. Since gcc on Ubuntu 12.04 was otherwise stuck at 4.6, it is very likely that the gdb I was using is a couple years older than the gcc. – Shahbaz Feb 14 '15 at 17:24
  • Please close this question as duplicate. – Shahbaz Feb 14 '15 at 17:27

0 Answers0