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

For what it's worth, this same problem occurs when using 2.5.1 from the trunk (rev 15410) in svn.

-SG

Okay, here's an update with this problem: I started doing a binary search through all the revisions of the fixes branch, and found that revision 14365 (http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=14365) introduced this problem.

If I check out rev 14364 I get the following when I tell gdb to read the symbols from my .so:
Reading symbols from /home/nitrodev/devel/bin/libESSDB.so...done.

But when I check out rev 14365 and recompile fpc then build my .so I get: 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]

Hopefully that helps.

-SG

Seth Grover wrote

But when I check out rev 14365 and recompile fpc then build my .so I get: 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]

Can you put the output of "readelf -w /home/nitrodev/devel/bin/libESSDB.so" and of "readelf -wa /home/nitrodev/devel/bin/libESSDB.so" online somewhere?

Jonas

Okay, on further investigation, the specific revision from the trunk which causes the problem 14336, which was merged into the fixes branch as part of 14365. Building FPC from the trunk at rev 14335 does not cause gdb to have the problem, but updating to 14336 does.

-SG

Jonas wrote

Can you put the output of "readelf -w /home/nitrodev/devel/bin/libESSDB.so" and of "readelf -wa /home/nitrodev/devel/bin/libESSDB.so" online somewhere?

http://sites.google.com/site/sethdgrover/Home/dwarfdebug.zip

-SG

Jonas, after looking at that file you had me generate, I was able to boil it down to a very simple case (http://pastebin.com/tX2f3ARe): ===========================================
program Project1;

{$mode objfpc}{$H+}

CONST

  (* query for finding found devices without connections
     used in ND_GetFoundDeviceList and
             GetFoundDevNoConn: ND_GetLastNWDiscStatus and ND_GetNumFoundNW *)
  QryNoConn = 'Select NDDevice.ID,NDDevice.UniqueID,

NDDevice.ManagementIP, NDDevice.Current '+
'FROM NDDevice '+
'WHERE NDDevice.Disabled=''F'' AND NDDevice.Current=''T'''+ ' AND NDDevice.ID NOT IN('+
'SELECT NDNeighbors.NDDevID1 FROM NDNeighbors group by NDNeighbors.NDDevID1)'+

       'ORDER BY 3 ';

begin

  writeln(QryNoConn);

end.
===========================================

$ gdb ./project1
GNU gdb (GDB) 7.1.0.20100510-cvs
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/tlacuache/tmp/project1...Dwarf Error: Could not find abbrev number 10751 [in module /home/tlacuache/tmp/project1]

Seems to be a problem with the long constant string?

-SG

Submitted to Mantis with the test case, thanks a lot.

http://bugs.freepascal.org/view.php?id=16705

-SG