Re: [bug-mes] MesCC should optimize ease of convincing us of its correctness

[Danny Milosavljevic]

Hi Mark,

On Thu, 18 Jul 2019 19:57:36 -0400
Mark H Weaver <address@hidden> wrote:

> Regarding (lack of) conformance to ABIs, the strength of my argument
> here is weaker, but I would feel much more comfortable if structure
> layout matched the relevant ABIs, and if the alignment requirements were
> honored.  The reason is that I have little confidence that
> platform-specific code never makes assumptions about the corresponding
> ABIs.

I'll let Janneke decide, but personally I'm all for being ABI-compatible IF
it's straightforward--I don't think that compiler sources care that certain
types are aligned to 16 Byte in order to be able to use SSE vectorized
instructions on them, for example.  There's all kinds of arcane stuff in ABIs.

My hope is that upstream makes sure to write their compiler (or at
least one version of it) in a way that can be easily bootstrapped by
mescc, so if such reliance were in there they'd eventually remove it.

Long term it's better to get upstream to care about bootstrapping.

In practice, because ABIs are different between different architectures
I think that even now portable programs probably don't rely on the exact
ABI.  It would still be better to be sure, of course.

There should not be platform-specific code in a compiler--at least in the
sense you mean (internal compiler structure layout).  It would be a
maintenance nightmare--and cross compilers would act weird.

For the time being I think having an alignment of 4 Byte for any
simple type would be enough--if only to make the backends less complicated.

This is not the case yet.

All the other alignments are architecture-specific and thus shouldn't
be relied on by portable programs (at least not without checking
first--programs' build scripts could check and the check would fail
and that would be good enough).

It would also be possible to automate checking:

* Make gcc dump the ".lu" unit files when compiling our target program using
gcc
* Extract the structure sizes and offsets from the ".lu" unit files
* Generate a C test (including the struct definition) that makes sure
that offsetof and sizeof report the same values as extracted above.
* Compile the C test using mescc and run it.  If it fails, the target program
wants something more than we provide.

That would automate checking, but it would not be bootstrappable (where to
get that gcc?  Right...).  But it would be nice to have regardless.

(P.S. the "stat" test is failing on ARM if mescc is selected as the
compiler in mes, and the non-alignment is probably why)

>The function calling convention is probably unimportant, and I
> suspect that's the most important corner to cut, for purposes of keeping
> MesCC simple.

I agree.

pgp_mNU_8RYVL.pgp
Description: OpenPGP digital signature