[coreboot] Time for a new project

[Segher Boessenkool]

> I will leave it at this: we've had one problem after another with
> ldscripts, ELF creation, ELF parsing, and so on over the years.

SELF will only attack the "ELF parsing" part.  My point is that you
can solve this *within* the ELF framework as well.  And my fears are
that a new, not yet stable format will not help anyone.

> It is
> hard to explain to users that we have to work out a problem and find
> out that THIS version of ubuntu has THAT version of gcc which uses
> THIS  version of gld which, when used with a particular option in an
> ldscript, interacts with a bug in our boot-time ELF parsing code and
> causes someone to be not able to boot. "but it's worked for five years
> ..."

Yeah, you've had your fair share (or more than that!) of such problems,
and so have I.  The GNU binutils are used almost exclusively for hosted
applications, which are a bit of a monoculture.  This results in it
being a bit under-tested for "more interesting" applications (like 
coreboot).

The four steps I use for making this problem manageable are:

0) Use a linker script, _always_;

1) Never rely on other defaults, either;

2) Keep it simple.  It is better to do a few simple build steps
    than to do one big huge complicated ld invocation, esp. since
    those are hard to debug (or understand, even!).

3) Attack the variance in build system versions in your build
    scripts, not in the code, wherever possible.

> What's different about our world vs. the linux world: if this stuff
> happens in the linux world recovery is pretty easy. In our world?
> Well, it can be very hard. We require a higher level of certainty, and
> that in turn (in my view) means a higher level of simplicity, and
> fewer options.

Yes.

> And, while ELF seems simple, in practice, it doesn't
> seem to work out to be simple. Why? I don't know.

I wouldn't blame this on ELF, but on the compiler/binutils used.
It already becomes a *lot* better when you build using a cross
toolchain instead of a native hosted toolchain, but asking users
to install one of those is a large inconvenience.  Besides, it's
easy to mess that up, as well.

> And it's even more fun when you do trivial things with gld, watch it
> dump core, go to the mailing list, and find out the problem has
> existed for four years and no one knows how to fix it, even though
> they've tried.

Yeah.

> So I want our usage of ld to be dead simple, about what the usage is
> for /bin/date.

Bad example, date (and esp. GNU date) is very complicated :-)

> I don't want to count on ld to place things at certain
> offsets in files. It may work this week, and it will probably fail
> next year. The past 8 years of experience says so.

Yes.  "Never rely on defaults, esp. if those aren't documented
defaults".

> My bss problem on v3 with filo came about when the bss was not
> properly place into a loadable segment.

Bad linker script.  I know, easier to say than to fix :-)

> I have no remembrance of what
> combination of gld, rubber bands, paper clips, and bailing wire caused
> that problem. I don't even care any more. I just don't want it to
> happen again :-)

I second that sentiment.  It's not realistic, of course, but hey.

> off to dinner. I am going to watch this discussion from afar, and stay
> away from the keyboard from now on :-) I think you guys will pick out
> the best options.

My current thinking is that since you will have an intermediate ELF
file anyway, that you will transform into a SELF file (which has some
nice properties), that it would be easier and way more future-proof
to transform that intermediate ELF file into a final ELF file (FELF?)
with those same nice properties (junk removed, PHDRs and notes at the
start -- did I forget any?)

> Have a good rest of weekend, everyone!

You too!


Segher