[coreboot] Time for a new project

[Segher Boessenkool]

>>> The entry point(main) has to end up at byte 0 of coreboot.initram if
>>> we want to avoid storing it outside the file.
>>
>> That doesn't seem to be guaranteed by these commands, indeed.
>
> Any way to force the first instruction of main() to be at byte 0 of the
> final binary when the startup (crt0) code is in a separate binary?

Even if you do some of the startup administrativa elsewhere, you still
have some startup code in your binary -- that is what "main" _is_, if
you look at it from a certain angle.  Or you can simply do a crt that
does nothing more than declare the entry point (symbol _start, usually),
and branch to main.

The compiler doesn't care about these things, and it shouldn't.  This
is linker land, and it's not a hard problem.

> That's what I meant with "having the entry point at the beginning of
> initram". Unless the linker reorders functions (without breaking all 
> the
> PIC code),

The linker will reorder stuff if you tell it to; and it will put stuff
in the order you want, if you tell it to do _that_.  Just tell it what
you want, don't rely on defaults, and certainly don't rely on things
that you aren't guaranteed in the linker documentation.

> this means the code section generated by gcc has to begin
> with the compiled body of main() and I see no way to ensure that,
> especially when using the -combine parameter. If that is possible with
> current (and older) gcc, I'd appreciate a hint how to achieve this.

You could put main() in a separate section, and tell the linker to put
that section first in the output binary.  But there's no need to play
games like that.


Segher