Re: [ipxe-devel] compile fails with gcc 4.8.0

2013-06-07 Thread Daniel P. Berrange
On Fri, Jun 07, 2013 at 02:05:54PM +0100, Michael Brown wrote:
 Christian Hessel...@eworm.de   on Tue, 2013/04/02 10:35:
 with gcc 4.8.0 compilation fails:
 
 [BUILD] 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
 
 The icky workaround for this is now pushed:
 
   http://git.ipxe.org/ipxe.git/commitdiff/238050d

This doesn't look right:

-  addw $4, %%sp\n\t )
+  popl %%ebp\n\t /* discard */
+  popl %%ebp\n\t /* gcc bug */ )


In the original patch it was

-  addw $4, %%sp\n\t )
+  addw $4, %%sp\n\t
+  popl %%ebp\n\t )

You've accidentally transposed the 'addw' into a second 'popl'.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel


Re: [ipxe-devel] compile fails with gcc 4.8.0

2013-06-07 Thread Daniel P. Berrange
On Fri, Jun 07, 2013 at 02:30:10PM +0100, Michael Brown wrote:
 On 07/06/13 14:22, Daniel P. Berrange wrote:
 This doesn't look right:
 
 -  addw $4, %%sp\n\t )
 +  popl %%ebp\n\t /* discard */
 +  popl %%ebp\n\t /* gcc bug */ )
 
 In the original patch it was
 -  addw $4, %%sp\n\t )
 +  addw $4, %%sp\n\t
 +  popl %%ebp\n\t )
 
 You've accidentally transposed the 'addw' into a second 'popl'.
 
 That's deliberate: since %ebp is about to get overwritten anyway, we
 can use it as a discard register for the popl, which increments
 %sp by 4 using only two bytes of code rather than three.
 
 You can see several other instances of this pattern within the codebase:
 
   git grep pop.*discard

Ok, I'll assume you're right since my assembler knowledge is tiny :-)
Just wanted to make sure it wasn't an accidental typo.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel


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

2013-03-05 Thread Daniel P. Berrange
On Tue, Mar 05, 2013 at 01:48:29PM +, Michael Brown wrote:
 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!

If you can provide the possible patch, I'll happily give it a spin on
a Fedora rawhide gcc 4.8.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel


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

2013-02-22 Thread Daniel P. Berrange
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


That's the following function code:

int pxe_start_nbp ( void ) {
int jmp;
int discard_b, discard_c, discard_d, discard_D;
uint16_t rc;

/* Allow restarting NBP via PXENV_RESTART_TFTP */
jmp = rmsetjmp ( pxe_restart_nbp );
if ( jmp )
DBG ( Restarting NBP (%x)\n, jmp );

/* Far call to PXE NBP */
__asm__ __volatile__ ( REAL_CODE ( movw %%cx, %%es\n\t
   pushw %%es\n\t
   pushw %%di\n\t
   sti\n\t
   lcall $0, $0x7c00\n\t
   addw $4, %%sp\n\t )
   : =a ( rc ), =b ( discard_b ),
 =c ( discard_c ), =d ( discard_d ),
 =D ( discard_D )
   : a ( 0 ), b ( __from_text16 ( pxenv ) ),
 c ( rm_cs ),
 d ( virt_to_phys ( pxenv ) ),
 D ( __from_text16 ( ppxe ) )
   : esi, ebp, memory );

return rc;
}


asm isn't my strong field, so anyone know if this is a valid ipxe bug, or
a mistaken report from newest gcc ?

NB, this is a git snapshot from 20130103, change #717279a. I've not tested
latest git yet, but don't see any changes to pxe_call.c that would make
me think it would succeed.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel


Re: [ipxe-devel] Source file license header clarification

2012-03-23 Thread Daniel P. Berrange
On Fri, Mar 23, 2012 at 02:13:36PM +, Daniel P. Berrange wrote:
 In the course of the Fedora review for iPXE, it was identified that many
 iPXE source files do not have any license header comment in them. While
 the intent is commonly that any such ommisions imply that the file(s) are
 covered by the terms of the top level COPYING file, the Fedora review
 guides say we should make a recommendation to upstream communities that
 they ensure per-file license headers.
 
 So this message is just such a friendly hint. To make life easier, I
 wrote a simple perl script to try  identify .h or .c files which have
 got either incomplete or missing license information. By incomplete I
 mean that a file has iPXE's magic FILE_LICENCE macro, but no comment
 header. By missing, I mean it lacks FILE_LICENCE and / or comments.
 
 IMHO, since iPXE seems to contain a non-trivial number of files that
 have been copied from other compatible open source projects, it is
 wise to ensure every source file has unambiguous license comments.
 
 I'm attaching the script, which on a GIT checkout it reports the
 following:

