This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [Patch H8/300] : Fix for crashing of gdb with" info f" command
- From: Andrew Cagney <cagney at gnu dot org>
- To: Sherry Samuel <SherryS at KPITCummins dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 15 Jul 2004 14:18:55 -0400
- Subject: Re: [Patch H8/300] : Fix for crashing of gdb with" info f" command
- References: <4A1BE23A7B777442B60F4B4916AE0F130218AAA5@sohm.kpit.com>
Hi
Reference:http://sources.redhat.com/ml/gdb-patches/2004-06/msg00428.html
In the latest GDB(gdb+dejagnu-20040630) snap shot, the "info f" problem described in the above link is fixed. Referring through the links you have suggested, it is evident that h8300 target is not in the list of the new GDB frame structure. Is it possible to know what should be done from our side to update H8300 targets to the new frame work? Can you suggest how to go about it?
Thanks in advance.
Right,
A very simplistic cookbook is as follows:
- #if 0 all the set_gdbarch_deprecated ... lines
- build gdb
- try gdb on a simple program
break main, info registers, stepi, nexti, ...
- fix an internal error due to missing method
- repeat
eventually you'll get gdb kind of working, at that point repeat the
above using the testsuite.
It turns out that for architectures like this that use all the old
deprecated methods, its quicker / easier to clear the deck and implement
a new (borrowing heavily from the old code of course).
It also turns out that basic operations (break main; run, stepi, info
registers) don't even need a frame unwinder - so that can be left as a
separate pass.
For the unwinder, you need to convert the frame_saved_regs code into the
frame_unwind_cache code (seen in more up-to-date architectures).
As for contributing this, perhaphs we can just incrementally submit the
above in realtime?
Andrew