[LinuxBIOS] Qemu compile for LinuxBIOSV2

[Marc Karasek]

I am trying to get up to speed on LinuxBIOS and to that end have tried 
to compile both v3 & v2 for qemu.

I have successfully compiled and run v3 with a filo package on my Fedora 
8 system.

When I try to compile v2 with a filo.elf payload I get the :

collect2: ld terminated with signal 11 [Segmentation fault]

Error

In looking at the compile it has gotten through the compile part and is 
linking.

rm -f linuxbios.a
ar cr linuxbios.a  malloc.o pci_ops.o smbus_ops.o memset.o 
pci_ops_auto.o linuxbios_table.o fallback_boot.o pciexp_device.o 
keyboard.o pnp_device.o printk.o irq_tables.o pcix_device.o i8259.o 
pci_device.o console.o elfboot.o hardwaremain.o boot.o exception.o 
delay.o version.o pci_ops_mmconf.o memcmp.o isa-dma.o hypertransport.o 
vtxprintf.o tables.o root_device.o cardbus_device.o uart8250.o 
device_util.o ./option_table.o compute_ip_checksum.o device.o 
northbridge.o memcpy.o agp_device.o vgabios.o clog2.o pirq_routing.o 
memmove.o pci_ops_conf2.o pci_ops_conf1.o mc146818rtc.o rom_stream.o 
c_start.o vsprintf.o cpu.o static.o
gcc -m32 -nostdlib -r -o linuxbios_ram.o c_start.o  mainboard.o 
uart8250_console.o linuxbios.a /usr/lib/gcc/i386-redhat-linux/4.1.2/libgcc.a
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T 
/home/mk216460/src/LinuxBIOSv2-2988/src/config/linuxbios_ram.ld 
linuxbios_ram.o
collect2: ld terminated with signal 11 [Segmentation fault]
make[1]: *** [linuxbios_ram] Error 1
make[1]: Leaving directory 
`/home/mk216460/src/LinuxBIOSv2-2988/targets/emulation/qemu-i386/qemu-i386/image'

In looking at the /var/log/messages you see

Nov 30 14:37:02 dhcp-uatl04-156-163 kernel: ld[3691]: segfault at 
00000030 eip 08068b2c esp bfc6a0f0 error 4

Any help/pointers for what to look at would be helpful.

[Peter Stuge]

On Fri, Nov 30, 2007 at 02:53:03PM -0500, Marc Karasek wrote:
> When I try to compile v2 with a filo.elf payload I get the :
>
> collect2: ld terminated with signal 11 [Segmentation fault]

The linker plain crashes.

Try vanilla upstream gcc and binutils packages.

//Peter

[Ed Swierk]

On 11/30/07, Marc Karasek  wrote:
> When I try to compile v2 with a filo.elf payload I get the :
>
> collect2: ld terminated with signal 11 [Segmentation fault]
>
> Error

The attached patch works around a crash from GNU ld version
2.17.50.0.18-1 20070731.

--Ed

[Marc Karasek]

Thanks for the patch.

Tried it and it still crashes, but at least now it gives more info.  I 
will look into this from this end and see what is happening.

BTW: Is this patch associated with the thread about qemu and the compilers?

Thanks again....

cp linuxbios_ram.nrv2b linuxbios_ram.rom
echo '/*ldoptions*/' > ldscript.ld; cat ldoptions >> ldscript.ld ; for 
file in  
/home/mk216460/src/LinuxBIOSv2-2988/src/arch/i386/init/ldscript.lb 
/home/mk216460/src/LinuxBIOSv2-2988/src//cpu/x86/16bit/entry16.lds 
/home/mk216460/src/LinuxBIOSv2-2988/src//cpu/x86/32bit/entry32.lds 
/home/mk216460/src/LinuxBIOSv2-2988/src//cpu/x86/16bit/reset16.lds 
/home/mk216460/src/LinuxBIOSv2-2988/src//arch/i386/lib/id.lds ; do echo 
/* $file */ >> ldscript.ld; cat $file >> ldscript.ld ; done
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o
/usr/bin/ld: linuxbios: section `.id' can't be allocated in segment 2
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status

/*********************
Marc Karasek
MTS
Sun Microsystems
mailto:[e-mail]
ph:770.360.6415
*********************/

