[coreboot] Time for a new project
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
> 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