This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FRAME_CHAIN() -> frame_id_unwind() ?


Hello,

This, I think, is the missing piece in making the frame code fully recursive.

A frame ID provides a frame unique identifer.  It includes the frame's stack address (for all stacks, the IA64 has two stacks) and the frame's code pointer.  A frame ID can be used for things like find a dummy-frame's data, or find the selected frame after a frame cache flush.

By asking the next frame to unwind the frame ID we get that unique identifier.  FRAME_CHAIN() only returns the frame pointer on the main stack so it, in the long run, isn't going to be sufficient.

Initially, for old code, frame_id_unwind() method would look something like:

    frame_id.base = FRAME_CHAIN() or FRAME_FP()
    frame_id.pc = FRAME_SAVED_PC(); /* aka frame_pc_unwind() */

And for a dummy-frame, it would be even simpler:

    // prev_id saved when dummy frame was created
    return dummy_frame->prev_id;

The CFI code could be implemented to do something equivalent.

This will give us:

    frame_register_unwind()
    frame_pc_unwind()
    frame_id_unwind()

Thoughts, at least on the principle?
I was asked, in private e-mail, which arcitecture should be examined in terms of how to currently implement things:

The short answer is ``dummy-frame.[ch]''!

The long answer is, dummy-frame.[hc] implements very simple self contained versions of the above functions (well it does in my sandpit). The code is straight forward enough for the principles to be apparent.

As for suggesting a reference architecture, tricky:

- Right now, the architectures are using one deprecated mechanism or another. A hybrid rs6000 / i386 is probably close. The registers -> deprecated_registers patches at least make the problem of figuring out where things are at easier.

- FRAME_CHAIN(), FRAME_SAVED_PC(), GET_SAVED_REGISTER(), while on notice, are still the only multi-arch hooks available for customizing an architectures. While its a safe bet that architecture vector will gain a per-architecture frame_id_unwind() frame_pc_unwind() and frame_register_unwind() and that dwarf2cfi will export cfi equivalents, I've no idea who will do it or when.

Andrew



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]