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

[Mark H Weaver]

Hi Danny,

> On Thu, 18 Jul 2019 06:14:46 -0400
> Mark H Weaver <address@hidden> wrote:
>
>> The System V ABI specifies alignment requirements for each C type.
>> Padding must be implicitly inserted in structures to ensure that each
>> field is properly aligned.  MesCC does not do this, and therefore it
>> violates the ABI.
>>
>> For example, see section 3.1.2 (Data Representation) here:
>>
>>   
>> https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf
>>
>> One consequence of this is that MesCC-compiled code cannot reliably be
>> linked with code compiled by other compilers, because there may be
>> disagreements over structure layout.
>
> That is true and a conscious design decision.
>
> In the ARM world, it's even worse, the stack needs to be aligned (to like
> 16 Bytes) on each function call; and even the uses of the register file need
> to be aligned (!).  We don't do those either.

I don't see how you can support non-Intel architectures *at all* without
proper alignment, unless you compile every word access as a set of byte
accesses and use arithmetic to put those bytes together into a word.
Intel is unusual in supporting unaligned access at the architectural
level.

> It was a conscious decision to ignore these in order to simplify the compiler.
> After all, the goal is to have a human read and understand all of the 
> compiler's
> source code, so better if it doesn't do arcane things if we can get away with
> leaving it off.

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.  While it may be easier to
understand the compiler, it casts doubt on whether the compiled programs
will behave correctly.

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.
Those bugs leave me with very little confidence that compiled programs
will work correctly.

> It's true that that precludes liking with code compiled by other compilers,
> but there is no use case for the latter, right?

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.

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

> We don't even optimize division by 1, that's how mimimalist we are...

That doesn't violate the C semantics, so it's fine.

      Thanks,
        Mark