From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109043 invoked by alias); 16 Feb 2016 21:32:00 -0000 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 Received: (qmail 108997 invoked by uid 89); 16 Feb 2016 21:32:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Bye, HContent-Transfer-Encoding:8bit X-HELO: xyzzy.0x04.net Received: from xyzzy.0x04.net (HELO xyzzy.0x04.net) (109.74.193.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Feb 2016 21:31:57 +0000 Received: from hogfather.0x04.net (89-65-66-135.dynamic.chello.pl [89.65.66.135]) by xyzzy.0x04.net (Postfix) with ESMTPS id CAB3840588; Tue, 16 Feb 2016 22:32:46 +0100 (CET) Received: from [192.168.13.108] (89-65-66-135.dynamic.chello.pl [89.65.66.135]) by hogfather.0x04.net (Postfix) with ESMTPSA id E8DEA58008A; Tue, 16 Feb 2016 22:31:54 +0100 (CET) Subject: Re: [PATCH 1/8] gdb: Add supply_pseudo_pc hook to gdbarch. To: Ulrich Weigand References: <20160216182754.CE86C6BEA@oc7340732750.ibm.com> Cc: arnez@linux.vnet.ibm.com, gdb-patches@sourceware.org From: =?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?= Message-ID: <56C3954A.8060205@0x04.net> Date: Tue, 16 Feb 2016 21:32:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160216182754.CE86C6BEA@oc7340732750.ibm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00488.txt.bz2 On 16/02/16 19:27, Ulrich Weigand wrote: > Marcin Kościelnicki wrote: > >> I don't think generalizing that function to arbitrary pseudo registers >> is a good idea - there's already a pseudo_register_write, which covers >> writing them. The only reason I'm not using it in tracepoint.c is >> that there's no "current register state" to write over, I'm making >> a new one from scratch. > > Well, strictly speaking there is already a "current register state" > since tracefile_fetch_registers just initialized all registers to > the "unavailable" state. At this point they could be fetched (and > would read all zeros). > > So in principle you could just use regcache_write_pc at this point. > The reason this doesn't work is a different one: that routine would > attempt to *update target state*, i.e. it would call to the target's > to_store_registers method. However, the tracefile target only > provides a to_fetch_registers method, and no to_store_registers, > and the default target to_store_registers method just errors out. > > You *could* add a to_store_registers tracefile target method that > would simply ignore writes (in effect, making the tracefile regcache > modifyable without any underlying "real" target); then you could > just use regcache_write_pc. > > However, this would not address the fact that there are potentially > target-specific settings beyond a pure PC value that must be > present in order to make a "synthetic" regcache at least minimally > consistent. This includes e.g. the address mode bit on 31-bit. > Note that a default value of 0 isn't really valid for the PSWM > register either, even though probably nobody checks. But there > are a number of bits that have to be set to make it a valid > user-space PSW (e.g. interrupts and address translation must be > enabled etc.). If you'd ever try to load the PSW back to the > hardware via ptrace, a 0 PSWM would get rejected. > >> Perhaps a better generalization would be to instead make a hook that's >> supposed to provide a whole regcache based on the tracepoint location, >> not just PC? I can imagine a few uses for that: >> >> - on machines like ARM where you have several instruction encodings, >> you could also supply whatever registers determine the encoding >> (arm vs thumb) based on the location. >> - if you can determine from the debug information that the function >> keeps GOT pointer / literal pool pointer / whatever in some register >> at the tracepoint location, you can also guess the contents of these >> (although that's probably not all that useful, and can be a lie >> if something is horribly buggy). > > Given the above, I therefore agree that this is really probably > the preferable level of abstraction here. You want a gdbarch hook > to synthesize a minimally-valid regcache given only information > statically known about the tracepoint. Whether this hook gets > just the PC or a full tracepoint structure is probably not so > important right now; this could still be modified if necessary. > > I'd also suggest that this hook doesn't get a predicate, but a > default implementation, which does the current handling of just > setting a real PC register. If overridden by a gdbarch, the > platform can do anything that's necessary there instead. > > Bye, > Ulrich > Sounds good, I'll do that.