Ed Swierk wrote:
> On 11/30/07, Marc Karasek  wrote:
> > When I try to compile v2 with a filo.elf payload I get the :
> >
> > collect2: ld terminated with signal 11 [Segmentation fault]
> >
> > Error
>
> The attached patch works around a crash from GNU ld version
> 2.17.50.0.18-1 20070731.
>
> --Ed

[Ed Swierk]

On 12/3/07, Marc Karasek  wrote:
> Thanks for the patch.
>
> Tried it and it still crashes, but at least now it gives more info.  I will
> look into this from this end and see what is happening.

I'm stuck on the same problem here (on Fedora 8), so please share any
discoveries.
> BTW: Is this patch associated with the thread about qemu and the compilers?

Not sure; I posted the same patch about a week ago but there was only
one response.

--Ed

[Peter Stuge]

On Mon, Dec 03, 2007 at 01:04:53PM -0500, Marc Karasek wrote:
> BTW: Is this patch associated with the thread about qemu and the
> compilers?

No, that thread is all about v3 growing pains.

//Peter

[Jordan Crouse]

On 03/12/07 09:58 -0800, Ed Swierk wrote:
> On 11/30/07, Marc Karasek  wrote:
> > When I try to compile v2 with a filo.elf payload I get the :
> >
> > collect2: ld terminated with signal 11 [Segmentation fault]
> >
> > Error
>
> The attached patch works around a crash from GNU ld version
> 2.17.50.0.18-1 20070731.

Can we get a Signed-off-by: line for this patch?  It seems sane enough to
me.

Jordan

[Ed Swierk]

On 12/3/07, Jordan Crouse  wrote:
> Can we get a Signed-off-by: line for this patch?  It seems sane enough to
> me.

Signed-off-by: Ed Swierk

[Jordan Crouse]

On 03/12/07 10:15 -0800, Ed Swierk wrote:
> On 12/3/07, Jordan Crouse  wrote:
> > Can we get a Signed-off-by: line for this patch?  It seems sane enough to
> > me.
>
> Signed-off-by: Ed Swierk

Acked-by: Jordan Crouse

[Marc Karasek]

Unfortunately, it is still broken under Fedora 8.

V3 works, it is just V2 that is having these linking problems. This 
patch makes things better, and it at least gives us a more descriptive 
error than just a segmentation fault.

This at least gives me a good starting point to debug from .. I think as 
soon as we get a stable version that should be the patch..

/*********************
Marc Karasek
MTS
Sun Microsystems
mailto:[e-mail]
ph:770.360.6415
*********************/

Jordan Crouse wrote:
> On 03/12/07 09:58 -0800, Ed Swierk wrote:
> > On 11/30/07, Marc Karasek  wrote:
> > > When I try to compile v2 with a filo.elf payload I get the :
> > >
> > > collect2: ld terminated with signal 11 [Segmentation fault]
> > >
> > > Error
> >
> > The attached patch works around a crash from GNU ld version
> > 2.17.50.0.18-1 20070731.
>
> Can we get a Signed-off-by: line for this patch?  It seems sane enough to
> me.
>
> Jordan

[Jordan Crouse]

On 03/12/07 13:15 -0500, Marc Karasek wrote:
> Unfortunately, it is still broken under Fedora 8.
>
> V3 works, it is just V2 that is having these linking problems. This patch 
> makes things better, and it at least gives us a more descriptive error than 
> just a segmentation fault.
>
> This at least gives me a good starting point to debug from .. I think as 
> soon as we get a stable version that should be the patch..

Fair enough - we can wait.   I do agree that avoiding segfaults is good. :)

Jordan

[Carl-Daniel Hailfinger]

On 03.12.2007 19:15, Marc Karasek wrote:
> Unfortunately, it is still broken under Fedora 8.
>
> V3 works, it is just V2 that is having these linking problems. This
> patch makes things better, and it at least gives us a more descriptive
> error than just a segmentation fault.
>
> This at least gives me a good starting point to debug from .. I think
> as soon as we get a stable version that should be the patch..

Please file a bug with the binutils guys. If they don't know ld is
broken, they can't fix it.

Regards,
Carl-Daniel

[Marc Karasek]

I think I have found the problem.  It is related to the patch Ed sent.

The new LD looks like it automagically turns on the --build-id option.  
I have not found out how turn it off.

