[LinuxBIOS] [PATCH] v3: Crash with a descriptive message in case of compiler bugs

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
>
>
> If you want to boot v3 on any hardware target, yes. The reason Ron is
> seeing crashes in pll_reset is exactly the same reason why this patch
> causes a crash as well. Basically, we not only use the wrong compiler
> options for initram, we also use the wrong linker options for initram.
> Both happen to work by accident in combination, but only for the Qemu
> target. Once the patch is applied, Qemu behaviour mirrors hardware
> target behaviour.
>   
Why do you say the linker and compiler options are wrong? Sounds like
magic. Mind to share an explanation or a fix for the less enlighted ;-))
> Oh, and btw, the gcc behaviour we depend on is undocumented and
> partially undefined and may change with the moon phase.
Oh sure. But its not the moon phase, people probably sit there and have
good ideas and valid reasons for their changes. As we had when choosing
that set of compiler options. We just have a little communication
problem here.

As I mentioned since the time this was first discussed: The clean way of
solving the inter-stage function calls is with a function pointer array
at a fixed position in the bootblock, defining a fixed API.

> The patch
> actually gives us a chance to verify later that gcc did what we wanted.
>   
How is that? In what cases do we have to do that verification?

Maybe we can build that test into the build system, namely xcompile?
Maybe a stripped down test that can automatically be analyzed? Then we
could warn about "broken" toolchains.

We will be facing problems with tool chains until we grow old  and gray.
These compilers are just not made for writing firmware. Nor did anyone
writing them ever have firmware in mind. In fact, they tend to be
wonderful for writing Linux userspace applications. Most of the time.
For what we do, those tools are usually too smart. They don't just
compile and link but take estimates on our intentions. We need to learn
to talk our problems to the gcc community and have their input. Or we
change our architecture so that such problems just don't appear.

All the best,

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071202/2d7b8400/attachment.sig>