[PATCH] binutils: partially revert 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8

[徐持恒 Xu Chiheng]

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 (.*) }

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
>