When this option is used it generates the   .note.gnu.build-id section.  
When this section was discarded in the first ld pass (linuxbios_rom.ram 
creation) it was causing the segmentation fault crash.

It looks like this same option is being called again when crt0.o is 
linked to create linuxbios.  I have added the .note.gnu.build-id section 
to the .id section in the ldscript.ld file.

SECTIONS {
        . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__id_end - __id_start);
        .id (.) : {
                *(.id)
                *(.note.gnu.build-id)
        }

This has gotten me past the second crash but now linuxbios.strip is 
crashing.

nm -n linuxbios | sort > linuxbios.map
objcopy --gap-fill 0xff -O binary linuxbios linuxbios.strip
objcopy: linuxbios.strip: Bad value
objcopy: linuxbios.strip: Bad value
make[1]: *** [linuxbios.strip] Error 1

So this does not look like a ld problem, but an added feature to ld is 
causing us grief.  If anyone can figure out how to turn this option 
off,  that may fix all of this without any patches... :-)

/*********************
Marc Karasek
MTS
Sun Microsystems
mailto:[e-mail]
ph:770.360.6415
*********************/

Carl-Daniel Hailfinger wrote:
> On 03.12.2007 19:15, Marc Karasek wrote:
> > Unfortunately, it is still broken under Fedora 8.
> >
> > V3 works, it is just V2 that is having these linking problems. This
> > patch makes things better, and it at least gives us a more descriptive
> > error than just a segmentation fault.
> >
> > This at least gives me a good starting point to debug from .. I think
> > as soon as we get a stable version that should be the patch..
>
> Please file a bug with the binutils guys. If they don't know ld is
> broken, they can't fix it.
>
> Regards,
> Carl-Daniel

[Ed Swierk]

On 12/3/07, Marc Karasek  wrote:
> So this does not look like a ld problem, but an added feature to ld is
> causing us grief.  If anyone can figure out how to turn this option off,
> that may fix all of this without any patches... :-)

Passing -Wl,--build-id=none to gcc turns off that ld feature. I
haven't yet tracked down all the gcc invocations where it's needed.

--Ed

[Marc Karasek]

Will -none really turn it off or just not do a crypto on the ld?

/*********************
Marc Karasek
MTS
Sun Microsystems
mailto:[e-mail]
ph:770.360.6415
*********************/

Ed Swierk wrote:
> On 12/3/07, Marc Karasek  wrote:
> > So this does not look like a ld problem, but an added feature to ld is
> > causing us grief.  If anyone can figure out how to turn this option off,
> > that may fix all of this without any patches... :-)
>
> Passing -Wl,--build-id=none to gcc turns off that ld feature. I
> haven't yet tracked down all the gcc invocations where it's needed.
>
> --Ed

[Marc Karasek]

I did a man on ld and it says this about the build-id option

--build-id
       --build-id=style
           Request creation of ".note.gnu.build-id" ELF note section.  
The contents of the note are
           unique bits identifying this linked file.  style can be 
"uuid" to use 128  random  bits,
           "sha1"  to  use a 160-bit SHA1 hash on the normative parts of 
the output contents, "md5"
           to use  a  128-bit  MD5  hash  on  the  normative  parts  of  
the  output  contents,  or
           "0xhexstring" to use a chosen bit string specified as an even 
number of hexadecimal dig-
           its ("-" and ":" characters between digit pairs are  
ignored).   If  style  is  omitted,
           "sha1" is used.

The "md5" and "sha1" styles produces an identifier that is 
always the same in an identi-
           cal output file, but will be unique among all nonidentical  
output  files.   It  is  not
           intended  to  be  compared  as a checksum for the file’s 
contents.  A linked file may be
           changed later by other tools, but the build  ID  bit  string  
identifying  the  original
           linked file does not change.

Passing  "none"  for style disables the setting from any 
"--build-id" options earlier on
           the command line.

Looks to me like the none option does not turn it off but only clears 
any prior options set on the command line.

Maybe this is a bug in ld in terms of it always being on and you not 
having to explicitly setting it to turn it on.

/*********************
Marc Karasek
MTS
Sun Microsystems
mailto:[e-mail]
ph:770.360.6415
*********************/

