[coreboot] SELF/ELF/LAR

[Segher Boessenkool]

>> OTOH, the disadvantages of a new format are many.  You'll have to
>> write new tools for dealing with them.  Those tools will have bugs.
>
> Hopefully not so many if the new format is simple. In theory. :p

Sure, but you know that there *will* be bugs, even if not all that
many.

>> The format *itself* will have bugs/shortcomings for quite a while,
>> too.
>
> Well, it will stabilize eventually.

Eventually.

>>> If coreboot supports loading certain ELF files, it will be
>>> surprising to (some) users if it does not support loading
>>> all ELF files.
>>
>> This can be dealt with in the coreboot build system easily enough:
>> just make sure to run the post-processor on all payload files.
>
> Unfortunately that isn't the only way payloads come to coreboot.
>
> lar will eventually be used to replace only the payload in a flash
> chip.
>
> lar can already be used to do so in a .rom file.

I consider LAR to be part of the build system.  We can fight over
terminology all day ;-P

Either way, you have the *exact same* problem here with SELF as
you would have with an ELF-post-processed-to-ELF.  The only
difference between SELF and ELF here is that by using an appropriate
linker script, the ELF case doesn't even need post-processing.
Maybe libpayload can provide such a linker script, dunno.

> I actually don't care what internal representation we use for complex
> binaries in LARs, as long as the lar utility can deal with common ELF
> files, and maybe a few other binary formats too!

LAR shouldn't care *at all*, it should simply be a file container,
like a cpio or an ar or a tar archive.  Trying to make it do more
doesn't really provide any benefits, but it does create huge headaches.
It's a maintenance nightmare.  In short, it's a layering violation.

Btw, the reason LAR was invented, instead of using one of the standard
archive formats, is that none of those standard formats provided the
needed feature set.  SELF on the other hand seems to have no real
benefits over ELF (or pretty much any other existing binary format).

> I don't want a separate preprocessor. We are reinventing mkelfImage.

Not at all: we are defining a standard linking script / standard startup
objects / standard libraries (libpayload!) here, like any other 
execution
environment has.  This makes things *simpler*, not harder.  Or do you
want every payload to redo all this on its own, introducing the same 
bugs
over and over?

I haven't looked at what libpayload provides today, so sorry if this
suggestion is old hand: one way to tackle these "we want to build
payloads outside of coreboot" issues is to provide a "corepayload"
script that will be called like

corepayload compile xxx.c -o xxx.o
corepayload link xxx.o yyy.o -o xyz

or similar.  This script would automatically get all ELF (or SELF)
trickery right, and all other build snafus for that matter.

Comments?


Segher