[ipxe-devel] iPXE build failure on Fedora 19 (rawhide)

[Michael Brown]

On 22/02/13 15:40, Daniel P. Berrange wrote:
> Building on Fedora 19 rawhide, which has latest gcc 4.8.0 I'm seeing the
> following failure on the pxe_call.c file:
>
>    gcc  -DARCH=i386 -DPLATFORM=pcbios -march=i386 -fomit-frame-pointer -fstrength-reduce -falign-jumps=1 -falign-loops=1 -falign-functions=1 -mpreferred-stack-boundary=2 -mregparm=3 -mrtd -freg-struct-return -m32 -fshort-wchar -Ui386 -Ulinux -DNVALGRIND -Iinclude -I. -Iarch/x86/include -Iarch/i386/include -Iarch/i386/include/pcbios -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  -ffunction-sections -fdata-sections -include compiler.h   -DOBJECT=pxe_call -c arch/i386/interface/pxe/pxe_call.c -o bin/pxe_call.o
>    arch/i386/interface/pxe/pxe_call.c: In function 'pxe_start_nbp':
>    arch/i386/interface/pxe/pxe_call.c:284:1: error: bp cannot be used in asm here
>     }
>     ^
>    make: *** [bin/pxe_call.o] Error 1
>
> <snip>
>
> asm isn't my strong field, so anyone know if this is a valid ipxe bug, or
> a mistaken report from newest gcc ?

gcc has a history of interesting failures relating to using the frame 
pointer in inline asm; see e.g

   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11807
   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28686

We've had to work around this kind of problem before:

   http://git.ipxe.org/ipxe.git/commitdiff/54fbd11

The quickest hack to fix this would be to manually preserve ebp via a 
pushl/popl within the inline asm, as is currently done in meme820() and 
multiboot_exec().  However, this is an ugly fix, not least because it 
makes it impossible to refer to local variables in asm constraints. 
Slightly neater would be to explicitly specify ebp as an unused output 
operand, but it's possible gcc would then complain about "impossible 
constraints in asm".

I've applied for access to the GCC Compile Farm, to make it easier to 
try out various fixes across multiple gcc versions.  In the meantime, if 
anyone has a gcc 4.8.0 box already set up and wants to report on whether 
or not the unused-output approach works, please do so!

Michael