Re: [Tinycc-devel] bitfield handling

[Michael Matz]

Hello,

On Tue, 2 May 2017, grischka wrote:

> Michael Matz wrote:
> > I chose to adjust field layout instead of field type; the latter can cause 
> > invalid mem accesses with packed structs/fields: 
>
> Hi Michael,
>
> May I suggest something:
>
> It appears to me that it's the point of packed (pcc) bitfields that
> all bits are fully tightly packed with no padding whatsoever, such that
> they can be used for decoding bit-stream protocols or some such.

No, the (my) point always was to be compatible with existing compilers in 
the sense that bitfields are layed out as the source author customized to 
$compiler expected/intended or was used to.  All my changes were about GCC 
and MSVC compatibility (for GCC see (*)).  At least insofar as bitfields 
are required in gawk and linux kernel and strange hand-written testcases.

[side mark: The rationale for msvc or pcc or $whatever bitfield layout is 
really of no consequence (i.e why they decided to put the bits here or 
there); most probably nobody can explain anymore why they chose this or 
that specific layout of bit-fields (and in fact many CPU vendors didn't 
think about this at all; they used whatever was default with GCC).  But 
the layout of _tcc_ bitfields IMHO should be clear: they should follow 
whatever the native compiler (i.e. GCC or MSVC)  is doing.; if 
realistically possible]

Yes, we could simplify the bitfield layout code quite much by ignoring 
this aspect (i.e. devise a TCC specific layout and be done with all the 
strangenesses).  IMHO we shouldn't.

> "More or less" packed isn't better than not at all in that case
> because it is just not what people will expect (I suppose).
>
> Therefor I'd suggest to revert the layout code to the point where it
> actually was producing the correct layout, then comment out the
> pcc:packed part and substitute by a warning "currently unsupported",
> for now.

So ... (as per above) reversion is IMHO out of question, all the changes 
were made for a reason.  Perhaps my comments are crappy (and I'd admit 
that parts of them are crappy because the bitfield layout code in GCC is 
_really_ complicated and that I skimmed over details) but that shouldn't 
stand in the way of code.

OTOH your mentioning of "to the point where it actually was producing the 
correct layout" indicates that it's not producing correct (i.e. expected) 
layout/code anymore.  Examples?  Because, really, I fixed struct bit-field 
incompatibilities with both MSVC and GCC, and hence am interested where 
it's getting things still wrong.  (Yes, the recent report was an example. 
I haven't checked if it got everything right before by design or luck, or 
superstition.)  Still, other examples where things go wrong would be 
appreciated. :)


Ciao,
Michael.

(*) GCC compatibility: GCC started out as alternative compiler for $random 
platform, where range($random) really was large.  At that time it was 
therefore an alternative compiler for whatever existed on the machine 
(e.g. the C runtime library).  For that GCC needed to emulate all aspects 
of the ABI (how functions are called; at that time the concept of ABI 
wasn't widespread, but existed) that the native compiler would produce 
(e.g. procedure calling conventions for functions in libc).  Many of the 
ABIs were based on whatever PCC (portable C compiler) produced, they 
weren't in fact really thought out, especially in the corner aspects 
(bit-fields!).  So, in the end many of the traditional unix ABIs for 
random architectures are actually just what "the" compiler happened to 
produce".  And from then it went "oh, but we need to be compatible". 
That's why PCC bit-field layout still exists, and isn't just called GCC 
bit-field layout; because it isn't.  It's the traditional "if I don't do 
anything special then this is what I get" layout :)