Hello,
Folks have been using tcc on linux for years and have not reported this as
an issue. Juding from the evidence, the situations where this is
problematic are vanishingly small. That's because it is only an issue when
a library presents the following sort of struct as part of its public api:
struct {
void * some;
double data;
int a : 2;
char vowel;
}
On 32-bit systems, the "int" in the a bitfield force the value of a to have
an alignment of four bytes. But, does the bitfield take four bytes followed
by a single char, causing the struct to consume eight bytes across its last
two members? Or, does the bitfield take a single byte, followed by a char
with a single byte, and two unused bytes? VC++ does the former behavior,
gcc without -mms-bitfields does the latter.
Perl uses gcc's close-packing behavior. That is what made me aware of the
problem. Even so, it is possible to compile perl.h and call functions from
the Perl API with tcc without running into trouble. If you use functions
that only need struct info that comes ahead of this bitfield stuff, you're
layouts will still agree. This means you can directly manipulate s->some,
s->data, and s->a, even when the alignment of vowel is wrong. Obviously if
you pass around pointers to your structs, you can call functions as pass
the pointers without any problems. It's really only an issue in two
circumstances: (1) if you are allowed/expected to directly manipulate the
elements of the struct (or use macros that do so, which was the case with
the Perl API), or (2) if you are supposed to call a function on a struct
directly, rather than passing via a pointer, in which case the stack will
not be properly set up.
Here is a discussion of enabling -mms-bitfields by default for another
project. You might find it informative:
https://groups.google.com/forum/#!topic/cocotron-dev/jwhEynyoZms
To reiterate, there is currently no way to get this to work correctly on
Linux. I'm proposing something that'll make it possible for everyone to
achieve the correct behavior, albeit possibly with an additional
command-line flag if you're on Windows.
David
On Tue, Nov 22, 2016 at 9:40 AM, avih <avih...@yahoo.com> wrote:
> Sounds fine to me to have better interoperability with existing/common
> tools on Linux.
>
> > If a library was compiled on Linux with gcc, there is no way to compile
> consuming code using tcc that is binary-compatible.
>
> Could you please elaborate on the scope of the affected use cases? does it
> apply to both .a and .so libs? I think the windows side has a potential to
> suffer more, if I understand it correctly.
>
> Assuming we take suggestion 1 (so on windows we'd need to invoke tcc with
> special cli flag to set a non default alignment) but we _don't_ use that
> flag, what would work which didn't before? interoperability with gcc? what
> wouldn't work? linking with libs created by native windows tools (MSVC)?
> What about using windows DLLs (which happens almost always as AFAIK
> binaries built with tcc use the ms crt for many things, and tcc comes with
> interfaces definitions to major system DLLs)?
>
> etc.
>
> Thanks.
>
>
> On Tuesday, November 22, 2016 5:16 AM, David Mertens <
> dcmertens.p...@gmail.com> wrote:
>
>
> Hello all,
>
> I have finally found a bit of time to work on this. Just to re-iterate,
> I've found variation in alignment with bitfields across different flavors
> of compilers, and tcc is incompatible with gcc on Linux. If a library was
> compiled on Linux with gcc, there is no way to compile consuming code using
> tcc that is binary-compatible. I've listed the test program and the known
> results below.
>
> I believe the sensible thing to do is to make tcc more gcc-ish. This would
> involve (1) making tcc's default behavior align with gcc's default
> behavior, which appears to be consistent across platforms, and (2)
> providing the -mms-bitfields command-line option for Windows folks who need
> it. This makes binary compatibility possible across both Linux and Windows,
> and asks no more of Windows folks than what gcc asks.
>
> Alternatively, we could make tcc's default behavior configurable. This
> would require an additional configure flag. It would also require both
> -mms-bitfields and -no-mms-bitfields (or whatever the proper name for that
> flag should be). And finally, it would probably be best to make the default
> configuration OS-dependent.
>
> I prefer the first option because (a) it is simpler and (b) any
> configuration tools that think they're working with gcc will be smart
> enough to include the -mms-bitfields flag when it's needed on Windows.
> (Perl's build chain does this, for example.) Pragmatically, it is what I
> have the time to accomplish. I think the second approach is in some ways
> "better", but it'll also add a bunch of configuration code that I think tcc
> would be better without.
>
> Preferences?
> David
>
>
> Here is a re-iteration of known results, and a new one: mingw on Windows.
>
> --------%<--------
> #include <stdint.h>
> #include <stdio.h>
> struct t1 {
> uint8_t op_type:1;
> uint8_t op_flags;
> };
> struct t2 {
> uint32_t op_type:1;
> uint8_t op_flags;
> };
> struct t3 {
> unsigned op_type:1;
> char op_flags;
> };
>
> int main() {
> printf("t1 struct size: %ld\n", sizeof(struct t1));
> printf("t2 struct size: %ld\n", sizeof(struct t2));
> printf("t3 struct size: %ld\n", sizeof(struct t3));
> return 0;
> }
> -------->%--------
>
> With tcc on 64-bit Linux, this prints:
> t1 struct size: 2
> t2 struct size: 8
> t3 struct size: 8
>
> With gcc on 64-bit Linux, this prints:
> t1 struct size: 2
> t2 struct size: 4
> t3 struct size: 4
>
> With i686-w64-mingw32 (i.e. with MinGW on 64-bit Windows), this prints
> t1 struct size: 2
> t2 struct size: 4
> t3 struct size: 4
>
> According to Christian Jullien, VC++ 32 and 64 both return:
> t1 struct size: 2
> t2 struct size: 8
> t3 struct size: 8
>
> --
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." -- Brian Kernighan
>
> _______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
>
> _______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