And this time with the script actually attached :-)

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|


license.pl
Description: Perl program
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel


[ipxe-devel] Build problems on Fedora 16/17 with current GIT

2012-03-19 Thread Daniel P. Berrange
I've been trying to package ipxe for Fedora, to replace our gpxe packages.

Originally I was building from this commit:

  commit ffb6d6be6dc8b0b7f144ed7f6d40b537b4480295
  Author: Michael Brown mc...@ipxe.org
  Date:   Tue Mar 13 04:41:49 2012 +

but the build eventually fails with the following error

  [ZBIN] bin/168c0023.rom.zbin
  [ZBIN] bin/168c0024.rom.zbin
  [ZBIN] bin/168c0027.rom.zbin
  [ZBIN] bin/168c0029.rom.zbin
Add 0+0x126 at 0x2 overflows 1-byte field (19456 bytes too big)
make: *** [bin/168c0023.rom.zbin] Error 1
make: *** Deleting file `bin/168c0023.rom.zbin'
make: *** Waiting for unfinished jobs
Add 0+0x126 at 0x2 overflows 1-byte field (19456 bytes too big)
make: *** [bin/168c0024.rom.zbin] Error 1
make: *** Deleting file `bin/168c0024.rom.zbin'
Add 0+0x126 at 0x2 overflows 1-byte field (19456 bytes too big)
make: *** [bin/168c0027.rom.zbin] Error 1
make: *** Deleting file `bin/168c0027.rom.zbin'
Add 0+0x126 at 0x2 overflows 1-byte field (19456 bytes too big)
make: *** [bin/168c0029.rom.zbin] Error 1
make: *** Deleting file `bin/168c0029.rom.zbin'


The command I'm using to start the build is:


  ISOLINUX_BIN=/usr/share/syslinux/isolinux.bin
  cd src
  make %{?_smp_mflags} bin/undionly.kpxe bin/ipxe.{dsk,iso,usb,lkrn} allroms \
   ISOLINUX_BIN=${ISOLINUX_BIN} NO_WERROR=1


(the %{?_smp_mflags} bit just expands to '-jNN' for number of host CPUs)


Updating to today's GIT, I now get an error much earlier in the build
process (so I suspect the original error is probably still there):


[snip]
gcc  -DVERSION_MAJOR=1 -DVERSION_MINOR=0 -DVERSION_PATCH=0 -DVERSION=\1.0.0+\ 
-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 -Wno-address  
-ffunction-sections -fdata-sections -include compiler.h   -DOBJECT=aes_wrap -c 
crypto/aes_wrap.c -o bin/aes_wrap.o 
gcc  -DVERSION_MAJOR=1 -DVERSION_MINOR=0 -DVERSION_PATCH=0 -DVERSION=\1.0.0+\ 
-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 -Wno-address  
-ffunction-sections -fdata-sections -include compiler.h   -DOBJECT=axtls_aes -c 
crypto/axtls_aes.c -o bin/axtls_aes.o 
gcc  -DVERSION_MAJOR=1 -DVERSION_MINOR=0 -DVERSION_PATCH=0 -DVERSION=\1.0.0+\ 
-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 -Wno-address  
-ffunction-sections -fdata-sections -include compiler.h   -DOBJECT=asn1 -c 
crypto/asn1.c -o bin/asn1.o 
gcc  -DVERSION_MAJOR=1 -DVERSION_MINOR=0 -DVERSION_PATCH=0 -DVERSION=\1.0.0+\ 
-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 -Wno-address  
-ffunction-sections -fdata-sections -include compiler.h   -DOBJECT=hmac -c 
crypto/hmac.c -o bin/hmac.o 
gcc  -DVERSION_MAJOR=1 -DVERSION_MINOR=0 -DVERSION_PATCH=0 -DVERSION=\1.0.0+\ 
-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 -Wno-address  
-ffunction-sections -fdata-sections -include compiler.h   -DOBJECT=bigint -c 
crypto/bigint.c -o bin/bigint.o 
arch/x86/include/bits/bigint.h: Assembler messages:
arch/x86/include/bits/bigint.h:185: Error: bad register name `%bpl'
make: *** [bin/bigint.o] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.bkKAV4 (%build)


Looking at GIT history for the  bigint.h file, it appears this