Jakub Jelinek writes: > On Wed, May 03, 2006 at 10:14:23AM +0100, Andrew Haley wrote: > > Adding an entry point to register debug info should not be a big deal. > > We're going to need it for gcj when we add a JIT. > > > > Another interesting possibility would be runtime extensions to > > MD_FALLBACK_FRAME_STATE_FOR. That would be more flexible because it > > would allow us to use a JIT's native debug info, not just DWARF. > > Well, MD_FALLBACK_FRAME_STATE_FOR is used solely in the DWARF2/3 > unwinder. Furthermore, exposing the changing internals of the > unwinder sounds like very bad idea, just registering generated > .eh_frame with the unwinder sounds much better.
Well, I don't know it would be better, exactly. It certainly would fit in more closely with gcc's idea of the way the world works. Whether that is better or worse depends on how gcc-centric your view of the world is. > Alternatively, if the generated code always calls at most a handful > controlled entry points, one could write sophisticated unwind info > for those entry points that would not only unwind through that > entry point routine, but also through the generated code above it > and you wouldn't need any unwinder changes at all. That's true, but rather restrictive. I guess you'd have to call a precompiled lump of code at every entry and exit point to JITted code. Andrew.
