From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6654 invoked by alias); 11 May 2002 02:05:55 -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 6630 invoked from network); 11 May 2002 02:05:51 -0000 Received: from unknown (HELO deimos.hpl.hp.com) (192.6.19.190) by sources.redhat.com with SMTP; 11 May 2002 02:05:51 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id TAA06127; Fri, 10 May 2002 19:05:50 -0700 (PDT) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by hplms2.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with ESMTP id g4B25nH17807; Fri, 10 May 2002 19:05:49 -0700 (PDT) Received: from napali.hpl.hp.com (localhost [127.0.0.1]) by napali.hpl.hp.com (8.12.2/8.12.2/Debian -5) with ESMTP id g4B25neM005289; Fri, 10 May 2002 19:05:49 -0700 Received: (from davidm@localhost) by napali.hpl.hp.com (8.12.2/8.12.2/Debian -5) id g4B25nx5005285; Fri, 10 May 2002 19:05:49 -0700 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15580.31869.406085.760707@napali.hpl.hp.com> Date: Fri, 10 May 2002 19:05:00 -0000 To: Andrew Cagney Cc: davidm@hpl.hp.com, gdb-patches@sources.redhat.com Subject: Re: new gdb arch routine FRAME_UNCHANGED In-Reply-To: <3CDC6E2F.9020702@cygnus.com> References: <200205110023.g4B0NVCF004832@napali.hpl.hp.com> <3CDC6E2F.9020702@cygnus.com> Reply-To: davidm@hpl.hp.com X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ X-SW-Source: 2002-05/txt/msg00382.txt.bz2 >>>>> On Fri, 10 May 2002 21:04:47 -0400, Andrew Cagney said: Andrew> Is the patch available somewhere? Not online, but if you want me to, I'm happy to send the complete patch to gdb-patches so you can see where I'm going (or thought I was going... ;-). Andrew> When you say unwind library support do you mean dwarf2cfi or Andrew> something else? From memory CFI identifies a frame using Andrew> CFA and PC, I'm wondering how things work here. The ia64 conventions come with their own unwind info. The conventions do not define a unique address/identifier for each frame. Andrew> cf: Andrew> http://sources.redhat.com/ml/gdb-patches/2002-04/msg00749.html Andrew> There is code through out GDB that relies on being able to Andrew> re-find a frame in the frame chain. The code typically Andrew> relies on just the frame address (oops). The referenced Andrew> patch changes it to use frame/pc. If I understand what Andrew> you're saying correctly, still more information will need to Andrew> be saved? Yes, this is an issue I was wondering about, too. My goal was fairly limited though: I just wanted to change gdb/ia64 to an unwind-info based implementation that works at least as well as the old version of gdb/ia64. I didn't look into this specific issue. It sounds like for ia64 we would need to add a another field to struct frame_id to track the register stack address of a frame. Otherwise, a recursive function that only uses the register stack would lead to a series of indistinguishable frames (a simple recursive factorial would do that). Is the idea to treat frame_id as an opaque structure? If so, I could add a routine to the unwind library API to obtain a unique frame-id for a given frame. That way, the ia64 issue could be hidden behind the API. --david