[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] bitfield handling
From: |
Michael Matz |
Subject: |
Re: [Tinycc-devel] bitfield handling |
Date: |
Wed, 3 May 2017 01:56:10 +0200 (CEST) |
User-agent: |
Alpine 2.20 (LSU 67 2015-01-07) |
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 :)