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