From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9216 invoked by alias); 28 Dec 2010 11:35:57 -0000 Received: (qmail 9173 invoked by uid 22791); 28 Dec 2010 11:35:56 -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; Tue, 28 Dec 2010 11:35:49 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C1F892BAB17; Tue, 28 Dec 2010 06:35:47 -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 3mXMRSwBde2p; Tue, 28 Dec 2010 06:35:47 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 4D9442BAACF; Tue, 28 Dec 2010 06:35:47 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 1C0FB145870; Tue, 28 Dec 2010 15:35:41 +0400 (RET) Date: Tue, 28 Dec 2010 12:01: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: <20101228113541.GC2436@adacore.com> References: <1293511386-7384-1-git-send-email-brobecker@adacore.com> <1293511386-7384-8-git-send-email-brobecker@adacore.com> <201012281104.06493.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201012281104.06493.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/msg00506.txt.bz2 > BZZT. Don't do that. The return of a TARGET_OBJECT_OSDATA request > should be a table that follows the gdb/features/osdata.dtd dtd. It > is meant as data to be fed into the "info os" command (and a non-submitted > -info-os MI command). Arg - I thought that using a target-specific annex name would be sufficient. 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. -- Joel