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
> 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... ;-).
Tossing out the work-in-progress will probably be useful - KevinB (ia64
maintainer) would at very likely be interested in what is comming his
way :-) (I should also double check what HP's Assignement status is.)
> 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).
Yep.
Hmm, is it possible to re-enter a function without changing the register
stack pointer? If it isn't then the register stack pointer could be
used for frame->frame.
> 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.
The value can't be really opaque. GUI code and MI are easier if they
don't have to worry about malloc/free (frame_id being a lightweight) and
MI needs to be able to pass the contents back to clients.
However, gdbarch methods to fill in and compare frame_id's could
certainly be added.
Andrew