shlibs/2227: gdb dying on very large shared library

[laurent at oget dot net]

>Number:         2227
>Category:       shlibs
>Synopsis:       gdb dying on very large shared library
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 12 16:28:02 GMT 2007
>Closed-Date:
>Last-Modified:
>Originator:     laurent@oget.net
>Release:        unknown-1.0
>Organization:
>Environment:
SunOS atl-qa-sol10 5.10 Generic_118822-30 sun4u sparc SUNW,A70
GNU gdb 6.4 
This GDB was configured as "sparc-sun-solaris2.10".

gcc version 3.4.3
>Description:
I have been trying to use gdb to debug an application built with g++ on solaris, which uses a lot of templated code and suffers from a pretty bad case of code bloat. The shared library is 154M and nm finds 195254 entry points in it. Should gdb be able to handle this or are we exceeding some limit there?

gdb is able, after some time to load the executable and set break points, but when i attempt to run the application in gdb i get thousands of error messages:

 BFD: /export/home/devUser/laurent/src/bin/libxArray.so.1: invalid string offset 6074469 >= 32 for section `'
BFD: /export/home/devUser/laurent/src/bin/libxArray.so.1: invalid string offset 561167 >= 80 for section `.shstrtab'

and gdb eventually dies with 


BFD: BFD 2.16.91 20051101 internal error, aborting at elfcode.h line 190 in bfd_elf64_swap_symbol_in

BFD: Please report this bug.

the library is linked with:

g++ -mcpu=v9 -m64 -g -shared -h libxArray.so.1 -Wl,-R,/export/home/devUser/laurent/src/bin .... 

and the objects are built with 

g++ -c -mcpu=v9 -m64 -fshort-wchar -fno-operator-names -Wno-deprecated -Wno-invalid-offsetof -g

I suspected a mismatched c++  ABI version and recompiled all third party libraries with the same compiler, and I am running out of things to try...

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: