From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24698 invoked by alias); 27 Apr 2009 00:43:53 -0000 Received: (qmail 24690 invoked by uid 22791); 27 Apr 2009 00:43:52 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_13,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 27 Apr 2009 00:43:46 +0000 Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id n3R0hfgg010981 for ; Mon, 27 Apr 2009 01:43:42 +0100 Received: from qyk3 (qyk3.prod.google.com [10.241.83.131]) by wpaz1.hot.corp.google.com with ESMTP id n3R0hen1011308 for ; Sun, 26 Apr 2009 17:43:40 -0700 Received: by qyk3 with SMTP id 3so4283982qyk.3 for ; Sun, 26 Apr 2009 17:43:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.110.21 with SMTP id l21mr2199082qcp.26.1240793020190; Sun, 26 Apr 2009 17:43:40 -0700 (PDT) In-Reply-To: <49F4C98B.2000609@apogeect.com> References: <49F4C98B.2000609@apogeect.com> Date: Mon, 27 Apr 2009 05:25:00 -0000 Message-ID: <8ac60eac0904261743i452a3ae5qc49b8f483644413a@mail.gmail.com> Subject: Re: Experiences building and using gdb 6.8 on Solaris From: Paul Pluzhnikov To: Frank Middleton Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00197.txt.bz2 On Sun, Apr 26, 2009 at 1:52 PM, Frank Middleton 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