Re: [patch] allow suppression of fde encoding warning

[Richard Sandiford <rdsandiford at googlemail dot com>]

Replying here rather than downthread because it seems more relevant.

Sandra Loosemore <sandra@codesourcery.com> writes:
> While working on a new toolchain port (Altera Nios II), I was seeing 
> diagnostics like
>
> ld: fde encoding in /tmp/cceh1oVS.o(.eh_frame) prevents .eh_frame_hdr 
> table being created.
>
> on some test cases compiled with -fpie.
>
> My understanding of this warning is as follows.
>
> As an optimization, GNU ld tries to precompute lookup tables for some 
> exception handling information ("fde" == "Frame Description Entry") at 
> link time.  This warning is saying that it can't do so when generating a 
> position-independent executable because the eh data contains absolute 
> relocations.  Since these tables are only an optimization, it's not a 
> fatal error; the relocations will be fully resolved at runtime and the 
> eh library is supposed to DTRT in the absence of the linker-generated 
> tables.
>
> Google turned up a few references to this problem on other targets that 
> indicated that the "right" solution is for GCC to emit section-relative 
> references in the FDE data.  But, not all architectures support such a 
> thing in the ABI (and, in particular, the Nios II ABI doesn't have an 
> appropriate relocation for this purpose).  So, it seems like we should 
> be able to turn the warning off on architectures where the optimization 
> cannot possibly work.

FWIW: MIPS can't represent a PC-relative offset in relocatable objects
either, but elf-eh-frame.c tries pretty hard to convert absolute addresses
into PC-relative ones.  This is enough for --eh-frame-hdr to work correctly
(AFAIK) on mips*-linux-gnu.

I'd be interested to know why that code isn't kicking in for Nios II.
Maybe a simple extension would fix it, or maybe not :-)  The GCC backend
needs a definition like this (from MIPS) for the conversion to work:

/* As on most targets, we want the .eh_frame section to be read-only where
   possible.  And as on most targets, this means two things:

     (a) Non-locally-binding pointers must have an indirect encoding,
	 so that the addresses in the .eh_frame section itself become
	 locally-binding.

     (b) A shared library's .eh_frame section must encode locally-binding
	 pointers in a relative (relocation-free) form.

   However, MIPS has traditionally not allowed directives like:

	.long	x-.

   in cases where "x" is in a different section, or is not defined in the
   same assembly file.  We are therefore unable to emit the PC-relative
   form required by (b) at assembly time.

   Fortunately, the linker is able to convert absolute addresses into
   PC-relative addresses on our behalf.  Unfortunately, only certain
   versions of the linker know how to do this for indirect pointers,
   and for personality data.  We must fall back on using writable
   .eh_frame sections for shared libraries if the linker does not
   support this feature.  */
#define ASM_PREFERRED_EH_DATA_FORMAT(CODE,GLOBAL) \
  (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr)

As the comment says, having PC-relative encodings is useful not only
for the .eh_frame_hdr optimisation (which can be pretty important on its own),
but because it allows .eh_frame to go in the text rather than data segment.

Richard