From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15252 invoked by alias); 4 Nov 2007 17:22:03 -0000 Received: (qmail 15243 invoked by uid 22791); 4 Nov 2007 17:22:03 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate6.de.ibm.com (HELO mtagate6.de.ibm.com) (195.212.29.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 04 Nov 2007 17:22:01 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id lA4HLwgt461960 for ; Sun, 4 Nov 2007 17:21:58 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id lA4HLw1G1978478 for ; Sun, 4 Nov 2007 18:21:58 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lA4HLvYn030250 for ; Sun, 4 Nov 2007 18:21:57 +0100 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id lA4HLvsx030247; Sun, 4 Nov 2007 18:21:57 +0100 Message-Id: <200711041721.lA4HLvsx030247@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Sun, 4 Nov 2007 18:21:57 +0100 Subject: Re: RFC: tracepoints: abstract frame base finding in dwarf2loc.c To: jimb@codesourcery.com (Jim Blandy) Date: Sun, 04 Nov 2007 17:22:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: from "Jim Blandy" at Oct 26, 2007 04:21:28 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00040.txt.bz2 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? > +/* 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); Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com