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: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Dave Korn <dave dot korn dot cygwin at googlemail dot com>, 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 19:58:28 +0100
- Subject: Re: [RFC]: .eh_frame section in mingw32 executables
- References: <F8629577-8DFF-404C-8D50-8D9AFEC422D6@adacore.com> <4A4108F8.4090508@gmail.com> <20090623165358.GM6469@adacore.com>
Joel Brobecker wrote:
>> 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?
I can't think of anything off the top of my head. Has this patch been in
production use anywhere for a while?
cheers,
DaveK