[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linuxbios
Subject:    Re: [coreboot] coreboot build of seabios payload broken
From:       Peter Stuge <peter () stuge ! se>
Date:       2014-05-23 6:05:58
Message-ID: 20140523060558.23474.qmail () stuge ! se
[Download RAW message or body]

Kevin O'Connor wrote:
> I've received a few reports of people having problems building seabios
> within the coreboot build system.  In my investigation I've uncovered
> at least two problems:

Thank you for identifying these problems!

I would suggest that we add two simple tests to coreboot to catch
these problems, until the problems can be completely avoided if that
is at all possible.


> 1 - on my machine, (with CONFIG_ANY_TOOLCHAIN=y) I can't build seabios
> from corebooat at all because of the LD definition.  The .xcompile
> file gets created with:
> 
> LD_x86_32:=ld.bfd -b elf32-i386 -melf_i386
> 
> and this gets passed to SeaBIOS as:
> 
> make -C payloads/external/SeaBIOS [...] LD="ld.bfd -b elf32-i386 -melf_i386"
> 
> unfortunately, the seabios build expects the LD variable to be a
> program - not the combination of a program and parameters.  This
> breaks the build.  (This also seems to happen with AS="as --32".)

If you think it's acceptable for SeaBIOS these variables could be
split into two; LD+LDFLAGS, AS+ASFLAGS, etc.


> 2 - others are reporting problems with python3 even on seabios master
> (when using coreboot's build chain).  This is actually a symptom of a
> much larger issue - for some reason section names are being corrupted
> by the tool chain.  Here's a quick test case:
> 
> echo 'int Foo __attribute__((section( ".data.varfseg." __FILE__ "." "123"  )));' > \
> foo.c ; gcc -c foo.c -o foo.o ; objdump -x foo.o | grep varfseg 
> this should show section names like ".data.varfseg.foo.c.123", but on
> impacted machines the section names are actually showing up as
> ".data.varfseg.".  This truncation of the section names results in
> SeaBIOS not being able to weed out unneeded content from the final
> binary, and it results in the seabios build getting confused on build
> options.

We should test for this as early as possible; ie. in buildgcc.

Great if SeaBIOS tests for it too.


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


[prev in list] [next in list] [prev in thread] [next in thread]