From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25299 invoked by alias); 5 Feb 2008 15:34:45 -0000 Received: (qmail 25290 invoked by uid 22791); 5 Feb 2008 15:34:44 -0000 X-Spam-Check-By: sourceware.org Received: from mu-out-0910.google.com (HELO mu-out-0910.google.com) (209.85.134.189) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 05 Feb 2008 15:34:21 +0000 Received: by mu-out-0910.google.com with SMTP id w1so999mue.8 for ; Tue, 05 Feb 2008 07:34:18 -0800 (PST) Received: by 10.82.116.15 with SMTP id o15mr15654713buc.3.1202225657575; Tue, 05 Feb 2008 07:34:17 -0800 (PST) Received: by 10.82.165.12 with HTTP; Tue, 5 Feb 2008 07:34:17 -0800 (PST) Message-ID: <8f2776cb0802050734x1f79a335kfa3eaa104f25fedc@mail.gmail.com> Date: Tue, 05 Feb 2008 15:34:00 -0000 From: "Jim Blandy" To: "andrzej zaborowski" Subject: Re: [PATCH] Disallow pseudo-registers in agent expression. Cc: gdb-patches@sources.redhat.com In-Reply-To: <8f2776cb0801281728v2ff40d50y2be92664b2c28de5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8f2776cb0801271007r125463e0la1cf8a7c9d1efef@mail.gmail.com> <8f2776cb0801281728v2ff40d50y2be92664b2c28de5@mail.gmail.com> X-Google-Sender-Auth: 29a2f41756d0647b 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: 2008-02/txt/msg00104.txt.bz2 Andrzej, is this idea something that you would be interested in implementing? It'd be great to get this working. On Jan 28, 2008 5:28 PM, Jim Blandy wrote: > On Jan 28, 2008 3:51 PM, andrzej zaborowski wrote: > > On 27/01/2008, Jim Blandy wrote: > > > On some targets, all the user-visible registers are pseudo-registers. > > > What we need is a gdbarch method (optional) that the tracepoint code > > > could call, passing it a struct agent_expr and a pseudo-register > > > number, to have the architecture code append the appropriate bytecodes > > > to access that register. > > > > That's ofcourse doable but sounds tough and bug-prone. The mapping of > > numbers to raw registers is to some extent obvious and unlikely to > > change, while the pseudo-registers may change with gdb version so the > > target has more gdb version dependence. > > I'm not sure I expressed myself well. I was imagining something like this: > > *** ax-gdb.c 07 Jan 2008 08:31:13 -0800 1.40 > --- ax-gdb.c 28 Jan 2008 17:21:28 -0800 > *************** > *** 1607,1615 **** > if (reg == -1) > internal_error (__FILE__, __LINE__, > _("Register $%s not available"), name); > ! value->kind = axs_lvalue_register; > ! value->u.reg = reg; > ! value->type = register_type (current_gdbarch, reg); > } > break; > > --- 1607,1627 ---- > if (reg == -1) > internal_error (__FILE__, __LINE__, > _("Register $%s not available"), name); > ! if (reg < gdbarch_num_regs (current_gdbarch)) > ! { > ! value->kind = axs_lvalue_register; > ! value->u.reg = reg; > ! value->type = register_type (current_gdbarch, reg); > ! } > ! else > ! { > ! /* It's a pseudo-register reference; ask the architecture > ! to generate appropriate bytecode for it. */ > ! if (! gdbarch_gen_pseudo_reg_ax (current_gdbarch, ax, value, reg)) > ! error (_("Couldn't generate agent expression" > ! " to refer to register '%s'"), > ! gdbarch_register_name (current_gdbarch, reg)); > ! } > } > break; > > This seems pretty reasonable to me: only the architecture knows how > pseudo-register values are computed from the raw register values --- a > pseudo-register might be two raw registers spliced together, for > example --- so only the architecture knows the right agent bytecode to > generate. >