From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10688 invoked by alias); 17 Oct 2005 18:52: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 10671 invoked by uid 22791); 17 Oct 2005 18:52:29 -0000 Received: from mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.29.152) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 17 Oct 2005 18:52:29 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j9HIqR1a140190 for ; Mon, 17 Oct 2005 18:52:27 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9HIqQOK225032 for ; Mon, 17 Oct 2005 20:52:26 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j9HIqQXM024473 for ; Mon, 17 Oct 2005 20:52:26 +0200 Received: from 53v30g15.boeblingen.de.ibm.com (53v30g15.boeblingen.de.ibm.com [9.152.26.155]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j9HIqQ86024468; Mon, 17 Oct 2005 20:52:26 +0200 Received: from 53v30g15.boeblingen.de.ibm.com (localhost [127.0.0.1]) by 53v30g15.boeblingen.de.ibm.com (8.12.10/8.12.10) with ESMTP id j9HIq3w0009715; Mon, 17 Oct 2005 20:52:04 +0200 Received: (from uweigand@localhost) by 53v30g15.boeblingen.de.ibm.com (8.12.10/8.12.10/Submit) id j9HIq3r7009705; Mon, 17 Oct 2005 20:52:03 +0200 From: Ulrich Weigand Message-Id: <200510171852.j9HIq3r7009705@53v30g15.boeblingen.de.ibm.com> Subject: Re: RFA: general prologue analysis framework To: jimb@redhat.com (Jim Blandy) Date: Mon, 17 Oct 2005 18:52:00 -0000 Cc: uweigand@de.ibm.com (Ulrich Weigand), gdb-patches@sourceware.org In-Reply-To: from "Jim Blandy" at Oct 14, 2005 11:12:55 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2005-10/txt/msg00137.txt.bz2 Jim Blandy wrote: > The comment for make_pv_area was misleading. Here's a better comment: > > /* Create a new area, tracking stores relative to the original value > of BASE_REG. Stores to constant addresses, unknown addresses, or > to addresses relative to registers other than BASE_REG will trash > this area; see pv_area_store_would_trash. */ > struct pv_area *make_pv_area (int base_reg); Yes, this is what I figured out in the meantime, sorry for the confusion. The new comment is definitely better, though ... 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 ... Bye, Ulrich -- Dr. Ulrich Weigand Linux on zSeries Development Ulrich.Weigand@de.ibm.com