binutils: partially revert 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8
Checks
Commit Message
Phenomenal: In 32 bit and 64 bit mixed code, ld can't do relocation
for 32 bit code.
It is caused by commit 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8.
/* src_mask selects the part of the instruction (or data) to be used
in the relocation sum. If the target relocations don't have an
addend in the reloc, eg. ELF USE_REL, src_mask will normally equal
dst_mask to extract the addend from the section contents. If
relocations do have an addend in the reloc, eg. ELF USE_RELA, this
field should normally be zero. Non-zero values for ELF USE_RELA
targets should be viewed with suspicion as normally the value in
the dst_mask part of the section contents should be ignored. */
bfd_vma src_mask;
Author: Jan Beulich <jbeulich@suse.com> 2021-05-07 18:05:12
Committer: Jan Beulich <jbeulich@suse.com> 2021-05-07 18:05:12
Parent: 98da05bf2698b55b73453480a3fbb92f163d2c7b (x86: don't mix disp
and imm processing)
Child: 4cf88725da1cb503be04d3237354105ec170bc86 ([gdb/symtab] Fix
infinite recursion in dwarf2_cu::get_builder())
Branches: master, test0558-01 and many more (41)
Follows: gdb-10-branchpoint
Precedes: binutils-2_37, gdb-11-branchpoint
x86-64/ELF: clear src_mask for all reloc types
x86-64 uses rela relocations. The comment next to the field's declaration
says "Non-zero values for ELF USE_RELA targets should be viewed with
suspicion ..." And indeed the fields being non-zero causes section
contents to be accumulated into the final relocated values in addition to
the relocations' addends, which is contrary to the ELF spec.
bfd/elf64-x86-64.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
Comments
On Thu, Nov 17, 2022 at 9:44 AM 徐持恒 Xu Chiheng via Binutils
<binutils@sourceware.org> wrote:
>
> Phenomenal: In 32 bit and 64 bit mixed code, ld can't do relocation
> for 32 bit code.
> It is caused by commit 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8.
>
>
>
>
> /* src_mask selects the part of the instruction (or data) to be used
> in the relocation sum. If the target relocations don't have an
> addend in the reloc, eg. ELF USE_REL, src_mask will normally equal
> dst_mask to extract the addend from the section contents. If
> relocations do have an addend in the reloc, eg. ELF USE_RELA, this
> field should normally be zero. Non-zero values for ELF USE_RELA
> targets should be viewed with suspicion as normally the value in
> the dst_mask part of the section contents should be ignored. */
> bfd_vma src_mask;
>
>
>
> Author: Jan Beulich <jbeulich@suse.com> 2021-05-07 18:05:12
> Committer: Jan Beulich <jbeulich@suse.com> 2021-05-07 18:05:12
> Parent: 98da05bf2698b55b73453480a3fbb92f163d2c7b (x86: don't mix disp
> and imm processing)
> Child: 4cf88725da1cb503be04d3237354105ec170bc86 ([gdb/symtab] Fix
> infinite recursion in dwarf2_cu::get_builder())
> Branches: master, test0558-01 and many more (41)
> Follows: gdb-10-branchpoint
> Precedes: binutils-2_37, gdb-11-branchpoint
>
> x86-64/ELF: clear src_mask for all reloc types
>
> x86-64 uses rela relocations. The comment next to the field's declaration
> says "Non-zero values for ELF USE_RELA targets should be viewed with
> suspicion ..." And indeed the fields being non-zero causes section
> contents to be accumulated into the final relocated values in addition to
> the relocations' addends, which is contrary to the ELF spec.
Are you using NASM?
On Thu, Nov 17, 2022 at 10:28 AM 徐持恒 Xu Chiheng <chiheng.xu@gmail.com> wrote:
>
> No. not using NASM.
>
> using x86_64-elf-g++ -m32 to generate 32 bit code(elf32).
> using x86_64-elf-objcopy to convert it to elf64.
> then link the 32 bit code(elf64) with 64 bit code.
>
This is an unsupported operation.
H.J.
>
>
> ________________________________
> From: H.J. Lu <hjl.tools@gmail.com>
> Sent: Friday, November 18, 2022 02:06
> To: 徐持恒 Xu Chiheng <chiheng.xu@gmail.com>
> Cc: binutils@sourceware.org <binutils@sourceware.org>
> Subject: Re: [PATCH] binutils: partially revert 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8
>
> On Thu, Nov 17, 2022 at 9:44 AM 徐持恒 Xu Chiheng via Binutils
> <binutils@sourceware.org> wrote:
> >
> > Phenomenal: In 32 bit and 64 bit mixed code, ld can't do relocation
> > for 32 bit code.
> > It is caused by commit 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8.
> >
> >
> >
> >
> > /* src_mask selects the part of the instruction (or data) to be used
> > in the relocation sum. If the target relocations don't have an
> > addend in the reloc, eg. ELF USE_REL, src_mask will normally equal
> > dst_mask to extract the addend from the section contents. If
> > relocations do have an addend in the reloc, eg. ELF USE_RELA, this
> > field should normally be zero. Non-zero values for ELF USE_RELA
> > targets should be viewed with suspicion as normally the value in
> > the dst_mask part of the section contents should be ignored. */
> > bfd_vma src_mask;
> >
> >
> >
> > Author: Jan Beulich <jbeulich@suse.com> 2021-05-07 18:05:12
> > Committer: Jan Beulich <jbeulich@suse.com> 2021-05-07 18:05:12
> > Parent: 98da05bf2698b55b73453480a3fbb92f163d2c7b (x86: don't mix disp
> > and imm processing)
> > Child: 4cf88725da1cb503be04d3237354105ec170bc86 ([gdb/symtab] Fix
> > infinite recursion in dwarf2_cu::get_builder())
> > Branches: master, test0558-01 and many more (41)
> > Follows: gdb-10-branchpoint
> > Precedes: binutils-2_37, gdb-11-branchpoint
> >
> > x86-64/ELF: clear src_mask for all reloc types
> >
> > x86-64 uses rela relocations. The comment next to the field's declaration
> > says "Non-zero values for ELF USE_RELA targets should be viewed with
> > suspicion ..." And indeed the fields being non-zero causes section
> > contents to be accumulated into the final relocated values in addition to
> > the relocations' addends, which is contrary to the ELF spec.
>
> Are you using NASM?
>
> --
> H.J.
On Thu, Nov 17, 2022 at 11:01 AM 徐持恒 Xu Chiheng <chiheng.xu@gmail.com> wrote:
>
> binutils-2.36 and earlier works
> binutils-2.37 and later does not work.
It worked by accident before. May I ask why you want to do it this way?
> ________________________________
> From: H.J. Lu <hjl.tools@gmail.com>
> Sent: Friday, November 18, 2022 02:50
> To: 徐持恒 Xu Chiheng <chiheng.xu@gmail.com>
> Cc: binutils@sourceware.org <binutils@sourceware.org>
> Subject: Re: [PATCH] binutils: partially revert 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8
>
> On Thu, Nov 17, 2022 at 10:28 AM 徐持恒 Xu Chiheng <chiheng.xu@gmail.com> wrote:
> >
> > No. not using NASM.
> >
> > using x86_64-elf-g++ -m32 to generate 32 bit code(elf32).
> > using x86_64-elf-objcopy to convert it to elf64.
> > then link the 32 bit code(elf64) with 64 bit code.
> >
>
> This is an unsupported operation.
>
> H.J.
> >
> >
> > ________________________________
> > From: H.J. Lu <hjl.tools@gmail.com>
> > Sent: Friday, November 18, 2022 02:06
> > To: 徐持恒 Xu Chiheng <chiheng.xu@gmail.com>
> > Cc: binutils@sourceware.org <binutils@sourceware.org>
> > Subject: Re: [PATCH] binutils: partially revert 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8
> >
> > On Thu, Nov 17, 2022 at 9:44 AM 徐持恒 Xu Chiheng via Binutils
> > <binutils@sourceware.org> wrote:
> > >
> > > Phenomenal: In 32 bit and 64 bit mixed code, ld can't do relocation
> > > for 32 bit code.
> > > It is caused by commit 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8.
> > >
> > >
> > >
> > >
> > > /* src_mask selects the part of the instruction (or data) to be used
> > > in the relocation sum. If the target relocations don't have an
> > > addend in the reloc, eg. ELF USE_REL, src_mask will normally equal
> > > dst_mask to extract the addend from the section contents. If
> > > relocations do have an addend in the reloc, eg. ELF USE_RELA, this
> > > field should normally be zero. Non-zero values for ELF USE_RELA
> > > targets should be viewed with suspicion as normally the value in
> > > the dst_mask part of the section contents should be ignored. */
> > > bfd_vma src_mask;
> > >
> > >
> > >
> > > Author: Jan Beulich <jbeulich@suse.com> 2021-05-07 18:05:12
> > > Committer: Jan Beulich <jbeulich@suse.com> 2021-05-07 18:05:12
> > > Parent: 98da05bf2698b55b73453480a3fbb92f163d2c7b (x86: don't mix disp
> > > and imm processing)
> > > Child: 4cf88725da1cb503be04d3237354105ec170bc86 ([gdb/symtab] Fix
> > > infinite recursion in dwarf2_cu::get_builder())
> > > Branches: master, test0558-01 and many more (41)
> > > Follows: gdb-10-branchpoint
> > > Precedes: binutils-2_37, gdb-11-branchpoint
> > >
> > > x86-64/ELF: clear src_mask for all reloc types
> > >
> > > x86-64 uses rela relocations. The comment next to the field's declaration
> > > says "Non-zero values for ELF USE_RELA targets should be viewed with
> > > suspicion ..." And indeed the fields being non-zero causes section
> > > contents to be accumulated into the final relocated values in addition to
> > > the relocations' addends, which is contrary to the ELF spec.
> >
> > Are you using NASM?
> >
> > --
> > H.J.
>
>
>
> --
> H.J.
On Thu, Nov 17, 2022 at 11:29 AM 徐持恒 Xu Chiheng <chiheng.xu@gmail.com> wrote:
>
> In developing some kernel like program. It start as 32 bit mode, then switch to 64 bit mode. All code are written in C++(only with inline assembly, with no assembly file).
>
Please compile C++ code to assembly code and add .code32 to assembly
codes to tell
assembler to generate 32-bit instructions.
> ________________________________
> From: H.J. Lu <hjl.tools@gmail.com>
> Sent: Friday, November 18, 2022 03:11
> To: 徐持恒 Xu Chiheng <chiheng.xu@gmail.com>
> Cc: binutils@sourceware.org <binutils@sourceware.org>
> Subject: Re: [PATCH] binutils: partially revert 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8
>
> On Thu, Nov 17, 2022 at 11:01 AM 徐持恒 Xu Chiheng <chiheng.xu@gmail.com> wrote:
> >
> > binutils-2.36 and earlier works
> > binutils-2.37 and later does not work.
>
> It worked by accident before. May I ask why you want to do it this way?
>
> > ________________________________
> > From: H.J. Lu <hjl.tools@gmail.com>
> > Sent: Friday, November 18, 2022 02:50
> > To: 徐持恒 Xu Chiheng <chiheng.xu@gmail.com>
> > Cc: binutils@sourceware.org <binutils@sourceware.org>
> > Subject: Re: [PATCH] binutils: partially revert 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8
> >
> > On Thu, Nov 17, 2022 at 10:28 AM 徐持恒 Xu Chiheng <chiheng.xu@gmail.com> wrote:
> > >
> > > No. not using NASM.
> > >
> > > using x86_64-elf-g++ -m32 to generate 32 bit code(elf32).
> > > using x86_64-elf-objcopy to convert it to elf64.
> > > then link the 32 bit code(elf64) with 64 bit code.
> > >
> >
> > This is an unsupported operation.
> >
> > H.J.
> > >
> > >
> > > ________________________________
> > > From: H.J. Lu <hjl.tools@gmail.com>
> > > Sent: Friday, November 18, 2022 02:06
> > > To: 徐持恒 Xu Chiheng <chiheng.xu@gmail.com>
> > > Cc: binutils@sourceware.org <binutils@sourceware.org>
> > > Subject: Re: [PATCH] binutils: partially revert 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8
> > >
> > > On Thu, Nov 17, 2022 at 9:44 AM 徐持恒 Xu Chiheng via Binutils
> > > <binutils@sourceware.org> wrote:
> > > >
> > > > Phenomenal: In 32 bit and 64 bit mixed code, ld can't do relocation
> > > > for 32 bit code.
> > > > It is caused by commit 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8.
> > > >
> > > >
> > > >
> > > >
> > > > /* src_mask selects the part of the instruction (or data) to be used
> > > > in the relocation sum. If the target relocations don't have an
> > > > addend in the reloc, eg. ELF USE_REL, src_mask will normally equal
> > > > dst_mask to extract the addend from the section contents. If
> > > > relocations do have an addend in the reloc, eg. ELF USE_RELA, this
> > > > field should normally be zero. Non-zero values for ELF USE_RELA
> > > > targets should be viewed with suspicion as normally the value in
> > > > the dst_mask part of the section contents should be ignored. */
> > > > bfd_vma src_mask;
> > > >
> > > >
> > > >
> > > > Author: Jan Beulich <jbeulich@suse.com> 2021-05-07 18:05:12
> > > > Committer: Jan Beulich <jbeulich@suse.com> 2021-05-07 18:05:12
> > > > Parent: 98da05bf2698b55b73453480a3fbb92f163d2c7b (x86: don't mix disp
> > > > and imm processing)
> > > > Child: 4cf88725da1cb503be04d3237354105ec170bc86 ([gdb/symtab] Fix
> > > > infinite recursion in dwarf2_cu::get_builder())
> > > > Branches: master, test0558-01 and many more (41)
> > > > Follows: gdb-10-branchpoint
> > > > Precedes: binutils-2_37, gdb-11-branchpoint
> > > >
> > > > x86-64/ELF: clear src_mask for all reloc types
> > > >
> > > > x86-64 uses rela relocations. The comment next to the field's declaration
> > > > says "Non-zero values for ELF USE_RELA targets should be viewed with
> > > > suspicion ..." And indeed the fields being non-zero causes section
> > > > contents to be accumulated into the final relocated values in addition to
> > > > the relocations' addends, which is contrary to the ELF spec.
> > >
> > > Are you using NASM?
> > >
> > > --
> > > H.J.
> >
> >
> >
> > --
> > H.J.
>
>
>
> --
> H.J.
Sorry, but I really think this is a regression.
64 bit linker originally could do relocation on 32 bit object code. It
worked perfectly.
Setting src_mask to 0, ignores the addend value in the section content.
On Fri, Nov 18, 2022 at 4:15 AM 徐持恒 Xu Chiheng <chiheng.xu@gmail.com> wrote:
>
> Sorry, but I really think this is a regession.
> 64 bit linker orginally could do relocation on 32 bit object code. It worked perfectly.
> Setting src_mask to 0, ignore the addend value in the section content.
>
> ________________________________
> From: H.J. Lu <hjl.tools@gmail.com>
> Sent: Friday, November 18, 2022 03:51
> To: 徐持恒 Xu Chiheng <chiheng.xu@gmail.com>
> Cc: binutils@sourceware.org <binutils@sourceware.org>
> Subject: Re: [PATCH] binutils: partially revert 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8
>
> On Thu, Nov 17, 2022 at 11:29 AM 徐持恒 Xu Chiheng <chiheng.xu@gmail.com> wrote:
> >
> > In developing some kernel like program. It start as 32 bit mode, then switch to 64 bit mode. All code are written in C++(only with inline assembly, with no assembly file).
> >
>
> Please compile C++ code to assembly code and add .code32 to assembly
> codes to tell
> assembler to generate 32-bit instructions.
>
> > ________________________________
> > From: H.J. Lu <hjl.tools@gmail.com>
> > Sent: Friday, November 18, 2022 03:11
> > To: 徐持恒 Xu Chiheng <chiheng.xu@gmail.com>
> > Cc: binutils@sourceware.org <binutils@sourceware.org>
> > Subject: Re: [PATCH] binutils: partially revert 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8
> >
> > On Thu, Nov 17, 2022 at 11:01 AM 徐持恒 Xu Chiheng <chiheng.xu@gmail.com> wrote:
> > >
> > > binutils-2.36 and earlier works
> > > binutils-2.37 and later does not work.
> >
> > It worked by accident before. May I ask why you want to do it this way?
> >
> > > ________________________________
> > > From: H.J. Lu <hjl.tools@gmail.com>
> > > Sent: Friday, November 18, 2022 02:50
> > > To: 徐持恒 Xu Chiheng <chiheng.xu@gmail.com>
> > > Cc: binutils@sourceware.org <binutils@sourceware.org>
> > > Subject: Re: [PATCH] binutils: partially revert 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8
> > >
> > > On Thu, Nov 17, 2022 at 10:28 AM 徐持恒 Xu Chiheng <chiheng.xu@gmail.com> wrote:
> > > >
> > > > No. not using NASM.
> > > >
> > > > using x86_64-elf-g++ -m32 to generate 32 bit code(elf32).
> > > > using x86_64-elf-objcopy to convert it to elf64.
> > > > then link the 32 bit code(elf64) with 64 bit code.
> > > >
> > >
> > > This is an unsupported operation.
> > >
> > > H.J.
> > > >
> > > >
> > > > ________________________________
> > > > From: H.J. Lu <hjl.tools@gmail.com>
> > > > Sent: Friday, November 18, 2022 02:06
> > > > To: 徐持恒 Xu Chiheng <chiheng.xu@gmail.com>
> > > > Cc: binutils@sourceware.org <binutils@sourceware.org>
> > > > Subject: Re: [PATCH] binutils: partially revert 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8
> > > >
> > > > On Thu, Nov 17, 2022 at 9:44 AM 徐持恒 Xu Chiheng via Binutils
> > > > <binutils@sourceware.org> wrote:
> > > > >
> > > > > Phenomenal: In 32 bit and 64 bit mixed code, ld can't do relocation
> > > > > for 32 bit code.
> > > > > It is caused by commit 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > /* src_mask selects the part of the instruction (or data) to be used
> > > > > in the relocation sum. If the target relocations don't have an
> > > > > addend in the reloc, eg. ELF USE_REL, src_mask will normally equal
> > > > > dst_mask to extract the addend from the section contents. If
> > > > > relocations do have an addend in the reloc, eg. ELF USE_RELA, this
> > > > > field should normally be zero. Non-zero values for ELF USE_RELA
> > > > > targets should be viewed with suspicion as normally the value in
> > > > > the dst_mask part of the section contents should be ignored. */
> > > > > bfd_vma src_mask;
> > > > >
> > > > >
> > > > >
> > > > > Author: Jan Beulich <jbeulich@suse.com> 2021-05-07 18:05:12
> > > > > Committer: Jan Beulich <jbeulich@suse.com> 2021-05-07 18:05:12
> > > > > Parent: 98da05bf2698b55b73453480a3fbb92f163d2c7b (x86: don't mix disp
> > > > > and imm processing)
> > > > > Child: 4cf88725da1cb503be04d3237354105ec170bc86 ([gdb/symtab] Fix
> > > > > infinite recursion in dwarf2_cu::get_builder())
> > > > > Branches: master, test0558-01 and many more (41)
> > > > > Follows: gdb-10-branchpoint
> > > > > Precedes: binutils-2_37, gdb-11-branchpoint
> > > > >
> > > > > x86-64/ELF: clear src_mask for all reloc types
> > > > >
> > > > > x86-64 uses rela relocations. The comment next to the field's declaration
> > > > > says "Non-zero values for ELF USE_RELA targets should be viewed with
> > > > > suspicion ..." And indeed the fields being non-zero causes section
> > > > > contents to be accumulated into the final relocated values in addition to
> > > > > the relocations' addends, which is contrary to the ELF spec.
> > > >
> > > > Are you using NASM?
> > > >
> > > > --
> > > > H.J.
> > >
> > >
> > >
> > > --
> > > H.J.
> >
> >
> >
> > --
> > H.J.
>
>
>
> --
> H.J.
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
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.
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
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
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
>
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
>>
(re-sending with binutils@ re-added to Cc; please don't send private
mail for stuff which belongs on the list)
On 18.11.2022 14:57, 徐持恒 Xu Chiheng wrote:
> x86_64-elf-g++ -c -O3 -ffreestanding -fno-builtin -fno-pic -m32
> -mcmodel=32 ... kern/core/x64/head/start32.cpp -o
> kern/core/x64/head/start32.cpp.o
> x86_64-elf-objcopy -I elf32-i386 -O elf64-x86-64
Well, I saw no need to use -I, but otherwise that's what I did. Yet you
quoting the commands you issued still doesn't answer ...
> kern/core/x64/head/start32.cpp.o kern/core/x64/head/start32.cpp.o
> x86_64-elf-g++ -nostdlib -v -fuse-ld=bfd -Wl,-v,--verbose -Wl,-r
> kern/core/x64/head/start32.cpp.o ... -o head.o
>
> On Fri, Nov 18, 2022 at 9:31 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> 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.
... which objcopy you used. Iirc llvm/clang also provide one, for example.
Jan
On 18.11.2022 15:07, 徐持恒 Xu Chiheng wrote:
> On Fri, Nov 18, 2022 at 10:02 PM Jan Beulich <jbeulich@suse.com> wrote:
>>> x86_64-elf-objcopy -I elf32-i386 -O elf64-x86-64
>>
>> Well, I saw no need to use -I, but otherwise that's what I did. Yet you
>> quoting the commands you issued still doesn't answer ...
> answer what ?
>>
>>
>> ... which objcopy you used. Iirc llvm/clang also provide one, for example.
>>
> Just binutils 's objcopy.
Then I can't tell why it's behaving differently for you and me. Did you
check "objcopy --version" output?
Jan
On Fri, Nov 18, 2022 at 10:09 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> Then I can't tell why it's behaving differently for you and me. Did you
> check "objcopy --version" output?
>
just my build of gcc cross toolchain. binutils version is 2.36.
2.36 works.
2.37 does not work, due to the commit 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8
On Fri, Nov 18, 2022 at 9:31 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> 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.
>
x86_64-elf-objcopy -I elf32-i386 -O elf64-x86-64
kern/core/x64/head/start32.cpp.o kern/core/x64/head/start32.cpp.o
How does binutils's objcopy convert ELF32(USE_REL) to ELF64(USE_RELA)?
How does it process relocation entry?
Right now, I'm not familiar with objcopy. I need to read the code.
On 18.11.2022 15:35, 徐持恒 Xu Chiheng wrote:
> On Fri, Nov 18, 2022 at 9:31 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> 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.
>>
>
> x86_64-elf-objcopy -I elf32-i386 -O elf64-x86-64
> kern/core/x64/head/start32.cpp.o kern/core/x64/head/start32.cpp.o
Okay, I've tried with 2.36.1 as well and I've also added the (in
principle unnecessary) -I option, but no difference. One reason for
the differing behavior may be that, judging by the naming of the tool
you use, you may have configured for x86_64-elf, whereas I'm using
x86_64-linux. I might be suspecting misbehavior elsewhere, and since
you didn't actually demonstrate the behavior, could you please attach
both input and output objects you pass into / get out of objcopy?
Jan
On Mon, Nov 21, 2022 at 3:53 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> you didn't actually demonstrate the behavior, could you please attach
> both input and output objects you pass into / get out of objcopy?
>
x86_64-elf-g++ -c -O3
-DGIT_COMMIT=\""01c3a0a4688485d80cd2bc12ceb06709de32f365"\"
-ffreestanding -fno-builtin -fvisibility=hidden
-fno-omit-frame-pointer -fno-optimize-sibling-calls -Wall -Wextra
-Werror -Wno-address -Wno-strict-aliasing -Wno-unused-parameter
-Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable
-Wno-nonnull-compare -Wno-array-bounds -Wno-cast-function-type
-Wno-stringop-overflow -Wno-implicit-fallthrough -march=x86-64
-mno-red-zone -mno-80387 -mno-mmx -msse2 -fno-use-cxa-atexit
-fno-rtti -fno-exceptions -fsized-deallocation -Woverloaded-virtual
-Wnamespaces -Wtemplates -Wvirtual-inheritance -Wno-invalid-offsetof
-Wno-pmf-conversions -MMD -MP -D__KernelGenius__
-I/cygdrive/c/Users/Administrator/OS/os/include
-I/cygdrive/c/Users/Administrator/OS/os/include/kernel/x64
-I/cygdrive/c/Users/Administrator/OS/os/kern/include
-I/cygdrive/c/Users/Administrator/OS/os/kern/core/x64/include
-mtune=intel -mno-80387 -mno-mmx -mno-sse -mno-sse2 -mno-sse3
-mno-ssse3 -mno-sse4 -mno-sse4a -mno-sse4.1 -mno-sse4.2 -mno-avx
-mno-avx2 -mno-avx512f -mno-avx512pf -mno-avx512er -mno-avx512cd
-mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512ifma
-mno-avx512vbmi -mno-sha -mno-aes -mno-pclmul -mno-clflushopt
-mno-clwb -mno-fsgsbase -mno-ptwrite -mno-rdrnd -mno-f16c -mno-fma
-mno-pconfig -mno-wbnoinvd -mno-fma4 -mno-prfchw -mno-rdpid
-mno-prefetchwt1 -mno-rdseed -mno-sgx -mno-xop -mno-lwp -mno-3dnow
-mno-3dnowa -mno-popcnt -mno-abm -mno-adx -mno-bmi -mno-bmi2
-mno-lzcnt -mno-fxsr -mno-xsave -mno-xsaveopt -mno-xsavec -mno-xsaves
-mno-rtm -mno-hle -mno-tbm -mno-mwaitx -mno-clzero -mno-pku
-mno-avx512vbmi2 -mno-avx512bf16 -mno-gfni -mno-vaes -mno-waitpkg
-mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b
-mno-enqcmd -mno-uintr -mno-tsxldtrk -mno-avx512vpopcntdq
-mno-avx512vp2intersect -mno-avx5124fmaps -mno-avx512vnni -mno-avxvnni
-mno-avx5124vnniw -mno-cldemote -mno-serialize -mno-amx-tile
-mno-amx-int8 -mno-amx-bf16 -mno-hreset -mno-kl -mno-widekl -fno-pic
-m32 -mcmodel=32
/cygdrive/c/Users/Administrator/OS/os/kern/core/x64/head/start32.cpp
-o kern/core/x64/head/start32.cpp.o.32
x86_64-elf-objcopy -I elf32-i386 -O elf64-x86-64
kern/core/x64/head/start32.cpp.o.32 kern/core/x64/head/start32.cpp.o
On Mon, Nov 21, 2022 at 4:30 PM 徐持恒 Xu Chiheng <chiheng.xu@gmail.com> wrote:
>
> On Mon, Nov 21, 2022 at 3:53 PM Jan Beulich <jbeulich@suse.com> wrote:
> >
> > you didn't actually demonstrate the behavior, could you please attach
> > both input and output objects you pass into / get out of objcopy?
> >
>
clang++ -target x86_64-elf -c -O3
-DGIT_COMMIT=\""01c3a0a4688485d80cd2bc12ceb06709de32f365"\"
-ffreestanding -fno-builtin -fvisibility=hidden
-fno-omit-frame-pointer -fno-optimize-sibling-calls -Wall -Wextra
-Werror -Wno-address -Wno-strict-aliasing -Wno-unused-parameter
-Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable
-Wno-nonnull-compare -Wno-array-bounds -Wno-cast-function-type
-Wno-stringop-overflow -Wno-implicit-fallthrough
-Wno-unknown-warning-option -Wno-unknown-attributes
-Wno-inline-new-delete -Wno-null-dereference -Wno-unused-private-field
-Wno-undefined-bool-conversion -Wno-c99-designator
-Wno-null-pointer-subtraction -fuse-init-array -march=x86-64
-mno-red-zone -mno-80387 -mno-mmx -msse2 -fno-use-cxa-atexit
-fno-rtti -fno-exceptions -fsized-deallocation -Woverloaded-virtual
-Wnamespaces -Wtemplates -Wvirtual-inheritance -Wno-invalid-offsetof
-Wno-pmf-conversions -MMD -MP -D__KernelGenius__
-I/cygdrive/c/Users/Administrator/OS/os/include
-I/cygdrive/c/Users/Administrator/OS/os/include/kernel/x64
-I/cygdrive/c/Users/Administrator/OS/os/kern/include
-I/cygdrive/c/Users/Administrator/OS/os/kern/core/x64/include
-mno-3dnow -mno-3dnowa -mno-adx -mno-aes -mno-amx-bf16 -mno-amx-int8
-mno-amx-tile -mno-avx -mno-avx2 -mno-avx512bf16 -mno-avx512bitalg
-mno-avx512bw -mno-avx512cd -mno-avx512dq -mno-avx512er -mno-avx512f
-mno-avx512ifma -mno-avx512pf -mno-avx512vbmi -mno-avx512vbmi2
-mno-avx512vl -mno-avx512vnni -mno-avx512vp2intersect
-mno-avx512vpopcntdq -mno-avxvnni -mno-bmi -mno-bmi2 -mno-cldemote
-mno-clflushopt -mno-clwb -mno-clzero -mno-cx16 -mno-enqcmd -mno-f16c
-mno-fma -mno-fma4 -mno-fsgsbase -mno-fxsr -mno-gfni -mno-hreset
-mno-invpcid -mno-kl -mno-lwp -mno-lzcnt -mno-mmx -mno-movbe
-mno-movdir64b -mno-movdiri -mno-mwaitx -mno-pclmul -mno-pconfig
-mno-pku -mno-popcnt -mno-prefetchwt1 -mno-prfchw -mno-ptwrite
-mno-rdpid -mno-rdrnd -mno-rdseed -mno-retpoline-external-thunk
-mno-rtm -mno-sahf -mno-serialize -mno-sgx -mno-sha -mno-shstk
-mno-sse -mno-sse2 -mno-sse3 -mno-sse4.1 -mno-sse4.2 -mno-sse4
-mno-sse4a -mno-ssse3 -mno-tbm -mno-tsxldtrk -mno-uintr -mno-vaes
-mno-vpclmulqdq -mno-vzeroupper -mno-waitpkg -mno-wbnoinvd -mno-widekl
-mno-x87 -mno-xop -mno-xsave -mno-xsavec -mno-xsaveopt -mno-xsaves
-fno-pic -m32 -mcmodel=small
/cygdrive/c/Users/Administrator/OS/os/kern/core/x64/head/start32.cpp
-o kern/core/x64/head/start32.cpp.o.32
x86_64-elf-objcopy -I elf32-i386 -O elf64-x86-64
kern/core/x64/head/start32.cpp.o.32 kern/core/x64/head/start32.cpp.o
On 21.11.2022 09:30, 徐持恒 Xu Chiheng wrote:
> On Mon, Nov 21, 2022 at 3:53 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> you didn't actually demonstrate the behavior, could you please attach
>> both input and output objects you pass into / get out of objcopy?
>>
>
> x86_64-elf-g++ -c -O3
> -DGIT_COMMIT=\""01c3a0a4688485d80cd2bc12ceb06709de32f365"\"
> -ffreestanding -fno-builtin -fvisibility=hidden
> -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wall -Wextra
> -Werror -Wno-address -Wno-strict-aliasing -Wno-unused-parameter
> -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable
> -Wno-nonnull-compare -Wno-array-bounds -Wno-cast-function-type
> -Wno-stringop-overflow -Wno-implicit-fallthrough -march=x86-64
> -mno-red-zone -mno-80387 -mno-mmx -msse2 -fno-use-cxa-atexit
> -fno-rtti -fno-exceptions -fsized-deallocation -Woverloaded-virtual
> -Wnamespaces -Wtemplates -Wvirtual-inheritance -Wno-invalid-offsetof
> -Wno-pmf-conversions -MMD -MP -D__KernelGenius__
> -I/cygdrive/c/Users/Administrator/OS/os/include
> -I/cygdrive/c/Users/Administrator/OS/os/include/kernel/x64
> -I/cygdrive/c/Users/Administrator/OS/os/kern/include
> -I/cygdrive/c/Users/Administrator/OS/os/kern/core/x64/include
> -mtune=intel -mno-80387 -mno-mmx -mno-sse -mno-sse2 -mno-sse3
> -mno-ssse3 -mno-sse4 -mno-sse4a -mno-sse4.1 -mno-sse4.2 -mno-avx
> -mno-avx2 -mno-avx512f -mno-avx512pf -mno-avx512er -mno-avx512cd
> -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512ifma
> -mno-avx512vbmi -mno-sha -mno-aes -mno-pclmul -mno-clflushopt
> -mno-clwb -mno-fsgsbase -mno-ptwrite -mno-rdrnd -mno-f16c -mno-fma
> -mno-pconfig -mno-wbnoinvd -mno-fma4 -mno-prfchw -mno-rdpid
> -mno-prefetchwt1 -mno-rdseed -mno-sgx -mno-xop -mno-lwp -mno-3dnow
> -mno-3dnowa -mno-popcnt -mno-abm -mno-adx -mno-bmi -mno-bmi2
> -mno-lzcnt -mno-fxsr -mno-xsave -mno-xsaveopt -mno-xsavec -mno-xsaves
> -mno-rtm -mno-hle -mno-tbm -mno-mwaitx -mno-clzero -mno-pku
> -mno-avx512vbmi2 -mno-avx512bf16 -mno-gfni -mno-vaes -mno-waitpkg
> -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b
> -mno-enqcmd -mno-uintr -mno-tsxldtrk -mno-avx512vpopcntdq
> -mno-avx512vp2intersect -mno-avx5124fmaps -mno-avx512vnni -mno-avxvnni
> -mno-avx5124vnniw -mno-cldemote -mno-serialize -mno-amx-tile
> -mno-amx-int8 -mno-amx-bf16 -mno-hreset -mno-kl -mno-widekl -fno-pic
> -m32 -mcmodel=32
> /cygdrive/c/Users/Administrator/OS/os/kern/core/x64/head/start32.cpp
> -o kern/core/x64/head/start32.cpp.o.32
>
> x86_64-elf-objcopy -I elf32-i386 -O elf64-x86-64
> kern/core/x64/head/start32.cpp.o.32 kern/core/x64/head/start32.cpp.o
So how did you conclude start32.cpp.o uses RELA relocations? .rel.text
is SHT_REL, not SHT_RELA, and so are other .rel.* sections. Which
actually supports my suspicion that SHT_REL aren't correctly handled
when linking, perhaps first and foremost because the x86-64 ABI
specifies that only RELA relocations are to be used. Whether, in that
light, it is valid for objcopy to produce SHT_REL output without any
warning is another question.
Jan
On 21.11.2022 10:02, Jan Beulich wrote:
> On 21.11.2022 09:30, 徐持恒 Xu Chiheng wrote:
>> On Mon, Nov 21, 2022 at 3:53 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>
>>> you didn't actually demonstrate the behavior, could you please attach
>>> both input and output objects you pass into / get out of objcopy?
>>>
>>
>> x86_64-elf-g++ -c -O3
>> -DGIT_COMMIT=\""01c3a0a4688485d80cd2bc12ceb06709de32f365"\"
>> -ffreestanding -fno-builtin -fvisibility=hidden
>> -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wall -Wextra
>> -Werror -Wno-address -Wno-strict-aliasing -Wno-unused-parameter
>> -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable
>> -Wno-nonnull-compare -Wno-array-bounds -Wno-cast-function-type
>> -Wno-stringop-overflow -Wno-implicit-fallthrough -march=x86-64
>> -mno-red-zone -mno-80387 -mno-mmx -msse2 -fno-use-cxa-atexit
>> -fno-rtti -fno-exceptions -fsized-deallocation -Woverloaded-virtual
>> -Wnamespaces -Wtemplates -Wvirtual-inheritance -Wno-invalid-offsetof
>> -Wno-pmf-conversions -MMD -MP -D__KernelGenius__
>> -I/cygdrive/c/Users/Administrator/OS/os/include
>> -I/cygdrive/c/Users/Administrator/OS/os/include/kernel/x64
>> -I/cygdrive/c/Users/Administrator/OS/os/kern/include
>> -I/cygdrive/c/Users/Administrator/OS/os/kern/core/x64/include
>> -mtune=intel -mno-80387 -mno-mmx -mno-sse -mno-sse2 -mno-sse3
>> -mno-ssse3 -mno-sse4 -mno-sse4a -mno-sse4.1 -mno-sse4.2 -mno-avx
>> -mno-avx2 -mno-avx512f -mno-avx512pf -mno-avx512er -mno-avx512cd
>> -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512ifma
>> -mno-avx512vbmi -mno-sha -mno-aes -mno-pclmul -mno-clflushopt
>> -mno-clwb -mno-fsgsbase -mno-ptwrite -mno-rdrnd -mno-f16c -mno-fma
>> -mno-pconfig -mno-wbnoinvd -mno-fma4 -mno-prfchw -mno-rdpid
>> -mno-prefetchwt1 -mno-rdseed -mno-sgx -mno-xop -mno-lwp -mno-3dnow
>> -mno-3dnowa -mno-popcnt -mno-abm -mno-adx -mno-bmi -mno-bmi2
>> -mno-lzcnt -mno-fxsr -mno-xsave -mno-xsaveopt -mno-xsavec -mno-xsaves
>> -mno-rtm -mno-hle -mno-tbm -mno-mwaitx -mno-clzero -mno-pku
>> -mno-avx512vbmi2 -mno-avx512bf16 -mno-gfni -mno-vaes -mno-waitpkg
>> -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b
>> -mno-enqcmd -mno-uintr -mno-tsxldtrk -mno-avx512vpopcntdq
>> -mno-avx512vp2intersect -mno-avx5124fmaps -mno-avx512vnni -mno-avxvnni
>> -mno-avx5124vnniw -mno-cldemote -mno-serialize -mno-amx-tile
>> -mno-amx-int8 -mno-amx-bf16 -mno-hreset -mno-kl -mno-widekl -fno-pic
>> -m32 -mcmodel=32
>> /cygdrive/c/Users/Administrator/OS/os/kern/core/x64/head/start32.cpp
>> -o kern/core/x64/head/start32.cpp.o.32
>>
>> x86_64-elf-objcopy -I elf32-i386 -O elf64-x86-64
>> kern/core/x64/head/start32.cpp.o.32 kern/core/x64/head/start32.cpp.o
>
> So how did you conclude start32.cpp.o uses RELA relocations? .rel.text
> is SHT_REL, not SHT_RELA, and so are other .rel.* sections. Which
> actually supports my suspicion that SHT_REL aren't correctly handled
> when linking, perhaps first and foremost because the x86-64 ABI
> specifies that only RELA relocations are to be used. Whether, in that
> light, it is valid for objcopy to produce SHT_REL output without any
> warning is another question.
Note this sentence in documentation of objcopy: "However, copying a
relocatable object file between any two formats may not work as
expected."
Jan
On Mon, Nov 21, 2022 at 5:02 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> So how did you conclude start32.cpp.o uses RELA relocations? .rel.text
> is SHT_REL, not SHT_RELA, and so are other .rel.* sections. Which
> actually supports my suspicion that SHT_REL aren't correctly handled
> when linking, perhaps first and foremost because the x86-64 ABI
> specifies that only RELA relocations are to be used. Whether, in that
> light, it is valid for objcopy to produce SHT_REL output without any
> warning is another question.
>
I'm not an expert, that was all my guess.
It is clear now that x86-64 linker treats the REL relocation entries
as RELA relocation entries, when doing relocation, it does not count
the addend in section content, because src_mask is set to 0.
Then can objcopy transform the REL relocation entries to RELA
relocation entries, so the x86-64 linker can consume them correctly ?
On 21.11.2022 10:21, 徐持恒 Xu Chiheng wrote:
> On Mon, Nov 21, 2022 at 5:02 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> So how did you conclude start32.cpp.o uses RELA relocations? .rel.text
>> is SHT_REL, not SHT_RELA, and so are other .rel.* sections. Which
>> actually supports my suspicion that SHT_REL aren't correctly handled
>> when linking, perhaps first and foremost because the x86-64 ABI
>> specifies that only RELA relocations are to be used. Whether, in that
>> light, it is valid for objcopy to produce SHT_REL output without any
>> warning is another question.
>>
> I'm not an expert, that was all my guess.
>
> It is clear now that x86-64 linker treats the REL relocation entries
> as RELA relocation entries, when doing relocation, it does not count
> the addend in section content, because src_mask is set to 0.
>
> Then can objcopy transform the REL relocation entries to RELA
> relocation entries, so the x86-64 linker can consume them correctly ?
It probably could, but I have no idea how to invasive this would end
up being.
Jan
On Mon, Nov 21, 2022 at 5:52 PM Jan Beulich <jbeulich@suse.com> wrote:
> >
> > It is clear now that x86-64 linker treats the REL relocation entries
> > as RELA relocation entries, when doing relocation, it does not count
> > the addend in section content, because src_mask is set to 0.
> >
> > Then can objcopy transform the REL relocation entries to RELA
> > relocation entries, so the x86-64 linker can consume them correctly ?
>
> It probably could, but I have no idea how to invasive this would end
> up being.
>
A much simpler solution is to let the linker accept the slightly
non-ABI-conformant ELF64(with both REL and RELA relocation entries).
The use of src_mask is dependent on whether relocation entry is REL or RELA.
@@ -50,13 +50,13 @@ static reloc_howto_type x86_64_elf_howto_table[] =
bfd_elf_generic_reloc, "R_X86_64_64", false, 0, MINUS_ONE,
false),
HOWTO(R_X86_64_PC32, 0, 4, 32, true, 0, complain_overflow_signed,
- bfd_elf_generic_reloc, "R_X86_64_PC32", false, 0, 0xffffffff,
+ bfd_elf_generic_reloc, "R_X86_64_PC32", false, 0xffffffff, 0xffffffff,
true),
HOWTO(R_X86_64_GOT32, 0, 4, 32, false, 0, complain_overflow_signed,
- bfd_elf_generic_reloc, "R_X86_64_GOT32", false, 0, 0xffffffff,
+ bfd_elf_generic_reloc, "R_X86_64_GOT32", false, 0xffffffff, 0xffffffff,
false),
HOWTO(R_X86_64_PLT32, 0, 4, 32, true, 0, complain_overflow_signed,
- bfd_elf_generic_reloc, "R_X86_64_PLT32", false, 0, 0xffffffff,
+ bfd_elf_generic_reloc, "R_X86_64_PLT32", false, 0xffffffff, 0xffffffff,
true),
HOWTO(R_X86_64_COPY, 0, 4, 32, false, 0, complain_overflow_bitfield,
bfd_elf_generic_reloc, "R_X86_64_COPY", false, 0, 0xffffffff,
@@ -74,10 +74,10 @@ static reloc_howto_type x86_64_elf_howto_table[] =
bfd_elf_generic_reloc, "R_X86_64_GOTPCREL", false, 0, 0xffffffff,
true),
HOWTO(R_X86_64_32, 0, 4, 32, false, 0, complain_overflow_unsigned,
- bfd_elf_generic_reloc, "R_X86_64_32", false, 0, 0xffffffff,
+ bfd_elf_generic_reloc, "R_X86_64_32", false, 0xffffffff, 0xffffffff,
false),
HOWTO(R_X86_64_32S, 0, 4, 32, false, 0, complain_overflow_signed,
- bfd_elf_generic_reloc, "R_X86_64_32S", false, 0, 0xffffffff,
+ bfd_elf_generic_reloc, "R_X86_64_32S", false, 0xffffffff, 0xffffffff,
false),
HOWTO(R_X86_64_16, 0, 2, 16, false, 0, complain_overflow_bitfield,
bfd_elf_generic_reloc, "R_X86_64_16", false, 0, 0xffff, false),
@@ -136,7 +136,7 @@ static reloc_howto_type x86_64_elf_howto_table[] =
bfd_elf_generic_reloc, "R_X86_64_PLTOFF64", false, 0, MINUS_ONE,
false),
HOWTO(R_X86_64_SIZE32, 0, 4, 32, false, 0, complain_overflow_unsigned,
- bfd_elf_generic_reloc, "R_X86_64_SIZE32", false, 0, 0xffffffff,
+ bfd_elf_generic_reloc, "R_X86_64_SIZE32", false, 0xffffffff, 0xffffffff,
false),
HOWTO(R_X86_64_SIZE64, 0, 8, 64, false, 0, complain_overflow_dont,
bfd_elf_generic_reloc, "R_X86_64_SIZE64", false, 0, MINUS_ONE,
@@ -188,7 +188,7 @@ static reloc_howto_type x86_64_elf_howto_table[] =
/* Use complain_overflow_bitfield on R_X86_64_32 for x32. */
HOWTO(R_X86_64_32, 0, 4, 32, false, 0, complain_overflow_bitfield,
- bfd_elf_generic_reloc, "R_X86_64_32", false, 0, 0xffffffff,
+ bfd_elf_generic_reloc, "R_X86_64_32", false, 0xffffffff, 0xffffffff,
false)
};