Missing line numbers from debug symbols for library in whole program, but not on its own

Question

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 libtool --mode=execute gdb .libs/libfoo.so and ask it to list the source of some function list Bar::Baz, I get the source code as expected. If I run libtool --mode=execute gdb binary, I can break in Bar::Baz(), and see its arguments in a stack trace, but I get no source file or line numbers, like so:

#7  0x018348e5 in Bar::Baz(Qux*, Quux*) () from /path/to/libfoo.so
                           ^^^^^^^^^^^ <--- debug symbols are present!

Similarly, if I try to list Bar::Baz when debugging the executable, I get

No line number known for 'Bar::Baz'.

I have confirmed that the binary is linked with -g, and I can list its main function, so I know some of the debug information is present are present.

When I say info sources, I get a full listing of the files from which the library is built, with correct absolute paths. When I say info shared, I get the correct path listed to the object file, with a Yes in the Syms column.

Any further ideas what could be going wrong, and how to fix it?

---

Edit 1: By accident, I ran objdump -g on the offending library, and got the following output:

/path/to/foo.so.0.0.0: file format elf32-i386
objdump: /path/to/foo.so.0.0.0: no recognized debugging information

This is surprising, since objdump -h (what I had tried to run) lists a bunch of .debug_* sections. The objdump manual suggests readelf -w as well, and that seems to print a huge pile of information. I need to go look through at what it actually provides, though.

---

Edit 2: So, readelf -w has produced some enlightenment. For whatever reason, the shared object file doesn't seem to contain the debugging information from the vast majority any 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 -g, 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).

---

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.

Flotsam

Answer 1

This is an answer to an old question, but your problem matched mine, but none of the solutions worked. Here is what worked for me.

Change CFLAGS -g to "-g -gstabs".

objdump was not recognizing the dwarf style debug information. -gstabs changes this format to one that works with objdump -g and objdump -S and my debugger.

Hope it helps.

NOTE: For me, I was building a linux kernel. This change was make in the linux kernel's Makefile.

Clearing

I recently encountered an encore of this issue. This time, it was gcc 4.9 vs gdb 7.2. The compiler was generating DWARF v4, while the debugger could only understand up to DWARF v3. Upgrading the debugger resolved it. As a workaround, passing -gdwarf-3 told it to spit out older format symbol. – Flotsam

Answer 2

Your first point of confusion: Bar::Baz(Qux*, Quux*) does not imply that debug symbols are present (and in fact implies that they are not present).

The debugger merely demangles the function name. If the debug symbols were in fact present, you'd see Bar::Baz(Qux* qux = 0x12..., Quux* quux = 0x234...)

As for the real problem, I suspect that the symbol is defined in some other library, which

• appears on the link line for the binary before libfoo.so does, and
• was built without debug symbols

(The runtime loader will bind the reference to Bar::Baz() to the first definition it sees.)

If you print ip in frame #7, then do info symbol <value-just-printed>, I suspect you'll have an "Aha!" moment.

EDIT: Your update made your question self-inconsistent. AFAICT,

1. gdb can see debug symbols when you execute
   libtool --mode=execute gdb .libs/libfoo.so
2. but not when you execute libtool --mode=execute gdb binary
3. you've verified that the symbol definition is coming from the exact same .libs/libfoo.o
4. and readelf -w doesn't see debug symbols in .libs/libfoo.o

At least one of the above statements is likely false.

If they are all really true, you probably have a weird GDB and readelf bug (a bug in one is possible, a simultaneous bug in both is somewhat unlikely).

Also note that adding -g to LDFLAGS is generally the wrong thing to do. Did you mean to add it to CXXFLAGS instead?

Civilly

That's a good point about the name mangling. I'll take a closer look at exactly what's linked in tomorrow morning. I'm doubtful that there's a wrong library involved, since the binary is a test program built in the same tree as the only visible instance of the library that it's supposed to be testing - there are no system installations or anything like that to contend with. – Flotsam

I just checked this, and the library linked is the library I expect. A typo I made led to an interesting discovery, with which I will amend the original question. – Flotsam

If you (or anyone else reading this) have other ideas to offer, I'm all ears (eyes, really). – Flotsam

Answer 3

Something made me wonder what the output of show language is when you are experiencing problems. If its not c++, maybe set language c++ is necessary?

Nomanomad