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: Convert absolute personalities into PC-relative ones


Richard Sandiford <rdsandiford@googlemail.com> writes:
> As discussed with Mark recently, this patch allows the linker to turn
> absolute-but-locally-binding personality pointers into PC-relative ones,
> under the usual "info->shared && we support this" condition.  MIPS needs
> this to work for indirect pointers too, and that shows up a problem in
> the current elf-eh-frame.c code: it treats the top nibble as an enum
> of the base address, whereas DW_EH_PE_indirect is really a separate
> flag.  So, for example, when adjusting PC-relative offsets to account
> for things like removed CIEs and FDEs, we use:
>
>    (encoding & 0xf0) == DW_EH_PE_pcrel
>
> even though (AIUI) the adjustment ought to be applied to
> DW_EH_PE_pcrel | DW_EH_PE_indirect as well.
>
> The patch goes through elf-eh-frame.c and replaces 0xf0 with 0x70.
> This wasn't just mechanical though!  I did try to justify that each
> one was correct.  And I think each one is.  However:
>
> 	      switch (ent->fde_encoding & 0xf0)
> 		{
> 		case DW_EH_PE_indirect:
> 		case DW_EH_PE_textrel:
> 		  BFD_ASSERT (hdr_info == NULL);
> 		  break;
> 		case DW_EH_PE_datarel:
> 		  {
> 		    asection *got = bfd_get_section_by_name (abfd, ".got");
>
> 		    BFD_ASSERT (got != NULL);
> 		    address += got->vma;
> 		  }
> 		  break;
> 		case DW_EH_PE_pcrel:
> 		  value += (bfd_vma) ent->offset - ent->new_offset;
> 		  address += (sec->output_section->vma
> 			      + sec->output_offset
> 			      + ent->offset + 8);
> 		  break;
> 		}
>
> is an interesting case.  It seems to be asserting that we only have
> an .eh_frame_hdr (and thus only use "address") in cases where we can
> correctly calculate the address of the target code.  That sounds like
> a good idea in principle, but as mentioned above, we ought to exclude
> all DW_EH_PE_indirect encodings, not just:
>
>   DW_EH_PE_indirect | DW_EH_PE_absptr
>
> Admittedly that's probably only of academic interest, since no-one is
> likely to use indirect pointers for the FDE ranges (are they? ;-)).
>
> More importantly, we don't seem to actually enforce the asserted
> condition anywhere, so I'm wondering whether we ought to have
> something like the second (completely untested) patch as well.
>
> I tested the first patch in combination with the third (gcc) patch
> on mips64octeon-linux-gnu.  There were no regressions from unpatched
> GCC and binutils.  After the patches, libstdc++.so still has a read-only
> .eh_frame, but it is free from text relocations.
>
> Any objections to the first patch?  Any thoughts on the second?
> If the first patch is OK, is it too invasive for the branch?
> I'd ideally like to get this into 2.20, so that the feature is
> in a released binutils when GCC 4.5 comes out.

No objections, so I committed the first patch to trunk.
I won't press it for branch though.

Richard


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