From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5062 invoked by alias); 25 Oct 2011 21:25:03 -0000 Received: (qmail 5011 invoked by uid 22791); 25 Oct 2011 21:25:02 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 25 Oct 2011 21:24:46 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RIoUH-0003gt-VB from pedro_alves@mentor.com ; Tue, 25 Oct 2011 14:24:46 -0700 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2011 22:24:42 +0100 From: Pedro Alves To: Joel Brobecker Subject: Re: [RFA/commit/ia64-linux] Allow libunwind to fetch register 0 Date: Wed, 26 Oct 2011 00:27:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.7.1; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <1319561563-20201-1-git-send-email-brobecker@adacore.com> <201110251818.43576.pedro@codesourcery.com> <20111025204052.GR19246@adacore.com> In-Reply-To: <20111025204052.GR19246@adacore.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110252224.37861.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: 2011-10/txt/msg00688.txt.bz2 On Tuesday 25 October 2011 21:40:52, Joel Brobecker wrote: > Hi again Pedro, > > I will make the small changes you suggested at the beginning of > the patch. I just wanted to confirm something: > > > > + gdb_assert (sizeof (r0_value) == register_size (gdbarch, regnum)); > > > + regcache_raw_supply (regcache, regnum, r0_value); > > > + return; > > > + } > > > + > > > > I don't speak ia64, but this is the right direction. > > I think we should make ia64_cannot_fetch_register return true for > > gr0 too though. > > I assume that you mean that ia64_cannot_fetch_register should return > False as well (meaning that we can in fact fetch the register - don't > you love double negatives?). Bleh. :-) Yes, I meant return false. > I had originally interpreted the name > of that function very strictly, meaning that, no, the kernel does > not provide that register value, so we cannot fetch it. But at the > same time, I think I see you point of having the fetch_register > routine saying we can get the value, while at the same time the > cannot_fetch_register function says we can't. Hmm, yeah, I looking at it from the perspective that the gdbarch hook can be used outside the ia64 target/arch dependent code, and at that point, it shouldn't matter if we're talking to ptrace or to a core or to something else. The core code calling the hook would only be interested in knowing whether the value can be fetched or not. But that looks moot, as this is used to mean "ptrace can fetch the register". alpha-nat.c: if (gdbarch_cannot_fetch_register (gdbarch, regno)) hppa-linux-nat.c: if (gdbarch_cannot_fetch_register (gdbarch, regno)) inf-ptrace.c: || gdbarch_cannot_fetch_register (gdbarch, regnum)) These are all legacy, and all look broken by design to me. I mean, what ptrace can or not return is a target-y thing, not gdbarch thing, and certainly the corresponding struct target can override the register fetching hook to do the same thing. I thought there were more uses of the hook... where have they gone to? :-D Given that, I don't see reason to change the hook on ia64-linux. In fact, I don't think there's any need for the hook to be installed on ia64-linux. Oh, wait, it _isn't_ installed as a gdbarch hook, is it? Eh. I'm tempted to go s/gdbarch_cannot_fetch_register/deprecated_gdbarch_cannot_fetch_register/g. :-) -- Pedro Alves