[coreboot] Time for a new project

[Carl-Daniel Hailfinger]

On 13.04.2008 02:11, Segher Boessenkool wrote:
>>>> Some Linux kernel verification mechanisms have caught compiler bugs in
>>>> the past. That's why I considered the possibility to do this as well.
>>>>
>>>
>>> The only ones that I am aware of are *generic* sanity checks in the
>>> kernel, that manage to trip on something that turned out to be a
>>> compiler
>>> bug.  Adding specific sanity checks for every piece of code that only
>>> checks for compiler bugs is foolishness (hint: it's impossible to ever
>>> get even 1% cover; and that check code itself is run through that same
>>> compiler anyway!)
>>
>> Well, possibly catching compiler bugs would have been a nice (yet
>> improbable) side effect. The decompression of a large chunk of data is
>> probably taxing memory a bit more than our current simple memtest
>> implementation and checksumming the result may have uncovered bugs in
>> RAM configuration.
>> But we can postpone/skip that.
>
> IMHO opinion, if you want to test RAM, it is better to test RAM
> explicitly
> than to hope some simple checksum of <some random data> will catch this.
> It's also a lot cleaner design, of course.

OK.

>>>> Unless you fork gcc, having the entry point at the beginning of
>>>> initram
>>>> is not possible. It worked by accident in the past and I'm pretty sure
>>>> Segher will confirm that we can't rely on that.
>>>>
>>>
>>> No, I confirm you *can* rely on that: just set up your linker script
>>> and your crt.o so this works.  Something like
>>>
>>>          .start : { crt0.o(*) }
>>>          .text : { *(.text) }
>>>          .data : { *(.data) }
>>>
>>> will guarantee that all of crt0 ends up before anything else (and there
>>> is no need to make it a separate section, FWIW).
>>
>> Hm. Does that really apply to the initram binary we produce in v3?
>
> I don't know what the current v3 code does.  I'm just replying to your
> "cannot be done, it's GCC's fault", while GCC isn't even in the picture
> if your code is sane at all.

In doubt, the code does not qualify for your definition of "sane".

>> AFAIK we don't link any crt0 into that binary.
>
> You have *some* equivalent code, for sure.  Some startup code that
> initialises things to conform to the ABI environment expected by
> the compiler (initial stack frame, segments, GOT/TOC/PLT/TLS pointers,
> etc -- that kind of thing).

Ah, that. That startup code ends up in a separate binary.

>> Here are the commands used to
>> generate coreboot.initram:
>>
>> $(CC) $(INITCFLAGS) -D_SHARED -fPIE -c -combine $(INITRAM_OBJ) -o
>> $(obj)/coreboot.initram_partiallylinked.o
>> $(LD) -Ttext 0 --entry main -N -R $(obj)/stage0-prefixed.o
>> $(obj)/coreboot.initram_partiallylinked.o -o $(obj)/coreboot.initram
>>
>> 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?
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), 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.


Regards,
Carl-Daniel