On Tue, 28 Mar 2023 at 09:32, Pingfan Liu <kernelfans@xxxxxxxxx> wrote: > > On Mon, Mar 27, 2023 at 6:57 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > On Mon, 27 Mar 2023 at 11:51, Pingfan Liu <kernelfans@xxxxxxxxx> wrote: > > > > > > Using objcopy to reform vmlinuz.efi.elf to vmlinuz.efi will not convey > > > any relocation information. That means vmlinuz.efi is expected to be > > > PIC. > > > > > > At present, vmlinuz.efi is PIC. But it is better to adopt the same > > > > Why is it better? > > > > I think except carefully coded with asm language, there is no > guarantee which prevents the compiler from generating position > dependent code. Or is there any presumption here? > All object files built under drivers/firmware/efi/libstub are scanned for absolute relocations, and if any exist, the build is aborted. > > > solution used by the kernel to resolve the code relocation issue by > > > itself. That is to resolve R_AARCH64_RELATIVE at the runtime. > > > > > > > This breaks other architectures. > > > > Oops, could it be done by: > #if defined(_aarch64_) > #define R_ARCH_RELATIVE R_AARCH64_RELATIVE > #else > #define R_ARCH_RELATIVE 0 > #endif > > Since any r_type equaling 0 can not be ejected into the relocation > section, this macro will make the code dummy in essential. > So the assembler instructions you are using are also implemented on RISC-V and LoongArch?
