From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6159 invoked by alias); 28 Dec 2010 15:46:15 -0000 Received: (qmail 6150 invoked by uid 22791); 28 Dec 2010 15:46:14 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Dec 2010 15:46:09 +0000 Received: (qmail 32624 invoked from network); 28 Dec 2010 15:46:08 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Dec 2010 15:46:08 -0000 From: Pedro Alves To: Joel Brobecker Subject: Re: [PATCH 7/8] ia64-hpux: unwinding bsp value from system call Date: Tue, 28 Dec 2010 16:17:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.33-29-realtime; KDE/4.4.5; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <1293511386-7384-1-git-send-email-brobecker@adacore.com> <201012281104.06493.pedro@codesourcery.com> <20101228113541.GC2436@adacore.com> In-Reply-To: <20101228113541.GC2436@adacore.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012281546.01099.pedro@codesourcery.com> X-IsSubscribed: yes 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/msg00513.txt.bz2 On Tuesday 28 December 2010 11:35:41, Joel Brobecker wrote: > I will use a different object kind. I could create our own object kind, > but someone it seems possible to have one that can be re-used by all > targets. > > Some proposed names: > > TARGET_OBJECT_OSABI_SPECIFIC_DATA > TARGET_OBJECT_OSABI_DATA > TARGET_OBJECT_TARGET_SPECIFIC_DATA > TARGET_OBJECT_TARGET_DATA > > Another option is to create feature-specific objects, but then I'm > afraid the number of objects might steadily grow beyond reasonable > (I need two, right now). > > The last option, is to follow the lead of some targets, and create > a CPU-specific target object: TARGET_OBJECT_IA64. 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. -- Pedro Alves