From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17398 invoked by alias); 29 Jan 2008 01:28:33 -0000 Received: (qmail 17388 invoked by uid 22791); 29 Jan 2008 01:28:32 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.176) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jan 2008 01:28:15 +0000 Received: by py-out-1112.google.com with SMTP id f31so2237647pyh.18 for ; Mon, 28 Jan 2008 17:28:13 -0800 (PST) Received: by 10.35.47.10 with SMTP id z10mr7210174pyj.15.1201570093197; Mon, 28 Jan 2008 17:28:13 -0800 (PST) Received: by 10.35.36.15 with HTTP; Mon, 28 Jan 2008 17:28:13 -0800 (PST) Message-ID: <8f2776cb0801281728v2ff40d50y2be92664b2c28de5@mail.gmail.com> Date: Tue, 29 Jan 2008 01:49: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: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8f2776cb0801271007r125463e0la1cf8a7c9d1efef@mail.gmail.com> X-Google-Sender-Auth: 1d15bf6b15a44259 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-01/txt/msg00661.txt.bz2 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.