Re: new gdb arch routine FRAME_UNCHANGED

[Andrew Cagney <ac131313@cygnus.com>]

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

Ah, ok. I guess `struct { CORE_ADDR x[3]; }'.  If someone finds they 
need more entries then we can just keep making it bigger.  Trailing 
unused entries are zero.

The reason for advising against pointers or variable size struct is that 
these objects are not well managed in terms of malloc/delete.  The ptid 
is another example of the same thing of the same thing - no need to 
worry about memory leaks.

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

Some existing code wants to compare based on just frame.  See 
stack.c:parse_frame_specification.  Stop on first trailing zero?

Also, code wants to determine which code is more INNER_THAN().  With two 
stacks, that starts to get really weird!

Andrew