[coreboot] Time for a new project

Segher Boessenkool segher at kernel.crashing.org
Sun Apr 13 02:53:59 CEST 2008

>>> 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.


More information about the coreboot mailing list