From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86521 invoked by alias); 16 Feb 2016 18:28:04 -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 86497 invoked by uid 89); 16 Feb 2016 18:28:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=overridden, buggy, targetspecific, target-specific X-HELO: e06smtp15.uk.ibm.com Received: from e06smtp15.uk.ibm.com (HELO e06smtp15.uk.ibm.com) (195.75.94.111) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Tue, 16 Feb 2016 18:28:02 +0000 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 16 Feb 2016 18:27:59 -0000 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 16 Feb 2016 18:27:56 -0000 X-IBM-Helo: d06dlp03.portsmouth.uk.ibm.com X-IBM-MailFrom: uweigand@de.ibm.com X-IBM-RcptTo: gdb-patches@sourceware.org Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 040811B08067 for ; Tue, 16 Feb 2016 18:28:12 +0000 (GMT) Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [9.149.37.248]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u1GIRtwR6226272 for ; Tue, 16 Feb 2016 18:27:55 GMT Received: from d06av07.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u1GIRt9B027339 for ; Tue, 16 Feb 2016 13:27:55 -0500 Received: from oc7340732750.ibm.com (dyn-9-152-213-148.boeblingen.de.ibm.com [9.152.213.148]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u1GIRtge027329; Tue, 16 Feb 2016 13:27:55 -0500 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id CE86C6BEA; Tue, 16 Feb 2016 19:27:54 +0100 (CET) Subject: Re: [PATCH 1/8] gdb: Add supply_pseudo_pc hook to gdbarch. To: koriakin@0x04.net (=?UTF-8?q?Marcin=20Ko=C5=9Bcielnicki?=) Date: Tue, 16 Feb 2016 18:28:00 -0000 From: "Ulrich Weigand" Cc: arnez@linux.vnet.ibm.com, gdb-patches@sourceware.org, koriakin@0x04.net (=?UTF-8?q?Marcin=20Ko=C5=9Bcielnicki?=) In-Reply-To: <1454853588-17529-1-git-send-email-koriakin@0x04.net> from "=?UTF-8?q?Marcin=20Ko=C5=9Bcielnicki?=" at Feb 07, 2016 02:59:48 PM MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20160216182754.CE86C6BEA@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16021618-0021-0000-0000-0000202FA248 X-SW-Source: 2016-02/txt/msg00486.txt.bz2 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 -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com