egcs and bitfields

egcs and bitfields

[David A. Greene]

I sent this question to the list a few days ago but got
no response.  Can someone please help me out?

I'm trying to figure out the alignment rules that egcs 
uses for bitfields under Linux 2.0.x.  It seems that egcs 
does not follow the System V ABI stardard.  Specifically, 
the part about not allowing bitfields to cross the 
alignment boundaries of their base types (i.e. int c:17 
should not cross a 32-bit boundary, but egcs allows it).  
Also, bitfields declared "int" are treated as signed by 
egcs while the System V ABI indicates they are unsigned.

What ABI is egcs conforming to?  I need some detailed 
information as we need to interface to code compiled by
egcs.

Thanks!

                                -Dave

Re: egcs and bitfields

[Martin v. Loewis]

> I sent this question to the list a few days ago but got
> no response.  Can someone please help me out?

I think the problem with your previous report was that it was hard to
understand. I tried to come up with a program that demonstrates your
problem, and I got

struct baz { unsigned int a:2, b:4, c:32;} y;

void foo()
{
  y.c = 0x56789;
}

int main()
{
  unsigned int  *b;
  bzero(&y,sizeof(y));
  foo();
  b=&y;
  printf("%x %x\n",b[0],b[1]);
}

Is this the case you are talking about? Now, you claim that the SysV
ABI requires y.c to be at offset 4, right? (this is a claim I can't
verify since I don't have that specification)

Anyway, when I run the program on i586-pc-linux-gnu, with
egcs-2.93.11, I get as output

0 56789

From your explanation, I understand that this result is
ABI-compliant. So where is the problem?

Regards,
Martin

Re: egcs and bitfields

[Robert Lipe]

> struct baz { unsigned int a:2, b:4, c:32;} y;
> 
> void foo()
> {
>   y.c = 0x56789;
> }
> 
> int main()
> {
>   unsigned int  *b;
>   bzero(&y,sizeof(y));
>   foo();
>   b=&y;
>   printf("%x %x\n",b[0],b[1]);
> }
> 
> Is this the case you are talking about? Now, you claim that the SysV
> ABI requires y.c to be at offset 4, right? (this is a claim I can't
> verify since I don't have that specification)

"System V ABI" is too vague for purposes of this discussion.  Do you
refer to the iBCS2 spec or the SVR4 ABI?  I don't know that they differ
in this regard, but it isn't an unreasonable question before tearing
into large books.

> Anyway, when I run the program on i586-pc-linux-gnu, with
> egcs-2.93.11, I get as output
> 
> 0 56789
> 
> From your explanation, I understand that this result is
> ABI-compliant. So where is the problem?

I fed this example into the following compilers on a system V/386 host:
	SCO OpenServer /bin/cc
	UDK cc (essentially the SVR4 ABI)
	EGCS 1.1.1
	Intel's optimizing compiler
It produced identical output on all of them.



I think (but am no authority) that Linux uses substantially the SVR4 ABI
but it does have some deviations.

RJL

Re: egcs and bitfields

[Robert Lipe]

> struct baz { unsigned int a:2, b:4, c:32;} y;
> 
> void foo()
> {
>   y.c = 0x56789;
> }
> 
> int main()
> {
>   unsigned int  *b;
>   bzero(&y,sizeof(y));
>   foo();
>   b=&y;
>   printf("%x %x\n",b[0],b[1]);
> }
> 
> Is this the case you are talking about? Now, you claim that the SysV
> ABI requires y.c to be at offset 4, right? (this is a claim I can't
> verify since I don't have that specification)

"System V ABI" is too vague for purposes of this discussion.  Do you
refer to the iBCS2 spec or the SVR4 ABI?  I don't know that they differ
in this regard, but it isn't an unreasonable question before tearing
into large books.

> Anyway, when I run the program on i586-pc-linux-gnu, with
> egcs-2.93.11, I get as output
> 
> 0 56789
> 
> From your explanation, I understand that this result is
> ABI-compliant. So where is the problem?

I fed this example into the following compilers on a system V/386 host:
	SCO OpenServer /bin/cc
	UDK cc (essentially the SVR4 ABI)
	EGCS 1.1.1
	Intel's optimizing compiler
It produced identical output on all of them.



I think (but am no authority) that Linux uses substantially the SVR4 ABI
but it does have some deviations.

RJL

Re: egcs and bitfields

[David A. Greene]

Martin v. Loewis wrote:
> 
> > I sent this question to the list a few days ago but got
> > no response.  Can someone please help me out?
> 
> I think the problem with your previous report was that it was hard to
> understand. I tried to come up with a program that demonstrates your
> problem, and I got
> 
> struct baz { unsigned int a:2, b:4, c:32;} y;
> 
> void foo()
> {
>   y.c = 0x56789;
> }
> 
> int main()
> {
>   unsigned int  *b;
>   bzero(&y,sizeof(y));
>   foo();
>   b=&y;
>   printf("%x %x\n",b[0],b[1]);
> }
> 
> Is this the case you are talking about? Now, you claim that the SysV
> ABI requires y.c to be at offset 4, right? (this is a claim I can't
> verify since I don't have that specification)
> 
> Anyway, when I run the program on i586-pc-linux-gnu, with
> egcs-2.93.11, I get as output
> 
> 0 56789
> 
> >From your explanation, I understand that this result is
> ABI-compliant. So where is the problem?

From this example, things look right.  Let me check my example
again.  Maybe I goofed!

Oh boy...It appears as though "gcc" on our machines has magically become
gcc-2.7.2.3 rather than egcs-1.1.1 as it used to be.  egcs in fact
functions correctly.  gcc-2.7.2.3 does not.

Our sysadmins will be hearing about this...  >:-[

Sorry to bother everyone with this "problem."

However, the signedness problem still seems to be there:

#include <stdio.h>

struct foo { int c:3; } x = { 7 };

int main(void)
{
  printf("%d\n", x.c);

  return(0);
}

>>-drakh-> egcc fieldinit.c
>>-drakh-> ./a.out
-1

I think the output should be 7, since an "int"
 bitfield is supposed
to be unsigned according to the i386 SysV ABI.

>>-drakh-> egcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.60/specs
gcc version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release)


                                            -Dave

Re: egcs and bitfields

[Robert Lipe]

> #include <stdio.h>
> 
> struct foo { int c:3; } x = { 7 };
> 
> int main(void)
> {
>   printf("%d\n", x.c);
> 
>   return(0);
> }
> 
> >>-drakh-> egcc fieldinit.c
> >>-drakh-> ./a.out
> -1
> 
> I think the output should be 7, since an "int"
>  bitfield is supposed
> to be unsigned according to the i386 SysV ABI.

While I can't comment on any correctness issues in the example or
pertinence of various ABI specs, I can confirm that your example behaves
differently on different System V/386's.


On OpenServer: 
	/bin/cc		-1
	egcs 1.1.1 	-1
	icc		7
	udk cc		7 

On UnixWare 7.0.1
	/bin/cc		7
	egcs 1.1.1 	-1


Note that /bin/cc on SVR5 is essentially the same as UDK on OSR5.  Since
/bin/cc on OpenServer had parentage in the code that became those two 
compilers, I'm guessing that it was an intentional ABI change between
the OpenServer lineage (more iBCS2-ish) and the SVR4 lineage.

RJL

Re: egcs and bitfields

[Doug Semler]

> > #include <stdio.h>
> > 
> > struct foo { int c:3; } x = { 7 };
> > 
> > int main(void)
> > {
> >   printf("%d\n", x.c);
> > 
> >   return(0);
> > }
> > 
> > >>-drakh-> egcc fieldinit.c
> > >>-drakh-> ./a.out
> > -1
> > 
> > I think the output should be 7, since an "int"
> >  bitfield is supposed
> > to be unsigned according to the i386 SysV ABI.
> 
> While I can't comment on any correctness issues in the example or
> pertinence of various ABI specs, I can confirm that your example behaves
> differently on different System V/386's.
> 
> 
> On OpenServer: 
> 	/bin/cc		-1
> 	egcs 1.1.1 	-1
> 	icc		7
> 	udk cc		7 
> 
> On UnixWare 7.0.1
> 	/bin/cc		7
> 	egcs 1.1.1 	-1
> 
> 
> Note that /bin/cc on SVR5 is essentially the same as UDK on OSR5.  Since
> /bin/cc on OpenServer had parentage in the code that became those two 
> compilers, I'm guessing that it was an intentional ABI change between
> the OpenServer lineage (more iBCS2-ish) and the SVR4 lineage.

I am assuming egcs uses the ABI's definition of whether a bitfield is
signed or unsigned????   According to the standard (6.7.2) unqualified
type int is implementation defined (cf C++ 9.6)

So, does egcs use the same implementation across all platforms?

---
Doug Semler                       | doug@seaspace.com
SeaSpace Corporation              | Garbage In -- Gospel Out
Least Senior Software Developer;  | Minister of things to do Next Quarter
Low Man on the Totem Pole         | (but will Never Be Done) DNRC  O-
A closed mind is a terrible thing | Bus Error (passengers dumped)
  
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/M d---(pu) s++:- a-- C++ UILSH+++$ P--- L++ E--- W+
N++ o-- K? w--(++$) O- M-- V- PS+ !PE Y PGP t(+) 5+++ X+
R- tv+(-) b+(++) DI++++ D G e++>++++ h!>--- r% y+>+++++**
------END GEEK CODE BLOCK------

Re: egcs and bitfields

[Robert Lipe]

> > On OpenServer: 
> > 	/bin/cc		-1
> > 	egcs 1.1.1 	-1
> > 	icc		7
> > 	udk cc		7 
> > 
> > On UnixWare 7.0.1
> > 	/bin/cc		7
> > 	egcs 1.1.1 	-1
> > 
> > 
> > Note that /bin/cc on SVR5 is essentially the same as UDK on OSR5.  Since
> > /bin/cc on OpenServer had parentage in the code that became those two 
> > compilers, I'm guessing that it was an intentional ABI change between
> > the OpenServer lineage (more iBCS2-ish) and the SVR4 lineage.

A supplementary info, look in gcc.texi and search for "ABI standard".
It seems this is a well-documented and well-characterized behaviour 
in GCC.   I think that wraps this issue up.

> I am assuming egcs uses the ABI's definition of whether a bitfield is
> signed or unsigned????   

Not according to that document.  It says that GCC is meant to be
consistent, regardless of any ABI definition but that you can overide
it with a command line flag.

> According to the standard (6.7.2) unqualified
> type int is implementation defined (cf C++ 9.6)
> 
> So, does egcs use the same implementation across all platforms?


According to that info node, yes.

RJL

Re: egcs and bitfields

[Robert Lipe]

> > On OpenServer: 
> > 	/bin/cc		-1
> > 	egcs 1.1.1 	-1
> > 	icc		7
> > 	udk cc		7 
> > 
> > On UnixWare 7.0.1
> > 	/bin/cc		7
> > 	egcs 1.1.1 	-1
> > 
> > 
> > Note that /bin/cc on SVR5 is essentially the same as UDK on OSR5.  Since
> > /bin/cc on OpenServer had parentage in the code that became those two 
> > compilers, I'm guessing that it was an intentional ABI change between
> > the OpenServer lineage (more iBCS2-ish) and the SVR4 lineage.

A supplementary info, look in gcc.texi and search for "ABI standard".
It seems this is a well-documented and well-characterized behaviour 
in GCC.   I think that wraps this issue up.

> I am assuming egcs uses the ABI's definition of whether a bitfield is
> signed or unsigned????   

Not according to that document.  It says that GCC is meant to be
consistent, regardless of any ABI definition but that you can overide
it with a command line flag.

> According to the standard (6.7.2) unqualified
> type int is implementation defined (cf C++ 9.6)
> 
> So, does egcs use the same implementation across all platforms?


According to that info node, yes.

RJL

Re: egcs and bitfields

[Martin v. Loewis]

> I am assuming egcs uses the ABI's definition of whether a bitfield is
> signed or unsigned????

No.

> So, does egcs use the same implementation across all platforms?

Yes. Please the the 'Non-bugs section' in the GCC manual for a
rationale. The idea is exactly that: Work the same on all platforms,
no matter what the ABI says. It's a language issue, not one of binary
compatibility.

Regards,
Martin

Re: egcs and bitfields

[Doug Semler]

> > I am assuming egcs uses the ABI's definition of whether a bitfield is
> > signed or unsigned????
> 
> No.

Ooops, it was a typo.... I knew that egcs is (meant to be) consistent
across platforms...that's one of the main reasons we use it in house. 
I meant to write:

Are you assuming egcs uses the ABI's ... etc

(I should get more sleep :))


---
Doug Semler                       | doug@seaspace.com
SeaSpace Corporation              | Garbage In -- Gospel Out
Least Senior Software Developer;  | Minister of things to do Next Quarter
Low Man on the Totem Pole         | (but will Never Be Done) DNRC  O-
A closed mind is a terrible thing | Bus Error (passengers dumped)
  
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/M d---(pu) s++:- a-- C++ UILSH+++$ P--- L++ E--- W+
N++ o-- K? w--(++$) O- M-- V- PS+ !PE Y PGP t(+) 5+++ X+
R- tv+(-) b+(++) DI++++ D G e++>++++ h!>--- r% y+>+++++**
------END GEEK CODE BLOCK------

Re: egcs and bitfields

[Doug Semler]

> > I am assuming egcs uses the ABI's definition of whether a bitfield is
> > signed or unsigned????
> 
> No.

Ooops, it was a typo.... I knew that egcs is (meant to be) consistent
across platforms...that's one of the main reasons we use it in house. 
I meant to write:

Are you assuming egcs uses the ABI's ... etc

(I should get more sleep :))


---
Doug Semler                       | doug@seaspace.com
SeaSpace Corporation              | Garbage In -- Gospel Out
Least Senior Software Developer;  | Minister of things to do Next Quarter
Low Man on the Totem Pole         | (but will Never Be Done) DNRC  O-
A closed mind is a terrible thing | Bus Error (passengers dumped)
  
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/M d---(pu) s++:- a-- C++ UILSH+++$ P--- L++ E--- W+
N++ o-- K? w--(++$) O- M-- V- PS+ !PE Y PGP t(+) 5+++ X+
R- tv+(-) b+(++) DI++++ D G e++>++++ h!>--- r% y+>+++++**
------END GEEK CODE BLOCK------

Re: egcs and bitfields

[Martin v. Loewis]

> I am assuming egcs uses the ABI's definition of whether a bitfield is
> signed or unsigned????

No.

> So, does egcs use the same implementation across all platforms?

Yes. Please the the 'Non-bugs section' in the GCC manual for a
rationale. The idea is exactly that: Work the same on all platforms,
no matter what the ABI says. It's a language issue, not one of binary
compatibility.

Regards,
Martin

Re: egcs and bitfields

[Doug Semler]

> > #include <stdio.h>
> > 
> > struct foo { int c:3; } x = { 7 };
> > 
> > int main(void)
> > {
> >   printf("%d\n", x.c);
> > 
> >   return(0);
> > }
> > 
> > >>-drakh-> egcc fieldinit.c
> > >>-drakh-> ./a.out
> > -1
> > 
> > I think the output should be 7, since an "int"
> >  bitfield is supposed
> > to be unsigned according to the i386 SysV ABI.
> 
> While I can't comment on any correctness issues in the example or
> pertinence of various ABI specs, I can confirm that your example behaves
> differently on different System V/386's.
> 
> 
> On OpenServer: 
> 	/bin/cc		-1
> 	egcs 1.1.1 	-1
> 	icc		7
> 	udk cc		7 
> 
> On UnixWare 7.0.1
> 	/bin/cc		7
> 	egcs 1.1.1 	-1
> 
> 
> Note that /bin/cc on SVR5 is essentially the same as UDK on OSR5.  Since
> /bin/cc on OpenServer had parentage in the code that became those two 
> compilers, I'm guessing that it was an intentional ABI change between
> the OpenServer lineage (more iBCS2-ish) and the SVR4 lineage.

I am assuming egcs uses the ABI's definition of whether a bitfield is
signed or unsigned????   According to the standard (6.7.2) unqualified
type int is implementation defined (cf C++ 9.6)

So, does egcs use the same implementation across all platforms?

---
Doug Semler                       | doug@seaspace.com
SeaSpace Corporation              | Garbage In -- Gospel Out
Least Senior Software Developer;  | Minister of things to do Next Quarter
Low Man on the Totem Pole         | (but will Never Be Done) DNRC  O-
A closed mind is a terrible thing | Bus Error (passengers dumped)
  
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/M d---(pu) s++:- a-- C++ UILSH+++$ P--- L++ E--- W+
N++ o-- K? w--(++$) O- M-- V- PS+ !PE Y PGP t(+) 5+++ X+
R- tv+(-) b+(++) DI++++ D G e++>++++ h!>--- r% y+>+++++**
------END GEEK CODE BLOCK------

Re: egcs and bitfields

[Robert Lipe]

> #include <stdio.h>
> 
> struct foo { int c:3; } x = { 7 };
> 
> int main(void)
> {
>   printf("%d\n", x.c);
> 
>   return(0);
> }
> 
> >>-drakh-> egcc fieldinit.c
> >>-drakh-> ./a.out
> -1
> 
> I think the output should be 7, since an "int"
>  bitfield is supposed
> to be unsigned according to the i386 SysV ABI.

While I can't comment on any correctness issues in the example or
pertinence of various ABI specs, I can confirm that your example behaves
differently on different System V/386's.


On OpenServer: 
	/bin/cc		-1
	egcs 1.1.1 	-1
	icc		7
	udk cc		7 

On UnixWare 7.0.1
	/bin/cc		7
	egcs 1.1.1 	-1


Note that /bin/cc on SVR5 is essentially the same as UDK on OSR5.  Since
/bin/cc on OpenServer had parentage in the code that became those two 
compilers, I'm guessing that it was an intentional ABI change between
the OpenServer lineage (more iBCS2-ish) and the SVR4 lineage.

RJL

Re: egcs and bitfields

[Martin v. Loewis]

> #include <stdio.h>
> 
> struct foo { int c:3; } x = { 7 };
> 
> int main(void)
> {
>   printf("%d\n", x.c);
> 
>   return(0);
> }

Ok, I can reproduce this printing -1. Yet, it still took me a while to
understand the problem. If you had provided proper references and
quotes, that would have been nice... Here's what I found:

The C standard explicitly leaves it unspecified whether an int
bitfield is signed or unsigned. In draft C9x, 6.7.2/5 says

>> Each of the comma-separated sets designates the same type, except
>> that for bit-fields, it is implementation-defined whether the
>> specifier int designates the same type as signed int or the same
>> type as unsigned int.

Now, the gcc documentation says, in the command-line-flags section,

`-fsigned-bitfields'
`-funsigned-bitfields'
`-fno-signed-bitfields'
`-fno-unsigned-bitfields'
     These options control whether a bitfield is signed or unsigned,
     when the declaration does not use either `signed' or `unsigned'.
     By default, such a bitfield is signed, because this is consistent:
     the basic integer types such as `int' are signed types.

     However, when `-traditional' is used, bitfields are all unsigned
     no matter what.

Indeed, when I compile your program with -funsigned-bitfields, it
gives the output '7', on i586-pc-linux-gnu.

Please have a look at the section 'Non-bugs' in the GCC manual. It
explains, in an elaborate way, why things are the way they are (and
yes, I've read this section for the first time today :-)

If you still think there is a bug, please make a detailed report to
egcs-bugs@cygnus.com. I think in this case, such a report should also
go to gcc-bugs@gnu.org.

Regards,
Martin

Re: egcs and bitfields

[David A. Greene]

Martin v. Loewis wrote:

> Ok, I can reproduce this printing -1. Yet, it still took me a while to
> understand the problem. If you had provided proper references and
> quotes, that would have been nice... Here's what I found:

I apologize for that.  I was under the impression that there was one
"i386 System V ABI."   As a lowly student I sort of assumed an ABI
was a well-defined standard that specified interfaces between object
code.  Guess I was wrong.

> The C standard explicitly leaves it unspecified whether an int
> bitfield is signed or unsigned. In draft C9x, 6.7.2/5 says

Exactly.  This is C.

> Now, the gcc documentation says, in the command-line-flags section,
> 
> `-fsigned-bitfields'
> `-funsigned-bitfields'
> `-fno-signed-bitfields'
> `-fno-unsigned-bitfields'
>      These options control whether a bitfield is signed or unsigned,
>      when the declaration does not use either `signed' or `unsigned'.
>      By default, such a bitfield is signed, because this is consistent:
>      the basic integer types such as `int' are signed types.
> 
>      However, when `-traditional' is used, bitfields are all unsigned
>      no matter what.

Ok, I missed this completely.  My fault for not looking at the docs.
I never thought there would be flags for this, as it seems to me that
you'd want a compiler to adhere to a standard interface.

> Please have a look at the section 'Non-bugs' in the GCC manual. It
> explains, in an elaborate way, why things are the way they are (and
> yes, I've read this section for the first time today :-)

:)  Ok, I'll have a look...a good bit of reading, that.  It answers
a lot of questions, even if I don't agree with those answers.  :)

Thanks!

                                       -Dave

Re: egcs and bitfields

[David A. Greene]

Martin v. Loewis wrote:

> Ok, I can reproduce this printing -1. Yet, it still took me a while to
> understand the problem. If you had provided proper references and
> quotes, that would have been nice... Here's what I found:

I apologize for that.  I was under the impression that there was one
"i386 System V ABI."   As a lowly student I sort of assumed an ABI
was a well-defined standard that specified interfaces between object
code.  Guess I was wrong.

> The C standard explicitly leaves it unspecified whether an int
> bitfield is signed or unsigned. In draft C9x, 6.7.2/5 says

Exactly.  This is C.

> Now, the gcc documentation says, in the command-line-flags section,
> 
> `-fsigned-bitfields'
> `-funsigned-bitfields'
> `-fno-signed-bitfields'
> `-fno-unsigned-bitfields'
>      These options control whether a bitfield is signed or unsigned,
>      when the declaration does not use either `signed' or `unsigned'.
>      By default, such a bitfield is signed, because this is consistent:
>      the basic integer types such as `int' are signed types.
> 
>      However, when `-traditional' is used, bitfields are all unsigned
>      no matter what.

Ok, I missed this completely.  My fault for not looking at the docs.
I never thought there would be flags for this, as it seems to me that
you'd want a compiler to adhere to a standard interface.

> Please have a look at the section 'Non-bugs' in the GCC manual. It
> explains, in an elaborate way, why things are the way they are (and
> yes, I've read this section for the first time today :-)

:)  Ok, I'll have a look...a good bit of reading, that.  It answers
a lot of questions, even if I don't agree with those answers.  :)

Thanks!

                                       -Dave

Re: egcs and bitfields

[Martin v. Loewis]

> #include <stdio.h>
> 
> struct foo { int c:3; } x = { 7 };
> 
> int main(void)
> {
>   printf("%d\n", x.c);
> 
>   return(0);
> }

Ok, I can reproduce this printing -1. Yet, it still took me a while to
understand the problem. If you had provided proper references and
quotes, that would have been nice... Here's what I found:

The C standard explicitly leaves it unspecified whether an int
bitfield is signed or unsigned. In draft C9x, 6.7.2/5 says

>> Each of the comma-separated sets designates the same type, except
>> that for bit-fields, it is implementation-defined whether the
>> specifier int designates the same type as signed int or the same
>> type as unsigned int.

Now, the gcc documentation says, in the command-line-flags section,

`-fsigned-bitfields'
`-funsigned-bitfields'
`-fno-signed-bitfields'
`-fno-unsigned-bitfields'
     These options control whether a bitfield is signed or unsigned,
     when the declaration does not use either `signed' or `unsigned'.
     By default, such a bitfield is signed, because this is consistent:
     the basic integer types such as `int' are signed types.

     However, when `-traditional' is used, bitfields are all unsigned
     no matter what.

Indeed, when I compile your program with -funsigned-bitfields, it
gives the output '7', on i586-pc-linux-gnu.

Please have a look at the section 'Non-bugs' in the GCC manual. It
explains, in an elaborate way, why things are the way they are (and
yes, I've read this section for the first time today :-)

If you still think there is a bug, please make a detailed report to
egcs-bugs@cygnus.com. I think in this case, such a report should also
go to gcc-bugs@gnu.org.

Regards,
Martin

Re: egcs and bitfields

[David A. Greene]

Martin v. Loewis wrote:
> 
> > I sent this question to the list a few days ago but got
> > no response.  Can someone please help me out?
> 
> I think the problem with your previous report was that it was hard to
> understand. I tried to come up with a program that demonstrates your
> problem, and I got
> 
> struct baz { unsigned int a:2, b:4, c:32;} y;
> 
> void foo()
> {
>   y.c = 0x56789;
> }
> 
> int main()
> {
>   unsigned int  *b;
>   bzero(&y,sizeof(y));
>   foo();
>   b=&y;
>   printf("%x %x\n",b[0],b[1]);
> }
> 
> Is this the case you are talking about? Now, you claim that the SysV
> ABI requires y.c to be at offset 4, right? (this is a claim I can't
> verify since I don't have that specification)
> 
> Anyway, when I run the program on i586-pc-linux-gnu, with
> egcs-2.93.11, I get as output
> 
> 0 56789
> 
> >From your explanation, I understand that this result is
> ABI-compliant. So where is the problem?

Re: egcs and bitfields

[Martin v. Loewis]

> I sent this question to the list a few days ago but got
> no response.  Can someone please help me out?

I think the problem with your previous report was that it was hard to
understand. I tried to come up with a program that demonstrates your
problem, and I got

struct baz { unsigned int a:2, b:4, c:32;} y;

void foo()
{
  y.c = 0x56789;
}

int main()
{
  unsigned int  *b;
  bzero(&y,sizeof(y));
  foo();
  b=&y;
  printf("%x %x\n",b[0],b[1]);
}

Is this the case you are talking about? Now, you claim that the SysV
ABI requires y.c to be at offset 4, right? (this is a claim I can't
verify since I don't have that specification)

Anyway, when I run the program on i586-pc-linux-gnu, with
egcs-2.93.11, I get as output

0 56789

From your explanation, I understand that this result is
ABI-compliant. So where is the problem?

Regards,
Martin

egcs and bitfields

[David A. Greene]

I sent this question to the list a few days ago but got
no response.  Can someone please help me out?

I'm trying to figure out the alignment rules that egcs 
uses for bitfields under Linux 2.0.x.  It seems that egcs 
does not follow the System V ABI stardard.  Specifically, 
the part about not allowing bitfields to cross the 
alignment boundaries of their base types (i.e. int c:17 
should not cross a 32-bit boundary, but egcs allows it).  
Also, bitfields declared "int" are treated as signed by 
egcs while the System V ABI indicates they are unsigned.

What ABI is egcs conforming to?  I need some detailed 
information as we need to interface to code compiled by
egcs.

Thanks!

                                -Dave

Re: egcs and bitfields

[David A. Greene]

Robert Lipe wrote:
> 
> > struct baz { unsigned int a:2, b:4, c:32;} y;
> >
> > void foo()
> > {
> >   y.c = 0x56789;
> > }
> >
> > int main()
> > {
> >   unsigned int  *b;
> >   bzero(&y,sizeof(y));
> >   foo();
> >   b=&y;
> >   printf("%x %x\n",b[0],b[1]);
> > }
> >
> > Is this the case you are talking about? Now, you claim that the SysV
> > ABI requires y.c to be at offset 4, right? (this is a claim I can't
> > verify since I don't have that specification)
> 
> "System V ABI" is too vague for purposes of this discussion.  Do you
> refer to the iBCS2 spec or the SVR4 ABI?  I don't know that they differ
> in this regard, but it isn't an unreasonable question before tearing
> into large books.

Good question.  The book I have here is the "System V ABI Intel386
Processor Supplement" put out by AT&T in 1991 (yes, I know it's old,
but it's all we've got).  It is the SVR4 ABI.  Please correct me 
if there's a more up-to-date version I should be looking at.
 
> I think (but am no authority) that Linux uses substantially the SVR4 ABI
> but it does have some deviations.

Do you know what these deviations are?  The devil is in the details. :)

                                           -Dave

Re: egcs and bitfields

[David A. Greene]

Robert Lipe wrote:
> 
> > struct baz { unsigned int a:2, b:4, c:32;} y;
> >
> > void foo()
> > {
> >   y.c = 0x56789;
> > }
> >
> > int main()
> > {
> >   unsigned int  *b;
> >   bzero(&y,sizeof(y));
> >   foo();
> >   b=&y;
> >   printf("%x %x\n",b[0],b[1]);
> > }
> >
> > Is this the case you are talking about? Now, you claim that the SysV
> > ABI requires y.c to be at offset 4, right? (this is a claim I can't
> > verify since I don't have that specification)
> 
> "System V ABI" is too vague for purposes of this discussion.  Do you
> refer to the iBCS2 spec or the SVR4 ABI?  I don't know that they differ
> in this regard, but it isn't an unreasonable question before tearing
> into large books.

Good question.  The book I have here is the "System V ABI Intel386
Processor Supplement" put out by AT&T in 1991 (yes, I know it's old,
but it's all we've got).  It is the SVR4 ABI.  Please correct me 
if there's a more up-to-date version I should be looking at.
 
> I think (but am no authority) that Linux uses substantially the SVR4 ABI
> but it does have some deviations.

Do you know what these deviations are?  The devil is in the details. :)

                                           -Dave