Re: new gdb arch routine FRAME_UNCHANGED

[David Mosberger <davidm@napali.hpl.hp.com>]

>>>>> On Sat, 11 May 2002 23:52:33 -0400, Andrew Cagney <ac131313@cygnus.com> said:

  Andrew> Tossing out the work-in-progress will probably be useful -
  Andrew> KevinB (ia64 maintainer) would at very likely be interested
  Andrew> in what is comming his way :-)

Oh, I already discussed the complete patch with KevinB.

  Andrew> Hmm, is it possible to re-enter a function without changing
  Andrew> the register stack pointer?

Yes.

  Andrew> If it isn't then the register
  Andrew> stack pointer could be used for frame->frame.

That doesn't work.  I think you might be able to get away with using
the memory stack pointer *OR* the register stack pointer as a unique
id for each frame, but that seems rather ugly and I suspect there are
cases where you might run into ambiguities.

  >> 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.

  Andrew> The value can't be really opaque.  GUI code and MI are
  Andrew> easier if they don't have to worry about malloc/free
  Andrew> (frame_id being a lightweight) and MI needs to be able to
  Andrew> pass the contents back to clients.

Oh, by "opaque" I didn't mean a "void *".  Just an object of a fixed
size with an undefined structure.  I agree that it's preferable to be
able to declare automatic variables of this type.  I was thinking of
having an array of "void *" inside an struct, with the array size
being architecture-specific.

  Andrew> However, gdbarch methods to fill in and compare frame_id's
  Andrew> could certainly be added.

OK, that would probably do it.  Do you see any need to calculate a
hash or is comparison for equality sufficient?

	--david