Ed Swierk wrote:
> On 12/3/07, Marc Karasek  wrote:
> > So this does not look like a ld problem, but an added feature to ld is
> > causing us grief.  If anyone can figure out how to turn this option off,
> > that may fix all of this without any patches... :-)
>
> Passing -Wl,--build-id=none to gcc turns off that ld feature. I
> haven't yet tracked down all the gcc invocations where it's needed.
>
> --Ed

[Ed Swierk]

On 12/3/07, Marc Karasek  wrote:
> Looks to me like the none option does not turn it off but only clears
> any prior options set on the command line.

If you look at the ld command line (by adding -v to the gcc command
line) you will see that gcc adds the --build-id option. So
--build-id=none turns it off.

--Ed

[Marc Karasek]

I now know what is going on.  I do not know how to fix it... :-)

I have made the changes to the Makefile to add the -Wl,--build-id=none 
option to the appropriate places. 
I am planning on making a patch file for this to cover all the cases.  
This will mean the patch submitted by Ed will not be needed.

The second problem has to do with the .id section and how it is defined 
in id.inc.
Currently it is as follows:
.section ".id", "a", @progbits

With this in place you cannot place the .id section above the address 
0xFFFF_EF00.  Doing so will create the error could not allocate in 
segment 1.  If you use the address 0xFFFF_EF00 or below it will compile 
and the text strings vendor and part are in the final binary image at 
the address specified.

If you change the id.inc file to :
.section .id or .section ".id"

With this in place you can move the address above 0xFFFF_EF00.  The 
vendor & part strings are in the crt0.o file and are listed in the 
linuxbios.map file.  They are NOT in the final binary however.

At this point I am looking for some guidance/help in what to do/look at 
next.  Do you think this is a ld bug or something else?
Can we live with moving this block below for right now with large 
comments as to why?

/*********************
Marc Karasek
MTS
Sun Microsystems
mailto:[e-mail]
ph:770.360.6415
*********************/

Ed Swierk wrote:
> On 12/3/07, Marc Karasek  wrote:
> > Looks to me like the none option does not turn it off but only clears
> > any prior options set on the command line.
>
> If you look at the ld command line (by adding -v to the gcc command
> line) you will see that gcc adds the --build-id option. So
> --build-id=none turns it off.
>
> --Ed

[Carl-Daniel Hailfinger]

On 03.12.2007 21:18, Marc Karasek wrote:
> I think I have found the problem.  It is related to the patch Ed sent.
> The new LD looks like it automagically turns on the --build-id
> option.  I have not found out how turn it off.
> When this option is used it generates the   .note.gnu.build-id
> section.  When this section was discarded in the first ld pass
> (linuxbios_rom.ram creation) it was causing the segmentation fault crash.
> It looks like this same option is being called again when crt0.o is
> linked to create linuxbios.  I have added the .note.gnu.build-id
> section to the .id section in the ldscript.ld file.
> SECTIONS {
>        . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__id_end - __id_start);
>        .id (.) : {
>                *(.id)
>                *(.note.gnu.build-id)
>        }
>
> This has gotten me past the second crash but now linuxbios.strip is
> crashing.

Well done.
> nm -n linuxbios | sort > linuxbios.map
> objcopy --gap-fill 0xff -O binary linuxbios linuxbios.strip
> objcopy: linuxbios.strip: Bad value
> objcopy: linuxbios.strip: Bad value
> make[1]: *** [linuxbios.strip] Error 1
>
> So this does not look like a ld problem, but an added feature to ld is
> causing us grief.  If anyone can figure out how to turn this option
> off,  that may fix all of this without any patches... :-)

Still, it would be a nice gesture to the binutils guys to report it as a
bug. Maybe there's some bug deeper down which triggers this.

Regards,
Carl-Daniel

[Marc Karasek]

As promised here is the patch for first the --build-on problem and also 
the final linker problem.  Although I consider the second one a patch 
rather than a fix.. :-)

I have compiled this and tested it with FILO under QEMU.   I think this 
will take care of all of the other builds as well.  At least teh i386 
ones.. :-)

