GDB Documentation and Request for Help
Michael Eager
eager@eagercon.com
Fri Mar 30 21:14:00 GMT 2007
Jim Blandy wrote:
> Daniel Jacobowitz <drow@false.org> writes:
>> On Fri, Mar 30, 2007 at 11:26:39AM -0700, Michael Eager wrote:
>>> Jim Blandy wrote:
>>>> If you post here, I think people would be happy to explain what's
>>>> current and what isn't. I'll watch for your messages.
>>> Thanks. I think that my questions are not very specific and
>>> it would be better to go through the Target Arch chapter
>>> and mark it up.
>>> But here goes: what did FRAME_INIT_SAVED get replaced by?
>> It got replaced by an entirely demand driven system. There's only two
>> entry points: this_id and prev_register. Every registered unwinder
>> provides both.
>
> Michael, your question suggests that you're looking at some code in
> your old port, and trying to figure out where it goes in your new
> port. I would find that a very hard question to answer if I were in
> your shoes. Instead, start by reading frame-unwind.h and having your
> foo_gdbarch_init function call frame_unwind_append_sniffer with a
> structure containing appropriate functions, written from scratch.
>
> In other words, you may be able to use the old port to understand how
> your target works, but you'll need to decide afresh how to express
> that understanding in the new arch description framework.
That's exactly the approach I'm taking.
> (Having worked on both, I think the new frame system is *much* nicer
> to work with, and more reliable. So your efforts won't be wasted.)
I'm sure that it is. It's just not documented. Reading code from
other targets to figure out what's needed is, well, challenging.
I'll take another look at frame-unwind.h.
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
More information about the Gdb
mailing list