Re: Using linker script to mark .debug_frame allocatable

[David Daney <ddaney at caviumnetworks dot com>]

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