Re: [PATCH] binutils: partially revert 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8

[Jan Beulich <jbeulich@suse.com>]

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