From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7767 invoked by alias); 19 Oct 2007 12:10:18 -0000 Received: (qmail 7751 invoked by uid 22791); 19 Oct 2007 12:10:15 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.29.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 19 Oct 2007 12:10:11 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id l9JCA8T3566698 for ; Fri, 19 Oct 2007 12:10:08 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 l9JCA7wU1712288 for ; Fri, 19 Oct 2007 14:10:07 +0200 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 l9JCA7c8027877 for ; Fri, 19 Oct 2007 14:10:07 +0200 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 l9JCA71T027874; Fri, 19 Oct 2007 14:10:07 +0200 Message-Id: <200710191210.l9JCA71T027874@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 19 Oct 2007 14:10:07 +0200 Subject: Re: [RFC] Using values to handle unwinding To: drow@false.org (Daniel Jacobowitz) Date: Fri, 19 Oct 2007 12:10:00 -0000 From: "Ulrich Weigand" Cc: gdb@sourceware.org, kettenis@gnu.org (Mark Kettenis) In-Reply-To: <20071017160350.GA26804@caradoc.them.org> from "Daniel Jacobowitz" at Oct 17, 2007 12:03:50 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-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00168.txt.bz2 Daniel Jacobowitz wrote: > It returns a GDB value object describing the register value. It may > be a lazy reference to memory, a lazy reference to the value of a > register in THIS frame, or a non-lvalue (constant or address). The > first part of the patch adds support for lazy registers, which are not > fetched until they are needed. When any frame other than the sentinel > frame sees that a register in the PREV frame is not saved or constant, > it returns a lazy reference to the register in THIS frame. I think this is an excellent idea. I'm wondering how this plays with special conversions needed for certain registers, see e.g. the discussion we had last December that led to introduction of the value_from_register gdbarch callback. For example, while we do have ways of performing special conversions on the registers themselves, there is no straightforward way to do so for unwound register contents. Maybe if we're going to using values to represent those, we could allow the architecture to perform type- specific conversions on those (this should e.g. allow me to eliminate a specical pseudo on the SPU that I'm using to hold the properly converted unwound stack pointer register contents). > There are three key differences / motivations: > > - Uses GDB's value infrastructure. Values carry around the > location information which previously took four extra arguments > to every unwinder. And this lets us use our existing value > manipulation routines as necessary. > > - Uses the same frame that non-unwinder architecture methods use. > For instance, in my ARM CPSR unwinding patch I had a routine > "arm_frame_is_thumb". It was used during software single > stepping, where we wanted the state of the current frame, and > during unwinding, where we wanted the state of THIS frame > (i.e. the one being unwound / having its ID established). > > - Simplifies getting other registers from the PREV frame. > For instance, if one register is computed based on the > value of another. Previously you had to inline code > to do this or call the same prev_register routine again > with the same NEXT frame and THIS cache; awkward if more > than one function was involved (see previous reason). I must admit I also no longer understand the original reason for using the NEXT_FRAME here. If THIS_FRAME works, it would certainly appear to be much more straightforward ... B.t.w. there's another change in the patch: the elimination of the prev_pc unwinder method. Could you explain the reason why this is now no longer necessary? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com