[PATCH] binutils: partially revert 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8

[Jan Beulich]

On 18.11.2022 11:45, 徐持恒 Xu Chiheng wrote:
> using x86_64-elf-g++ -m32 -c on C++ files to generate head.o(32 bit
> code, elf32).
> using x86_64-elf-objcopy to convert it to elf64.
> then link head.o(32 bit code, elf64) with other object files(64 bit
> code, elf64).
> 
> link script line is :
>   .head           : { head.o (.multiboot) head.o (.*) }

Was that GNU objcopy you used? I've just tried here, and I don't see
it converting from REL to RELA.

And again: Please don't top-post. By doing so you're making it harder
to follow the flow of conversations.

Jan

> On Fri, Nov 18, 2022 at 6:34 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 18.11.2022 11:24, 徐持恒 Xu Chiheng wrote:
>>> Does that mean there is a bug in objcopy?
>>> x86_64-elf-objcopy failed to correctly convert a ELF32(USE_REL, addend
>>> is in section content) to ELF64(USE_RELA, addend is in relocation
>>> entry) .
>>> In other words,  x86_64-elf-objcopy just converts a REL relocation
>>> entry to a RELA relocation entry, without putting the addend in
>>> section content to the new RELA relocation entry.
>>
>> Possible, but I can't check without knowing more details about the
>> input object you did use.
>>
>> As an aside - please don't top-post.
>>
>> Jan
>>
>>> On Fri, Nov 18, 2022 at 6:01 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 18.11.2022 10:37, 徐持恒 Xu Chiheng via Binutils wrote:
>>>>> Sorry, but I really think this is a regression.
>>>>> 64 bit linker originally could do relocation on 32 bit object code. It
>>>>> worked perfectly.
>>>>
>>>> And it still can, provided you pass in well-formed 32-bit object files.
>>>>
>>>>> Setting src_mask to 0, ignores the addend value in the section content.
>>>>
>>>> Which is precisely what the ELF spec says the behavior is for RELA type
>>>> relocations. _Not_ ignoring section contents was the bug here.
>>>>
>>>> You are, btw, not the first one to notice this perceived regression. But
>>>> that still doesn't actually make it one. It is merely a change in
>>>> behavior to fix a long-standing bug.
>>>>
>>>> Jan
>>