Re: Experiences building and using gdb 6.8 on Solaris

[Paul Pluzhnikov <ppluzhnikov at google dot com>]

On Sun, Apr 26, 2009 at 1:52 PM, Frank Middleton
<f.middleton@apogeect.com> wrote:
> Not sure if this is the correct list, but maybe someone here is interested
> in some Solaris issues
>
> This is on snv103 (SunOS 5.11) for SPARC, with make aliased to gmake.
>
> Biggest problem is that make distclean doesn't remove any of the cache
> files, so the make fails miserably if, for example, you change LDFLAGS.
>
> In order to get it to build, it was necessary to get the latest ncurses,
> and to build that --with-shared, and, as usual, remember not to use
> Solaris /bin/sh.
>
> The motivation to build the latest gdb is the following error with
> GNU gdb 6.3.50_2004-11-23-cvs
> ...
> elfread.c:366: internal-error: sect_index_data not initialized
> ...
>
> but, alas, it still fails with GNU gdb 6.8
> ...
> elfread.c:424: internal-error: sect_index_data not initialized
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
>
> Aside from the optimism of the last line (further debugging appears
> to be impossible), is this a known problem? It is proving to be rather
> difficult to make a simple test case, and extensive Googling found
> little other than that something similar had been fixed a while ago.
>
> Gdb runs simple executables just fine. The problem comes when linking
> and running an executable containing a mix of libraries compiled using
> Sun cc (i.e. the system libraries), some 3rd party libraries, probably
> compiled using a relatively old gcc (3.4.2), and a relatively new
> gcc (4.3.2) locally. Truss shows that the last library to be opened
> was /usr/lib/libXau.so.6. Both versions of gdb emit this warning:
> warning: Lowest section in /usr/lib/libdl.so.1 is .SUNW_syminfo at 00000094
> AFAIK Sun ld was used for linking throughout. The application actually
> run properly if you run it without gdb.
>
> Any insights much appreciated...

First, you should verify that it is indeed libXau.so.6 that is causing
the problem.
Steps:

echo "int main() { return 0; }" > junk.c
cc -g -c junk.c
cc -g junk.o -lX11  # resulting a.out should not produce the error
cc -g junk.o -lXau  # resulting a.out should trigger the problem

If libXau is indeed the problem, you've now got a trivial test case.
If not, do this:

  gdb -ex 'set verbose on' /path/to/app

This should provide a better clue what GDB was doing when the internal
error fired.

The other thing that may help figuring out the problem is to run gdb
under itself:

gdb -ex 'set prompt (top) ' --args gdb /path/to/app
(top) break internal_error
# Should set breakpoint 1 in the inferior GDB
(top) run
(gdb) run
# Should stop at breakpoint 1
(top) where full



-- 
Paul Pluzhnikov