Files Modified:
LinuxBIOSv2/src/arch/i386/Config.lb
LinuxBIOSv2/src/arch/i386/lib/id.lds
LinuxBIOSv2/src/config/Config.lb
/*************************Patch***********************************************
diff -C 3 -r -x .svn LinuxBIOSv2.orig/src/arch/i386/Config.lb 
LinuxBIOSv2/src/arch/i386/Config.lb
*** LinuxBIOSv2.orig/src/arch/i386/Config.lb    2007-12-06 
10:06:31.000000000 -0500
--- LinuxBIOSv2/src/arch/i386/Config.lb    2007-12-04 16:25:13.000000000 
-0500
***************
*** 100,106 ****

makerule linuxbios  
          depends    "crt0.o init.o $(LINUXBIOS_APC) 
$(LINUXBIOS_RAM_ROM) ldscript.ld"
!         action    "$(CC) -nostdlib -nostartfiles -static -o $@ -T 
ldscript.ld crt0.o init.o"
          action    "$(CROSS_COMPILE)nm -n linuxbios | sort > linuxbios.map"
          end

--- 100,106 ----

makerule linuxbios  
          depends    "crt0.o init.o $(LINUXBIOS_APC) 
$(LINUXBIOS_RAM_ROM) ldscript.ld"
!         action    "$(CC) -Wl,--build-id=none -nostdlib -nostartfiles 
-static -o $@ -T ldscript.ld crt0.o init.o"
          action    "$(CROSS_COMPILE)nm -n linuxbios | sort > linuxbios.map"
          end

diff -C 3 -r -x .svn LinuxBIOSv2.orig/src/arch/i386/lib/id.lds 
LinuxBIOSv2/src/arch/i386/lib/id.lds
*** LinuxBIOSv2.orig/src/arch/i386/lib/id.lds    2007-12-06 
10:06:31.000000000 -0500
--- LinuxBIOSv2/src/arch/i386/lib/id.lds    2007-12-06 
10:36:31.000000000 -0500
***************
*** 1,5 ****
  SECTIONS {
!     . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__id_end - __id_start);
      .id (.): {
          *(.id)
      }
--- 1,11 ----
  SECTIONS {
!
! /*
!  *           . = (_ROMBASE + (ROM_IMAGE_SIZE - 0x10)) - (__id_end - 
__id_start);
!  *          This is a temporary fix.  Under Fedora 8 ld does not like 
it if the .id section is above address 0xFFFF_EF00         
! */
!         _ROMTEMP = 0xffffef00;
!         . = _ROMTEMP;
      .id (.): {
          *(.id)
      }
Only in LinuxBIOSv2/src/arch/i386/lib: id.lds~
diff -C 3 -r -x .svn LinuxBIOSv2.orig/src/config/Config.lb 
LinuxBIOSv2/src/config/Config.lb
*** LinuxBIOSv2.orig/src/config/Config.lb    2007-12-06 
10:06:30.000000000 -0500
--- LinuxBIOSv2/src/config/Config.lb    2007-12-04 16:27:48.000000000 -0500
***************
*** 40,51 ****

makerule linuxbios_ram.o
      depends    "$(DRIVER) linuxbios.a $(LIBGCC_FILE_NAME)"
!     action    "$(CC) -nostdlib -r -o $@ c_start.o $(DRIVER) 
linuxbios.a $(LIBGCC_FILE_NAME)"
  end

makerule linuxbios_ram
      depends    "linuxbios_ram.o $(TOP)/src/config/linuxbios_ram.ld 
ldoptions"
!     action    "$(CC) -nostdlib -nostartfiles -static -o $@ -T 
$(TOP)/src/config/linuxbios_ram.ld linuxbios_ram.o"
      action     "$(CROSS_COMPILE)nm -n linuxbios_ram | sort > 
linuxbios_ram.map"
  end

--- 40,51 ----

makerule linuxbios_ram.o
      depends    "$(DRIVER) linuxbios.a $(LIBGCC_FILE_NAME)"
!     action    "$(CC) -Wl,--build-id=none -nostdlib -r -o $@ c_start.o 
$(DRIVER) linuxbios.a $(LIBGCC_FILE_NAME)"
  end

makerule linuxbios_ram
      depends    "linuxbios_ram.o $(TOP)/src/config/linuxbios_ram.ld 
ldoptions"
!     action    "$(CC) -Wl,--build-id=none -nostdlib -nostartfiles 
-static -o $@ -T $(TOP)/src/config/linuxbios_ram.ld linuxbios_ram.o"
      action     "$(CROSS_COMPILE)nm -n linuxbios_ram | sort > 
linuxbios_ram.map"
  end
