This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [RFC]: .eh_frame section in mingw32 executables
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- Cc: Tristan Gingold <gingold at adacore dot com>, Binutils <binutils at sourceware dot org>, Kai Tietz <ktietz70 at googlemail dot com>
- Date: Tue, 23 Jun 2009 09:53:58 -0700
- Subject: Re: [RFC]: .eh_frame section in mingw32 executables
- References: <F8629577-8DFF-404C-8D50-8D9AFEC422D6@adacore.com> <4A4108F8.4090508@gmail.com>
> Can you explain what it does, how it does it and why in a bit more detail
> please? You're changing the behaviour of relocatable links to keep the
> .eh_data in its own section instead of merging it into .rdata, yes?
That's correct.
The idea is to preserve the .eh_frame data in its own section so that
the debugger can use it. This is mostly for x86_64, where I'm struggling
with prologue instruction parsing in GDB in order to be able to unwind
from (optimized) routines in the GNAT runtime. It's basically a lost
battle, as there are so many variations of that prologue when code starts
getting optimized (and also because disassembling x86_64 instruction
a-la-mano is a nightmare). I think that, eventually, people will
want to have pdata/xdata support on x86_64, and we can also enhance
GDB to support that in the near future. But in the meantime, it would be
very convenient to have .eh_frame info available to make backtrace
computing much more solid on x86_64-windows.
Any reason why it would be bad to have that data in its own section
rather than being merged in .rdata?
--
Joel