[ipxe-devel] Unrecognised relocation type R_X86_64_32S in util/elf2efi64

[Jan Kundrát]

On Thursday, 12 February 2015 12:05:53 CEST, Michael Brown wrote:
>   make bin-x86_64-efi/x509.o.rebuild V=1

Ah, V=1, not VERBOSE=1 as I'm used to :). Thanks!

Here's the GCC invocation:

gcc  -DARCH=x86_64 -DPLATFORM=efi -fstrength-reduce -fomit-frame-pointer 
-falign-jumps=1 -falign-loops=1 -falign-functions=1 -fpie -m64 
-fshort-wchar -Ui386 -Ulinux -DNVALGRIND -mno-red-zone -Iinclude -I. 
-Iarch/x86/include -Iarch/x86_64/include -Iarch/x86_64/include/efi -Os -g 
-ffreestanding -Wall -W -Wformat-nonliteral  -fno-stack-protector -fno-PIE 
-nopie -fno-dwarf2-cfi-asm -fno-exceptions  -fno-unwind-tables 
-fno-asynchronous-unwind-tables -Wno-address -maccumulate-outgoing-args  
-Werror -ffunction-sections -fdata-sections -include include/compiler.h   
-DOBJECT=x509 -c crypto/x509.c -o bin-x86_64-efi/x509.o 

I'm actually on "Hardened Gentoo" which does patch its GCC, but I did take 
care to switch to a vanilla GCC as well, and the end result was the same. 
If I use unmodified GCC as provided by Gentoo and after a `git clean -dxf` 
in my src/, I still get these relocations, and the command invoking GCC 
remains the same. Am I cleaning stuff thoroughly enough?

I see that there's some test for this in Makefile.housekeeping. Calling 
`gcc -fno-PIE -nopie -x c -c /dev/null -o /dev/null` return exit status 0, 
aand there's no output on stdout/stderr.

OK, this fixes the problem for me:

--- a/src/Makefile.housekeeping
+++ b/src/Makefile.housekeeping
@@ -165,7 +165,7 @@ endif
 ifeq ($(CCTYPE),gcc)
 PIE_TEST = [ -z "`$(CC) -fno-PIE -nopie -x c -c /dev/null -o /dev/null 
2>&1`" ]
 PIE_FLAGS := $(shell $(PIE_TEST) && $(ECHO) '-fno-PIE -nopie')
-WORKAROUND_CFLAGS += $(PIE_FLAGS)
+#WORKAROUND_CFLAGS += $(PIE_FLAGS)

Now I wonder whether my compiler plays some funny game with me and my 
assumption about disabling the Hardended fixes by Gentoo-provided steps is 
not enough, or whether the build system mistakenly applies a workaround?

Anyway, after this hackish patch, the invocation is just:

gcc  -DARCH=x86_64 -DPLATFORM=efi -fstrength-reduce -fomit-frame-pointer 
-falign-jumps=1 -falign-loops=1 -falign-functions=1 -fpie -m64 
-fshort-wchar -Ui386 -Ulinux -DNVALGRIND -mno-red-zone -Iinclude -I. 
-Iarch/x86/include -Iarch/x86_64/include -Iarch/x86_64/include/efi -Os -g 
-ffreestanding -Wall -W -Wformat-nonliteral  -fno-stack-protector 
-fno-dwarf2-cfi-asm -fno-exceptions  -fno-unwind-tables 
-fno-asynchronous-unwind-tables -Wno-address -maccumulate-outgoing-args  
-Werror -ffunction-sections -fdata-sections -include include/compiler.h   
-DOBJECT=x509 -c crypto/x509.c -o bin-x86_64-efi/x509.o 

and I don't get any such relocations.

> I'm fairly sure there's no way to generate an equivalent PE relocation for R_X86_64_32S, since UEFI allows objects to be loaded anywhere within the 64-bit address space.

I don't understand the object formats nor the amd64 ABI, but I am a bit 
surprised that R_X86_64_32 is supported, then. Is that a direct result of 
zero-extension vs. sign-extension?

> and also confirm which git revision you are building (e.g. via "git log")?

335a7ddcd4e2d0faaee6d5b1edf0307dfba3d0e5

With kind regards,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/