From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9023 invoked by alias); 17 Oct 2005 20:28:32 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9005 invoked by uid 22791); 17 Oct 2005 20:28:29 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 17 Oct 2005 20:28:29 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j9HKSPE9017132; Mon, 17 Oct 2005 16:28:25 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j9HKSPV21264; Mon, 17 Oct 2005 16:28:25 -0400 Received: from theseus.home..redhat.com (vpn26-6.sfbay.redhat.com [172.16.26.6]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j9HKSNij020347; Mon, 17 Oct 2005 16:28:24 -0400 To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: RFA: general prologue analysis framework References: <200510171852.j9HIq3r7009705@53v30g15.boeblingen.de.ibm.com> From: Jim Blandy Date: Mon, 17 Oct 2005 20:28:00 -0000 In-Reply-To: <200510171852.j9HIq3r7009705@53v30g15.boeblingen.de.ibm.com> (Ulrich Weigand's message of "Mon, 17 Oct 2005 20:52:02 +0200 (CEST)") 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-SW-Source: 2005-10/txt/msg00138.txt.bz2 Ulrich Weigand writes: > I'll see how I can adapt the s390 code to use the new interface. > There's one point I'm not quite sure how to handle: it can happen that > the same register is saved multiple times to the stack (e.g. %r6 once in > the save area and once as incoming argument register). In this case, > the s390 heuristic is that the slot at the highest address is the real > save area slot. I'm not sure how to fit this into the generic routine ... pv_area_find_reg doesn't give you any way to express a preference between one location and another. But it does a linear search of the area, so if you're building up a table of all saved registers, you probably don't want to use it anyway. I think pv_area_scan would work better. Here's the function I use in the m32c port. /* Function for finding saved registers in a 'struct pv_area'; we pass this to pv_area_scan. If VALUE is a saved register, ADDR says it was saved at a constant offset from the frame base, and SIZE indicates that the whole register was saved, record its offset in the reg_offset table in PROLOGUE_UNTYPED. */ static void check_for_saved (void *prologue_untyped, pv_t addr, CORE_ADDR size, pv_t value) { struct m32c_prologue *prologue = (struct m32c_prologue *) prologue_untyped; struct gdbarch *arch = prologue->arch; struct gdbarch_tdep *tdep = gdbarch_tdep (arch); /* Is this the unchanged value of some register being saved on the stack? */ if (value.kind == pvk_register && value.k == 0 && pv_is_register (addr, tdep->sp->num)) { /* Some registers require special handling: they're saved as a larger value than the register itself. */ CORE_ADDR saved_size = register_size (arch, value.reg); if (value.reg == tdep->pc->num) saved_size = tdep->ret_addr_bytes; else if (gdbarch_register_type (arch, value.reg) == tdep->data_addr_reg_type) saved_size = tdep->push_addr_bytes; if (size == saved_size) { /* Find which end of the saved value corresponds to our register. */ if (gdbarch_byte_order (arch) == BFD_ENDIAN_BIG) prologue->reg_offset[value.reg] = (addr.k + saved_size - register_size (arch, value.reg)); else prologue->reg_offset[value.reg] = addr.k; } } }