From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7031 invoked by alias); 22 Feb 2006 17:06:47 -0000 Received: (qmail 7023 invoked by uid 22791); 22 Feb 2006 17:06:45 -0000 X-Spam-Check-By: sourceware.org Received: from nwkea-mail-4.sun.com (HELO nwkea-mail-4.sun.com) (192.18.42.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 22 Feb 2006 17:06:42 +0000 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k1MH6e3W000226 for ; Wed, 22 Feb 2006 09:06:40 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IV300C01LZ7GT@mpk-mail1.sfbay.sun.com> (original mail from Olatunji.Ruwase@Sun.COM) for gdb-patches@sources.redhat.com; Wed, 22 Feb 2006 09:06:40 -0800 (PST) Received: from Sun.COM (ruwase.SFBay.Sun.COM [129.146.78.63]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IV300CUFM5B7U@mpk-mail1.sfbay.sun.com>; Wed, 22 Feb 2006 09:05:35 -0800 (PST) Date: Wed, 22 Feb 2006 18:24:00 -0000 From: Olatunji Ruwase Subject: Re: Re : Debugging v8plus binaries on solaris In-reply-to: <200602172331.k1HNVj1L030314@elgar.sibelius.xs4all.nl> To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Reply-to: Olatunji.Ruwase@Sun.COM Message-id: <43FC99DF.5010408@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <43ECF3A0.6070203@Sun.COM> <43F65373.5020805@Sun.COM> <200602172331.k1HNVj1L030314@elgar.sibelius.xs4all.nl> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00418.txt.bz2 Mark Kettenis wrote On 02/17/06 15:31,: >>Date: Fri, 17 Feb 2006 14:51:31 -0800 >>From: Olatunji Ruwase > > > Sorry, I spent most of the week in bed/on the couch in front of the > telly with a bad flu :(. I had a first glance at it last week, but Nice to have you back :). > I'm afraid it needs a bit more work. I suspected it would, this is my first stab at gdb development, and the architecture of the code is still a bit fuzzy to me. > > For one thing, I think it's important to split the generic v8plus > target support out from the Solaris v8plus native support. And > concentrate on the target support first. The seperation is mostly > already there (*-tdep.c versus *-nat.c), but some of the Solaris > native "weirdness" (which I realize is necessary for backwards > compatibility) has crept into the target support. > > Looking from an OS agnostic point onto the v8plus support code, I > really think v8plus should be a seperate architecture much in the same > way existing 64-bit support is seperate from the 32-bit support. Of > course this v8plus architecture should reuse as much code from the > existing 32-bit code as possible, and if the 32-bit code can be > generalized to work for v8plus as well, that's great, but I think > constructs like > > if (sparc_v8plus) > { > ... > } > else > { > ... > } > Most of my changes to the target support (sparc-tdep.c) are wrapped in the above construct. sparc32 target support assumes that registers are 4 bytes. One way to eliminate the "if (sparc_v8plus)" is to rewrite the code to also support 8 byte registers, while making sure that data is only written and read from the low 4 bytes. However this proposed change will not work for sparc32_register_type(), but should work for all other cases. Will this be an acceptable complexity in the target support code ?. If not I will start moving all the changes into sparc32plus-* files. > should be avoided. I also think the xregset stuff should be moved > into Solaris-specific files, perhaps even into Solaris-specofic > *-nat.c files. This depends a bit on how v8plus core dumps look. If > they have the xregset stuff too, the code should probably be moved to > sparc-sol2-tdep.c or sparc64-sol2-tdep.c. Yes the v8plus core dump has xregset stuff in it. And I now see why these changes need to be restricted to solaris specific files. > > Is the v8plus ABI documented somewhere? Unfortunately I dont think it is, I cant find any :(. Thanks tunji > > Mark