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