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: gold patch: fix problem with TLS and 128-bit data on x86_64


"Cary Coutant" <ccoutant@google.com> writes:

>> Do we also need to use the addend in tls_gd_to_le, tls_desc_gd_to_le,
>> and tls_ie_to_le?
>
> I didn't think so, but I'm not so confident any more. In these cases,
> the original relocations call for the address of a GOT entry, so the
> use of any non-zero addend is messy. Should the relocation mean
> ((address of GOT entry for S) + A) or (address of GOT entry for (S +
> A))? Arguably, it's the latter that makes more sense, but that's not
> straightforward to implement (our table of GOT entries would have to
> be keyed by a <symbol, addend> pair), and it seems reasonable to
> require the addend to be zero for these relocations (we did require
> this on HP-UX for PA and Itanium). (Of course, if we're going to
> require that, we probably should print an error when we see a non-zero
> addend.) Thoughts?

Makes sense.  I agree that issuing a warning for a non-zero addend
would seem to be appropriate, since, if it means anything, we won't be
handling it correctly.  That may let us find the problem sooner, if
there is a problem.

I agree that if there is an added, it should mean (address of GOT
entry for (S + A)).

Ian


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