From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14946 invoked by alias); 29 Dec 2010 03:29:03 -0000 Received: (qmail 14938 invoked by uid 22791); 29 Dec 2010 03:29:02 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Dec 2010 03:28:56 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 0ABBD2BABF1; Tue, 28 Dec 2010 22:28:55 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dsTcTsJy2jDC; Tue, 28 Dec 2010 22:28:54 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 82B882BAB98; Tue, 28 Dec 2010 22:28:54 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 1205A145870; Wed, 29 Dec 2010 07:28:48 +0400 (RET) Date: Wed, 29 Dec 2010 05:49:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 7/8] ia64-hpux: unwinding bsp value from system call Message-ID: <20101229032848.GE2396@adacore.com> References: <1293511386-7384-1-git-send-email-brobecker@adacore.com> <201012281104.06493.pedro@codesourcery.com> <20101228113541.GC2436@adacore.com> <201012281546.01099.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201012281546.01099.pedro@codesourcery.com> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-12/txt/msg00535.txt.bz2 > What is the underlying object you're getting those values from? > I understood it to be whatever object TT_LWP_RUREGS accesses? > You seem to call it save_state_t? Why not TARGET_OBJECT_HPUX_RUREGS > or TARGET_OBJECT_HPUX_SAVE_STATE, or something along those lines? > Then, the offset, and length passed to target_xfer would the > the offset and length you're currently passing to > ia64_hpux_read_register_from_save_state_t. This would allow > (if useful) exporting this object similarly to the $_siginfo and > $_tlb objects. I cannot determine the offset from the tdep code. The offset is is a obtained by including one of the system hearders. To widen a bit the discussion, I should mention that there is also another object that I am trying to transfer in this patch set: During an inferior function call, I need to set the global pointer, and I can only get that global pointer from the shared-library code (we extract a structure from memory which is also defined by system headers). In both cases, I was (ab)-using TARGET_OBJECT_OSDATA. My initial thoughts on the kind of object to be used were that we could have one generic object which the targets were free to ues as they see fit. Right now, we have TARGET_OBJECT_AVR, TARGET_OBJECT_SPU, etc. It seems unnecessary to have one for each CPU since we can use namespace conventions to make sure there are no collision. I'm not even sure that collisions are really a problem either, in fact. Depending on which approach we use, I am proposing the following target objects: (a) * TARGET_OBJECT_HPUX_STOP_REASON Returns a 1-byte object. 0 == syscall context, non-zero == interruption context * TARGET_OBJECT_HPUX_SOLIB_GOT ANNEX contains an image of the PC for which we need the GOT Returns a CORE_ADDR that is either 0 if no shared library contains that PC, or else the associated SO's GOT. (b) One object for both datas: TARGET_OBJECT_HPUX, or TARGET_OBJECT_HPUX_DATA, or TARGET_OBJECT_TARGET_DATA, or TARGET_OBJECT_TDEP_DATA. In that case, the annex is used to determine which specific data the tdep code is looking for. I tend to like either TARGET_OBJECT_HPUX, or TARGET_OBJECT_TDEP_DATA, with a preference for the TARGET_OBJECT_TDEP_DATA. -- Joel