[RFC/RFA/frame stuff] Fix build failure in alpha-osf1-tdep.c
Andrew Cagney
ac131313@redhat.com
Wed Jun 4 17:33:00 GMT 2003
>> >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
More information about the Gdb-patches
mailing list