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: Allow copy relocations with pie links


>> Right. With Sri's test case, we get an absolute R_386_32 relocation
>> for the access, and the DT_TEXTREL flag is set in the PIE binary
>> because of the text relocation. There is no COPY relocation. Since we
>> had a path in the code to check for copy relocs for the PC-relative
>> relocations, I think it makes sense to adjust the test there, though.
>
> It took me a while to understand this discussion.  I think I get it
> now, it looks like there is no need for me to change i386.cc as no
> data access can produce a pc relative relocation.  Cary, how do I
> think I should adjust the test?  The test itself passes on i386 even
> without the change.

I think your patch to i386.cc is fine. If it's possible to reach the
call to may_need_copy_reloc in the case that handles R_386_PCxx
relocations, it's correct to check for output_is_executable() instead
of !output_is_position_independent(). If the ABI forbids a compiler
from ever using one of those relocations to access global data, then
we won't ever reach the code anyway. To me, the choice is either to
patch it as you've done, or remove that whole if statement. Given that
the code is there and always has been, let's leave the patch as is.
There's always the chance that someone might write a bit of assembly
code that uses that relocation.

-cary


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