From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18174 invoked by alias); 5 Nov 2007 16:41:31 -0000 Received: (qmail 18162 invoked by uid 22791); 5 Nov 2007 16:41:30 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 05 Nov 2007 16:41:28 +0000 Received: (qmail 14343 invoked from network); 5 Nov 2007 16:41:26 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Nov 2007 16:41:26 -0000 To: "Ulrich Weigand" Cc: gdb-patches@sourceware.org Subject: Re: RFC: tracepoints: abstract frame base finding in dwarf2loc.c References: <200711041721.lA4HLvsx030247@d12av02.megacenter.de.ibm.com> From: Jim Blandy Date: Mon, 05 Nov 2007 16:41:00 -0000 In-Reply-To: <200711041721.lA4HLvsx030247@d12av02.megacenter.de.ibm.com> (Ulrich Weigand's message of "Sun, 4 Nov 2007 18:21:57 +0100 (CET)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2007-11/txt/msg00072.txt.bz2 "Ulrich Weigand" writes: > Jim Blandy wrote: > >> Here's a change to dwarf2loc.c that pulls out the guts of the code to >> find a function symbol's frame base expression into its own function. >> We'll also use this function to find frame bases for variables we're >> collecting at a tracepoint, in a later patch. There should be no >> change in behavior. Tested on i386 Linux with no regressions. > > Nice; I assume you'll be using that to handle DW_OP_fbreg properly and > get rid of the gdbarch_virtual_frame_pointer call in tracepoint_var_ref? Yes, exactly! >> +/* Find the frame base expression for PC, within FUNCTION. >> + Set *START to a pointer to it; set *LENGTH to its length. */ >> +static void >> +symbol_frame_base (struct symbol *function, CORE_ADDR pc, >> + gdb_byte **start, size_t *length) > > I think the FUNCTION is redundant here, it can be recovered > via find_pc_function (pc). This should in all cases have the > same result as the get_frame_function (frame) call below. > >> + struct symbol *framefunc = get_frame_function (frame); >> + CORE_ADDR pc = get_frame_address_in_block (frame); Yes, I think you're right. I had been confused about whether the pc-decrementing magic necessary for find_pc_function to get the right answer would always happen correctly, but: - in the dwarf_expr_frame_base case, the PC we'd supply comes from get_frame_address_in_block, which does the magic, and - in the tracepoint case, the address is supplied directly by the user, so the magic isn't required. Thanks!