/*************************Patch***********************************************

Signed-off-by: Marc Karasek mailto:[e-mail]

/*********************
Marc Karasek
MTS
Sun Microsystems
mailto:[e-mail]
ph:770.360.6415
*********************/

Carl-Daniel Hailfinger wrote:
> On 03.12.2007 21:18, Marc Karasek wrote:
> > I think I have found the problem.  It is related to the patch Ed sent.
> > The new LD looks like it automagically turns on the --build-id
> > option.  I have not found out how turn it off.
> > When this option is used it generates the   .note.gnu.build-id
> > section.  When this section was discarded in the first ld pass
> > (linuxbios_rom.ram creation) it was causing the segmentation fault crash.
> > It looks like this same option is being called again when crt0.o is
> > linked to create linuxbios.  I have added the .note.gnu.build-id
> > section to the .id section in the ldscript.ld file.
> > SECTIONS {
> >        . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__id_end - __id_start);
> >        .id (.) : {
> >                *(.id)
> >                *(.note.gnu.build-id)
> >        }
> >
> > This has gotten me past the second crash but now linuxbios.strip is
> > crashing.
>
> Well done.
> > nm -n linuxbios | sort > linuxbios.map
> > objcopy --gap-fill 0xff -O binary linuxbios linuxbios.strip
> > objcopy: linuxbios.strip: Bad value
> > objcopy: linuxbios.strip: Bad value
> > make[1]: *** [linuxbios.strip] Error 1
> >
> > So this does not look like a ld problem, but an added feature to ld is
> > causing us grief.  If anyone can figure out how to turn this option
> > off,  that may fix all of this without any patches... :-)
>
> Still, it would be a nice gesture to the binutils guys to report it as a
> bug. Maybe there's some bug deeper down which triggers this.
>
> Regards,
> Carl-Daniel

[Myles Watson]

I know this should tell me something more than it does, but I'm hoping
it helps someone else.

Building v3 and v2 for Qemu fails for me on FC6 with binutils updated
to 2.18.50, but succeeds on FC6-64-bit with the same binutils built
from source.

The error messages are similar

Since they're both targeting the same architecture, that struck me as strange.

Any suggestions?

Thanks,
Myles

v2's failure:

echo '/*ldoptions*/' > ldscript.ld; cat ldoptions >> ldscript.ld ; for
file in  /home/myles/test/buildrom/buildrom-devel/work/coreboot/svn/src/arch/i386/init/ldscript.lb
/home/myles/test/buildrom/buildrom-devel/work/coreboot/svn/src//cpu/x86/16bit/entry16.lds
/home/myles/test/buildrom/buildrom-devel/work/coreboot/svn/src//cpu/x86/32bit/entry32.lds
/home/myles/test/buildrom/buildrom-devel/work/coreboot/svn/src//cpu/x86/16bit/reset16.lds
/home/myles/test/buildrom/buildrom-devel/work/coreboot/svn/src//arch/i386/lib/id.lds
; do echo /* $file */ >> ldscript.ld; cat $file >> ldscript.ld ;
done
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o
/usr/bin/ld: linuxbios: section `.id' can't be allocated in segment 1
LOAD: .id .reset
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make[2]: *** [linuxbios] Error 1
make[2]: Leaving directory
`/home/myles/test/buildrom/buildrom-devel/work/coreboot/svn/targets/emulation/qemu-i386/qemu-i386/image'
make[1]: *** [image/linuxbios.rom] Error 1
make[1]: Leaving directory
`/home/myles/test/buildrom/buildrom-devel/work/coreboot/svn/targets/emulation/qemu-i386/qemu-i386'

v3's failure:

make[1]: Entering directory
`/home/myles/test/buildrom/buildrom-devel/work/coreboot-v3/svn'
  CP      build/config.h
  GEN     build/build.h
  CC      build/stage0.init
/usr/bin/ld: /home/myles/test/buildrom/buildrom-devel/work/coreboot-v3/svn/build/stage0.o:
section `.stage0_1' can't be allocated in segment 0
LOAD: .stage0_1 .resetvector
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make[1]: *** [/home/myles/test/buildrom/buildrom-devel/work/coreboot-v3/svn/build/stage0.init]
Error 1
make[1]: Leaving directory
`/home/myles/test/buildrom/buildrom-devel/work/coreboot-v3/svn'