[PATCH] D29714: [ELF] - Do sign extend for addends of R_386_8, R_386_16 relocations

[George Rimar via llvm-commits]

>> grimar added a comment.
>>
>> In https://reviews.llvm.org/D29714#671060, @ruiu wrote:
>>
>>> Maybe we need to sign extend everything? In other words, is there any relocation that we shouldn't sign extend?
>>
>>
>> From my understanding we should extend only relocations that have addend value shorter than target size.
>>
>> I mean we return 64 bit value from getImplicitAddend(), it is then assigned to uintX_t. So for i386 case for example we want to extend >all relocations that are not reading 32 bits,
>> as anyways value is truncated later.
>> So I believe, for i386 this patch is all what else needed for it's relocations, all other ones are working with 32 bits already.
>
>I am sure the rule is not that generic. X86_64 explicitly has
>R_X86_64_32S since R_X86_64_32 is unsigned. I am sorry I haven't had the
>time to look deeper at this, but I really think the problem is somewhere
>else.
>
>Cheers,
>Rafael

Ok.
But there are no much choices here. Relocations are not a part of ABI, all we know it says them are truncated.

If we have for example R_I386_8 relocation and some value, lets say 5. And relocation is = -2 (0xFE). 
We can read it as 0xFFFFFFFE or 0x000000FE. (extended or not)
In both cases we have final value =
1) 5 + 0xFFFFFFFE = 0x03 = 0x3 after truncation.
2) 5 + 0x000000FE = 0x103. = 0x3 after truncation.

Second calulation would report out of range currently, though truncation to single byte, anyways produce similar value for
both ways. May be we could just remove truncation check then for now for R_i386_8/16 ? At least that wasy we can link that place
of linux kernel and still follow the ABI.

George.