From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10470 invoked by alias); 10 Dec 2002 02:32:25 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10290 invoked from network); 10 Dec 2002 02:32:23 -0000 Received: from unknown (HELO gw-us1.philips.com) (63.114.235.94) by sources.redhat.com with SMTP; 10 Dec 2002 02:32:23 -0000 Received: from smtpscan-us2.philips.com (unknown [167.81.233.26]) by gw-us1.philips.com (Postfix) with ESMTP id 9FAAD3DC77; Mon, 9 Dec 2002 20:32:22 -0600 (CST) Received: from smtprelay-us1.philips.com (localhost [127.0.0.1]) by smtpscan-us2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id UAA18577; Mon, 9 Dec 2002 20:32:20 -0600 (CST) Received: from smtphub.abq.sc.philips.com (smtphub.abq.sc.philips.com [130.140.3.9]) by smtprelay-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id UAA08963; Mon, 9 Dec 2002 20:32:20 -0600 (CST) Received: from atoae450.abq.sc.philips.com (atoae450.abq.sc.philips.com [130.140.5.8]) by smtphub.abq.sc.philips.com (8.8.5/8.8.5) with ESMTP id TAA17350; Mon, 9 Dec 2002 19:33:59 -0700 (MST) Received: from abqn42.abq.sc.philips.com (abqn42 [130.140.5.42]) by atoae450.abq.sc.philips.com (8.11.6+Sun/8.11.6) with SMTP id gBA2WGq05003; Mon, 9 Dec 2002 19:32:16 -0700 (MST) Message-Id: <200212100232.gBA2WGq05003@atoae450.abq.sc.philips.com> Date: Mon, 09 Dec 2002 18:56:00 -0000 From: Josh Martin Reply-To: Josh Martin Subject: Re: [PATCH]: gdb/769 - segv fault on "info shared" on GDB 5.2.1 HPUX64 11.00 To: Josh.Martin@abq.sc.philips.com, gdb-patches@sources.redhat.com, kevinb@redhat.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iHu9m6a643+EShrF9STsIQ== X-SW-Source: 2002-12/txt/msg00311.txt.bz2 > On Oct 9, 5:42pm, Josh Martin wrote: > > > Here's the ChangeLog entry that I forgot to post. Unfortunately I cannot get > > expect to work on my system, so I can neither create a test case for this bug, > > nor verify other tests after this patch. > > > > - Josh Martin > > > > 2002-09-28 Josh Martin > > > > * solib.c (info_sharedlibrary_command): Added catch for potential > > dereference of NULL pointer (current_target_so_ops). > > Fix PR gdb/769. > > > > > For platforms that aren't covered by the gdb/solib-foo.c files and the gdbarch > > > platform dependancy files the "info sharedlibrary" command will cause a > > > segmentation fault by dereferencing a NULL pointer (current_target_so_ops) in > > > gdb/solib.c:update_solib_list. The patch checks if current_target_so_ops is > > > NULL, and if so it responds with a "command not implemented" message. > > > > > > What I really wanted to do was to implement support for HPUX 11.00 64-bit > > w/GCC. > > > It shouldn't be too difficult as 64-bit GCC in HPUX 11.00 uses GNU ld and the > > > "standard" elf64hppa object format. Unfortunately I had no idea how to proceed > > > or where to find the neccesary information, thus I stuck with this "band-aid" > > > patch. > > Date: Thu, 5 Dec 2002 17:54:05 -0700 > From: Kevin Buettner > > I've been thinking about this patch some more. > > What I'm wondering is why your hpux target uses solib.o without defining > an appropriate solib-hpux.c (or whatever) file? > > Anyway, with regard to catching potential dereferences to a NULL > current_target_so_ops, I'm inclined to handle this either via > a gdb_assert() or an explicit check (perhaps in the TARGET_SO_* macros) > with a call to internal_error(). Because that's really what it is. We > shouldn't be in solib.c at all if an appropriate backend hasn't been > defined. > > Kevin I'm not involved with the HPUX maintainance/port of GDB, so I'm not completely sure, but I think there already is a backend for the HPUX libarary format (which is in 32-bit), but on a 64-bit HP platform the libraries are written in a 64-bit ELF format, at least with gcc and GNU ld, which goes through pa64solib.c. I also noticed that GDB isn't reading the core files properly, it is still trying to open them in the 32-bit format, but I'm not sure if this is a problem with GDB, or the BFD libraries. - Josh Martin