Databases
StackOverflow2013
Postsdbo
POMissing line numbers from debug symbols for library in whole program, but not on its own
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POMissing line numbers from debug symbols for library in whole program, but not on its own
    primarykey
    data
    text
    <p>I'm seeing an odd issue when trying to use gdb to debug a test program for a package built with libtool. If I run <code>libtool --mode=execute gdb .libs/libfoo.so</code> and ask it to list the source of some function <code>list Bar::Baz</code>, I get the source code as expected. If I run <code>libtool --mode=execute gdb binary</code>, I can break in <code>Bar::Baz()</code>, and see its arguments in a stack trace, but I get no source file or line numbers, like so:</p> <pre><code>#7 0x018348e5 in Bar::Baz(Qux*, Quux*) () from /path/to/libfoo.so ^^^^^^^^^^^ &lt;--- debug symbols are present! </code></pre> <p>Similarly, if I try to <code>list Bar::Baz</code> when debugging the executable, I get </p> <pre><code>No line number known for 'Bar::Baz'. </code></pre> <p>I have confirmed that the binary is linked with <code>-g</code>, and I can list its <code>main</code> function, so I know some of the debug information is present are present.</p> <p>When I say <code>info sources</code>, I get a full listing of the files from which the library is built, with correct absolute paths. When I say <code>info shared</code>, I get the correct path listed to the object file, with a <code>Yes</code> in the <code>Syms</code> column.</p> <p>Any further ideas what could be going wrong, and how to fix it?</p> <hr> <p>Edit 1: By accident, I ran <code>objdump -g</code> on the offending library, and got the following output:</p> <pre><code>/path/to/foo.so.0.0.0: file format elf32-i386 objdump: /path/to/foo.so.0.0.0: no recognized debugging information </code></pre> <p>This is surprising, since <code>objdump -h</code> (what I had tried to run) lists a bunch of <code>.debug_*</code> sections. The <code>objdump</code> manual suggests <code>readelf -w</code> as well, and that seems to print a huge pile of information. I need to go look through at what it actually provides, though.</p> <hr> <p>Edit 2: So, <code>readelf -w</code> has produced some enlightenment. For whatever reason, the shared object file doesn't seem to contain the debugging information from <strike>the vast majority</strike> <em>any</em> of the objects linked into it. Based on the Makefiles, it's possible that the command that actually gathers up the objects into the shared library isn't passed <code>-g</code>, and so that information isn't properly propagated. The funny thing is that this works (has full debug information) on all our other configurations, including the same compiler version on x86_64 (versus the present x86).</p> <hr> <p>Edit 3: Actually went through a full rebuild with the modified Makefile with -g added on the LDFLAGS, and it made no difference. Now I'm well and truly baffled.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USPhil Miller
    1. USPhil Miller
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POMissing line numbers from debug symbols for library in whole program, but not on its own
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POMissing line numbers from debug symbols for library in whole program, but not on its own
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POMissing line numbers from debug symbols for library in whole program, but not on its own
      1. USShriram
      1. VTFavorite
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload