This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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: [RFC]: .eh_frame section in mingw32 executables


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


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