This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: Dynamically generated code and DWARF exception handling


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.


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