Re: Conflict between system and compiler types

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

+1

While the OS gets to define the ABI, the compiler gets to implement
specific details such as the calling convention; correctly.

I suspect this can be traced back to when bringing up a new port
consisted of first finding a build machine with a somewhat working and
proprietary compiler and then hitting it with a big stick until it
acted somewhat like the cross compiler we now expect - for instance
hacking include paths so it picked up the target OS's headers and not
the native ones.  Those days are mostly long gone.  We just press a
few buttons and a cross compiler pops out the other end.

On Mon, 4 Feb 2019 at 08:13, Kamil Rytarowski <n54%gmx.com@localhost> wrote:
>
> On 04.02.2019 08:46, matthew green wrote:
> > Martin Husemann writes:
> >> On Mon, Feb 04, 2019 at 05:52:28AM +0000, David Holland wrote:
> >>> They are wrong -- the system ABI is the OS's responsibility
> >>> (including, possibly, compat obligations that the compiler folks don't
> >>> know about and shouldn't have to care about) because it's the OS that
> >>> provides the libraries that the definitions in the system ABI headers
> >>> are supposed to match.
> >>
> >> True, but in this case the compiler has been instructed to compile for
> >> a different ABI, and we may well consider to have our own provided types
> >> being flexible to cope (if it comes at basically no cost).
> >
> > indeed.  we work to keep the compiler and base types the same
> > and when they change, it can be a pain, even if the change is
> > not a change in ABI.  eg, when we added sparc64, we changed
> > some sparc types from 'int' to 'long' so that the would size
> > themselves properly, but this triggered warnings when people
> > had not updated their base headers and compiler at the same
> > time (eg, building a new kernel.)
> >
> > as i understand Kamil's idea, and as we've been using in some
> > ports already for a while, is to let the compiler builtins
> > provide these in our headers, and i think that is a fine
> > idea and we can even use it to eliminate the MD headers from
> > providing these definitions at all (though it would be best
> > to make sure they continue to do so -- but by having them
> > include the MI header, instead of the current opposite.)
> >
>
> We already maintain types in compilers (Clang, GCC) and we could rely on
> them directly.
>
> I've checked that the following types are in GCC, TinyCC, Clang/LLVM, PCC:
>
> __WCHAR_TYPE__
> __SIZE_TYPE__
> __WINT_TYPE__
> __PTRDIFF_TYPE__
>
> The bar for a compiler using our native headers is already higher than
> that so this doesn't change anything.
>
> It's a stronger proposal but we could require these types and remove
> entirely homegrown redefinitions and maintain the types directly in
> compilers.
>
> There is already a header using the compiler builtins.
>
> https://nxr.netbsd.org/xref/src/sys/sys/common_ansi.h#65
>
> OR1K and RISCV use them from the start.
>
> So the current proposal is to replace all src/sys/arch/*/include/ansi.h
> with a single include of sys/common_ansi.h, analogously to RICCV and OR1K.
>
> What do you think?
>
> >
> > .mrg.
> >
>
>