PATCH: Sign extend relocation result to 64bit for R_X86_64_DTPOFF64/R_X86_64_TPOFF64

[H.J. Lu]

On Tue, May 8, 2012 at 3:55 PM, Roland McGrath <roland@hack.frob.com> wrote:
>> https://sites.google.com/site/x32abi/documents
>>
>> most of relocations in x32 are applied to 32bit fields.
>
> OK.
>
>> > Then it can be just:
>> >
>> >        *reloc_addr = (Elf64_Sxword) (Elf32_Sword) value;
>>
>> Not all relocations use this computation.  I don't think we
>> should compute a value which is only used by a few relocations.
>
> Sorry I was not clear.  I just meant a local temporary in those cases to
> avoid having the same calculation on both forks of the #if, not anything
> superfluous.
>
>> > But it needs a comment saying why this particular reloc type gets sign
>> > extension when all the others get zero extension.
>> >
>>
>> Here is the updated patch with comments.  OK for trunk?
>
> Never say "64bit", always "64-bit" if an adjective.
>
> The comments are too terse.  Say something like:
>
> This relocation type computes a signed offset that is usually negative.
> The symbol and addend values are 32 bits but the GOT entry is 64 bits wide
> and the whole 64-bit entry is used as a signed quantity, so we need to
> sign-extend the computed value to 64 bits.
>

Here is the updated patch.  Since there already are

              /* We know the offset of the object the symbol is contained in.
                 It is a negative value which will be added to the
                 thread pointer.  */

I didn't repeat the negative offset in the second comment.
OK to install?

Thanks.

-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libc-x32-tls-2.patch
Type: application/octet-stream
Size: 1897 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20120508/fde6c666/attachment.obj>