Hi all,
I am a bit worried and confused about this patch:
Op di 31-10-2006, om 00:59 schreef Pedro Alves:
> Hi all,
>
> I am commiting this patch that cleans up gcc's support of Windows CE for
> arm.
>
> This patch fixes some major bugs/annoyances we had:
>
> - __declspec(dllexport/dllimport) was so broken that it was hurting.
> We weren't passing -export= in .drectve properly,
> so the linker would default to exporting everything. If you used .def
> files, this would go unnoticed.
>
> - We had some major violations of WinCE's ABI:
>
> Currently this test gives wrong results:
> struct abi_check_doubles { char a; double d; };
> struct foo0 { char x; };
> struct foo1 { char x;char :0; char y; };
> struct foo2 { char x; int :0; int :0; int :0; int :0; char y; };
> struct foo3 { char x; char :1; char y; };
> struct foo4 { char x; int :1; char y; };
>
> int main()
> {
> printf ("Size of foo0 is %d, should be 1\n", sizeof (struct foo0));
> printf ("Size of foo1 is %d, should be 2\n", sizeof (struct foo1));
> printf ("Size of foo2 is %d, should be 2\n", sizeof (struct foo2));
> printf ("Size of foo3 is %d, should be 3\n", sizeof (struct foo3));
> printf ("Size of foo4 is %d, should be 12\n", sizeof (struct foo4));
> return 0;
> }
>
> The right results where taken from compiling the test case with MSVC.
> Note that this is a simplified test case.
> If you where experiencing weird crashes before while calling/interfacing
> MSVC/eVC compiled code,
> including the system dlls, this may very well be the reason.
>
> This patch also brings gcc support very close to what should be
> submitted upstream.
compiling the above on an ARM-Linux box yields:
$> ./test
Size of foo0 is 4, should be 1
Size of foo1 is 4, should be 2
Size of foo2 is 8, should be 2
Size of foo3 is 4, should be 3
Size of foo4 is 4, should be 12
This is with
$> gcc --version
gcc (GCC) 3.4.3
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
We should note that this can break a lot of other stuff. We had rather
be using the __packed__ attributed here.
struct abi_check_doubles { char a; double d; };
struct __attribute__((__packed__)) foo0 { char x; };
struct __attribute__((__packed__)) foo1 { char x;char :0; char y; };
struct __attribute__((__packed__)) foo2 { char x; int :0; int :0; int
:0; int :0; char y; };
struct __attribute__((__packed__)) foo3 { char x; char :1; char y; };
struct __attribute__((__packed__)) foo4 { char x; int :1; char y; };
int main()
{
printf ("Size of foo0 is %d, should be 1\n", sizeof (struct foo0));
printf ("Size of foo1 is %d, should be 2\n", sizeof (struct foo1));
printf ("Size of foo2 is %d, should be 2\n", sizeof (struct foo2));
printf ("Size of foo3 is %d, should be 3\n", sizeof (struct foo3));
printf ("Size of foo4 is %d, should be 12\n", sizeof (struct foo4));
return 0;
}
Will yield:
./test
Size of foo0 is 1, should be 1
Size of foo1 is 2, should be 2
Size of foo2 is 2, should be 2
Size of foo3 is 3, should be 3
Size of foo4 is 3, should be 12
Where the foo4 is 3 in my opinion is fully correct.. 12 is pretty large
for 2 chars and 1 bit...
The compiler can do this behaviour on all structs when we have
-fpack-struct when invoking gcc. The manual of gcc however warns about
the behaviour and the resulting binary incompatibilities.
I am not sure about the behaviour of eVC in this respect but the packing
of integers on an ARM processor is pretty much going to slowdown memory
access by a factor of at least four! (each byte is read separately when
unaligned memory access is done.)
I will need to do some more checking on this in respect to eVC.
Jan Rinze.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
