[fpc-devel] gdb "Dwarf Error: Could not find abbrev number" loading symbols from .so

[Seth Grover]

Greetings,

The project I maintain includes several shared object libraries (.so
files, since we're dealing in Linux) which are built with FPC. We've
been using the 2.4.0 release of the compiler, but since I've heard the
release of 2.4.2 is upcoming, I decided to make sure everything builds
and works okay with what's in the fixes_2_4 branch from SVN.

Everything compiled fine, and seems to run correctly as well. However,
when I built for debugging in GDB with dwarf symbols ("-O1 -g -gl
-gw") I found that gdb could not attach to my process successfully
because it failed to load the symbols from one of my .so's. So, I ran
gdb on the .so file directly just to watch it load the symbols up.

When I build the library with FPC 2.4.0 I get:
Reading symbols from /home/tlacuache/tmp/libESSDB.so...done.

However, when I build the exact same source code with 2.4.1 (currently
I'm at rev 15403) gdb tells me this:
Reading symbols from /home/nitrodev/devel/bin/libESSDB.so...Dwarf
Error: Could not find abbrev number 10751 [in module
/home/nitrodev/devel/bin/libESSDB.so]

The odd thing is, of my 6 .so's that are part of this project, the
other 5 are just fine. It's just this one .so. Just to make sure, I
did a complete clean checkout, build, and installation of FPC from the
fixes_2_4 branch with a clean checkout of the code for my library, and
it reproduces 100% percent of the time with this one particular
library (and works 100% of the time with the other 5 libraries I'm
building).

Compiling without -gw (which generates stabs debug info instead of
dwarf, I believe) does work correctly and allows me to debug, but I
prefer to use dwarf because of the difference in the resulting file
size and because its a more modern format.

I don't know very much about gdb's internals and dwarf symbol
information formats. I have not yet started to try to boil this down
into something I can attach to an issue in mantis since the code which
makes up this library is the intellectual property of my employer and
is not for me to release, but I'm happy to get as much information as
I can about my environment, to try and experiment with other tests or
revisions or patches or whatever I can to help. If I need to I can try
to start commenting out large chunks of code from the .so to see if I
can pinpoint exactly what it is about this .so that doesn't exist in
the other 5 .so's that makes it behave differently, but before I start
down that long road I thought it best to describe the situation to you
and see what ideas you might have.

By the way, I'm building on and targeting linux/i386.

Cheers,

-SG


--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.

Seth Grover
sethdgrover[at]gmail[dot]com