This is the mail archive of the gcc-patches@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]

Re: [discuss] Re: [patches] Re: x86_64 frame unwind info


> On Wed, Oct 17, 2001 at 11:07:16PM +0200, Jan Hubicka wrote:
> > So solution I see is to invent new name for the unwind frame and add
> > target macros to get gcc write the eh-frame to that section and use
> > it for unwinding in similar way as IA-64 machinery works.
> 
> I don't see any point to that.

There is demand to allow standard way of stack unwinding of the code.
To my understanding this is mostly to allow Java runtimes garbage collect
non-conservativly in the JITs (they needs to see trought the C code to the
JIT compiled stack frames to track down the references).

If we will keep the current scheme of eh_frame emitted sometimes and
only for exception handling in internal gcc format and debug_frame
emit for debugging and strip by "strip", we still need some third frame
unwinding that can be used by the GC code.

Such info must be present, at least, in the all shared libraries so it
looks like good idea to me to commonize all those tasks to single section.

> 
> I don't see why you don't just leave well enough alone and let
> both sections be emitted.  If you're adamant against that, then
> go ahead and teach gdb about gcc's encoding formats.
> 
> Of course, you do realize that gdb doesn't even use .debug_frame

Jiri has mostly done so.  He has patches to gdb that are able
to grog .debug_frame and apears to works pretty well.

Honza

> yet, so there's no point in teaching it about the differences for
> .eh_frame until the former is complete.
> 
> 
> r~


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