Home Original page

Using linker script to mark .debug_frame allocatable

David Daney ddaney@caviumnetworks.com
Wed Jul 29 16:15:00 GMT 2009 
Matt Fleming wrote:
> On Wed, Jul 29, 2009 at 11:13:19AM -0400, Daniel Jacobowitz wrote:
>> On Wed, Jul 29, 2009 at 03:18:06PM +0100, Matt Fleming wrote:
>>> Basically because the DWARF frame info is currently in the .debug_frame
>>> section and I assumed that if no .eh_frame section was generated during
>>> the partial link of the kernel source, I can move the .debug_frame input
>>> section into a .eh_frame output section and it still wouldn't be
>>> allocatable.
>>>
>>> Is there a way to force all DWARF debug frame info to be output into a
>>> .eh_frame section?
>> Compile with unwind tables.  ARM's got an option to do this already
>> (though that does not result in .eh_frame - ARM is special - it would
>> on other platforms).
>>
> 
> I thought that the unwind tables had an architecture-specific layout? Or
> in any case, had more architecture-specific information encoded in their
> entries than the DWARF info in .debug_frame?
> 

DWARF based .eh_frame sections don't really have any 
architecture-specific things in them.  The register numbering 
conventions are not needed when unwinding, only if you wanted to catch 
an exception and restore the registers, which I don't think you do in 
the kernel.  I think the only architecture-specific code you would need 
is something to find the first CFA given the machine state at the unwind 
point.

I would compile the whole thing with -fasynchronous-unwind-tables or 
-funwind-tables and use the resulting .eh_frame sections.  That is what 
they are there for.  Trying to make .debug_frame into an allocatable 
section seems hacky to me.

Good luck, it is something I have thought about doing myself.

David Daney
More information about the Binutils mailing list