[oe] need help: cdrkit & bitifields

Khem Raj raj.khem at gmail.com
Sat Mar 7 09:37:40 UTC 2009


On Thursday 05 March 2009 13:10:13 Frans Meulenbroeks wrote:
> 2009/3/5 Koen Kooi <k.kooi at student.utwente.nl>:
> > On 05-03-09 18:21, Frans Meulenbroeks wrote:
> >> Ucbit is an unsigned char
> >
> > unsigned char makes me think of
> > http://www.arm.linux.org.uk/docs/faqs/signedchar.php
> >
> > regards,
> >
> > Koen
>
> Well it is explictly defined as unsigned char.
> from utypes.h:
>
> /*
>  * The IBM AIX C-compiler seems to be the only compiler on the world
>  * which does not allow to use unsigned char bit fields as a hint
>  * for packed bit fields. Define a pesical type to avoid warnings.
>  * The packed attribute is honored wit unsigned int in this case too.
>  */
> #if     defined(_AIX) && !defined(__GNUC__)
>
> typedef unsigned int    Ucbit;
>
> #else
>
> typedef unsigned char   Ucbit;
>
> #endif
>
> The link you give is related to chars that are by default signed or
> unsigned
>
> This one seems to be related to whether bitfields are ordered left to
> right or right to left
> (and if I recall correctly in the ansi C standard this is undefined
> (but it has been a while since I checked)
>
> Decided to do some testing. On x86: gcc 4.3.2:
> frans at linux-suse:~/wt> cat tst.c
> #include <stdio.h>
>
> typedef struct {
>     unsigned char bit0:1;
>     unsigned char bits:6;
>     unsigned char bit7:1;
> } bitfields;
>
> main(int argc, char **argv)
> {
>     char c = 0xf0;
>     bitfields *bf = &c;
>
>     printf("bit 0 = %d, bits = %x, bit7 = %x\n", bf->bit0, bf->bits,
> bf->bit7); }
> frans at linux-suse:~/wt> gcc  tst.c
> tst.c: In function ‘main’:
> tst.c:12: warning: initialization from incompatible pointer type
> frans at linux-suse:~/wt> ./a.out
> bit 0 = 0, bits = 38, bit7 = 1
> frans at linux-suse:~/wt> gcc -O1 tst.c
> tst.c: In function ‘main’:
> tst.c:12: warning: initialization from incompatible pointer type
> frans at linux-suse:~/wt> ./a.out
> bit 0 = 0, bits = 38, bit7 = 1
> frans at linux-suse:~/wt> gcc -O2 tst.c
> tst.c: In function ‘main’:
> tst.c:12: warning: initialization from incompatible pointer type
> frans at linux-suse:~/wt> ./a.out
> bit 0 = 0, bits = 1c, bit7 = 1
> frans at linux-suse:~/wt> gcc -O3 tst.c
> tst.c: In function ‘main’:
> tst.c:12: warning: initialization from incompatible pointer type
> frans at linux-suse:~/wt> ./a.out
> bit 0 = 0, bits = 1c, bit7 = 1
>
> Same test on beagle (gcc 4.3.1), -O0  -O1 -O2 -O3
> root at beagleboard:~# ./tst0
> bit 0 = 0, bits = 38, bit7 = 1
> root at beagleboard:~# ./tst1
> bit 0 = 0, bits = 38, bit7 = 1
> root at beagleboard:~# ./tst2
> bit 0 = 0, bits = 20, bit7 = 0
> root at beagleboard:~# ./tst3
> bit 0 = 0, bits = 20, bit7 = 0
>
> Not sure what is happening here.
> I tried to compile cdrkit with -O1 using
> FULL_OPTIMIZATION = "-O1"
> FULL_OPTIMIZATION_armv7a = "-O1"
> BUILD_OPTIMIZATION = "${FULL_OPTIMIZATION}"
> but that did not help either.
>
> There is a compile time macro in gcc called BITS_BIG_ENDIAN but that
> one is set to 0 for arm (same as for x86).
>
> Puzzled....
Frans

There is a gcc bug here you are seeing when you use higher opt level. But this 
may not be cause of your problem here. You could try compiling with -Wcast-
align and see for any new warnings that will pop up. You then need to fix those 
cases.

You could also try -Wpadded and see if any structure is getting implicit 
padding.


Thx

-Khem




More information about the Openembedded-devel mailing list