This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: new gdb arch routine FRAME_UNCHANGED
- From: David Mosberger <davidm at napali dot hpl dot hp dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: davidm at hpl dot hp dot com, gdb-patches at sources dot redhat dot com
- Date: Fri, 10 May 2002 19:05:49 -0700
- Subject: Re: new gdb arch routine FRAME_UNCHANGED
- References: <200205110023.g4B0NVCF004832@napali.hpl.hp.com><3CDC6E2F.9020702@cygnus.com>
- Reply-to: davidm at hpl dot hp dot com
>>>>> On Fri, 10 May 2002 21:04:47 -0400, Andrew Cagney <ac131313@cygnus.com> 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