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


"H.J. Lu" <hjl.tools@gmail.com> writes:
> On Sat, Sep 19, 2009 at 1:07 AM, Richard Sandiford
> <rdsandiford@googlemail.com> wrote:
>> 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.
>>
>
> Your change caused:
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=10681
>
> Could you please look into it?

The change is intentional, so I installed the patch below after
testing on x86_64-linux-gnu and i686-linux-gnu.  This also
accounts for the change I just committed to use sdata*
encodings where possible.

Richard


ld/testsuite/
	PR ld/10681
	* ld-elf/eh6.d: Expect absolute pointers in shared libraries to
	be converted into PC-relative form.

Index: ld/testsuite/ld-elf/eh6.d
===================================================================
--- ld/testsuite/ld-elf/eh6.d	2009-09-21 20:00:25.000000000 +0100
+++ ld/testsuite/ld-elf/eh6.d	2009-09-21 20:08:42.000000000 +0100
@@ -11,7 +11,7 @@ Contents of the .eh_frame section:
   Code alignment factor: 1
   Data alignment factor: .*
   Return address column: .*
-  Augmentation data:     80 .* 1b
+  Augmentation data:     9[bc] .* 1b
 
   DW_CFA_nop
 #pass


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