Re: [bug-mes] MesCC neglects alignment requirements of the System V ABI

[Danny Milosavljevic]

Hi Mark,

On Thu, 18 Jul 2019 14:40:08 -0400
Mark H Weaver <address@hidden> wrote:

> I don't see how you can support non-Intel architectures *at all* without
> proper alignment

I agree.

On ARM, as far as mescc is concerned, all registers are words.  64 bit types
are (supposed to be) simulated using structs (so there are only 4-Byte aligned
struct members and, as far as the compiler is concerned, there are no
non-composite types larger than 4 Byte, or even != 4 Byte).

The actual local variables are always on the stack.
The stack values are always words, too.
Parameters are always on the stack.

The registers that are used at all are used when issuing the instruction in
order to include the operands' values.  These are three registers.

But notice that the official ARM EABI requirements are *16* Byte aligned stack
on function entry - that's a lot more than the 4 Byte a word has.  And
the former is what we don't do while the latter is what we always do,
even for Bytes.

It would not be practically possible to review something that does everything
that POSIX, the ABI and the C standard requires (that would likely end up
being just as large as gcc, right?).  Therefore, we cut corners where safe.
One of the corners is not to link to foreign libraries and thus drop almost the
entire ABI requirement.  Then we only implement the part of POSIX that is in
use by gcc and binutils (which is not large at all) and so drop most of POSIX.

We can't drop anything of the C standard that tcc, gcc and binutils actually
use in their source, so we shouldn't.

But we should remove everything else permissible in order to get mescc as short
and simple to review as humanly possible.

>, unless you compile every word access as a set of byte
>> accesses and use arithmetic to put those bytes together into a word.

No.

> If the goal is to have confidence that the compiled programs behave
> correctly, then I think that you make the problem worse by cutting
> corners and violating the C semantics.

Oh, we don't intentionally violate C semantics.

The ABI is separate from that and the C standard doesn't say anything about
that, it just specifies an "abstract machine" semantics.

> On that question, another set of bugs that I recently reported is much
> more likely to be problematic than this one, namely the apparent lack of
> support for integer promotions and the usual arithmetic conversions.

That is bad - and also easy to fix.  Basically promote each set of operands
to the larger ones.

> I'm not sure.  Do some Linux system calls use C structs to pass
> information between user space and the kernel, and therefore assume that
> the kernel and userspace agree on structure layout?  I don't know off
> hand.

Yes.  There exist such system calls.

But keep in mind that mescc is supposed to only compile compilers - and for
that we shouldn't need any system calls more complicated than
open/read/write/close/stat.  Those few that did come up (mainly in
binutils etc) we have implemented and added tests.

> Is there any code that passes raw structs over a network socket, or to
> read/write data to disk?  I don't know.

Maybe, but the goal is not to have a universal compiler - IMO it's a bootstrap
compiler in order to bootstrap another compiler.  It's not a drop-in
replacement for a distribution's primary compiler.

pgpbtVt6OL0rI.pgp
Description: OpenPGP digital signature