Re: [RFC/RFA/frame stuff] Fix build failure in alpha-osf1-tdep.c

[Andrew Cagney <ac131313@redhat.com>]

>> >2003-06-03  J. Brobecker  <brobecker@gnat.com>
>> >
>> >        * alpha-osf1-tdep.c (alpha_osf1_skip_sigtramp_frame): Replace
>> >        references to struct frame_info fields by calls to the equivalent
>> >        accessors. Necessary now that frame_info is opaque.
>> >        (alpha_osf1_pc_in_sigtramp): Likewise.
>> >
>> >Looks ok?
> 
>> 
>> Yes.  If you're feeling game you could use get_frame_memory, but
>> either way.
> 
> 
> Andrew, please forgive for not having followed the discussions about
> the new frame architecture too closely (I did go and read the messages
> you recently pointed out to Daniel, though!).
> 
> You are saying either way; however, my current understanding is that
> get_frame_memory is not currently any different from the above, but
> is still a better approach in the long run if we eventually want to be
> multi-everything.  Is it correct?

Yes.

> I am not sure if it is really worth fixing this sort of thing now, or
> worry about it later... You know the grand plan, so your call.

If the change is straight forward, might as well.  If it's a struggle, 
don't bother - I'll be looking over the code anyway to see where there 
are problems.  I'm also pretty sure that there is going to be a new 
architecture method so that:

	xxx_frame__yyy (get_frame_arch (frame), frame, ...)

can be written as:

	xxx_frame_yyy (frame, ....);

Anyway, to scare you :-)

There is some interest in fixing GDB's Java.  [insert manditory slander 
directed towards the old code] The current implementation has more 
limitiations than one can point a stick at.  Off the top of my head:
	- namespaces
	- bytecodes and a byte code target
	- backtraces through libffi
To get these working, it's going to be especially important to avoid 
globals such as current_gdbarch.

Anyway, I think the first thing is get the infrastructure working here.

Andrew