[PATCH] binutils: partially revert 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8

[Jan Beulich]

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