Re: sizeof problem in kernel modules
Alan Shutko <[EMAIL PROTECTED]> said: > One more tidbit: ISO/IEC 9899:1990 3.14 > > 3.14 object: A region of data storage in the execution environment, > the contents of which can represent values. Except for > bit-fields, objects are composed of contiguous sequences of one or > more bytes, the number, order and encoding of which are either > explicitely specified or implementation-defined. > > This would specifically prohibit separating any part of a structure > from the rest. It just prohibits separating bytes, not subobjects. I.e., everything can be handled as an array of bytes (of the appropiate length, as given by sizeof()) -- Dr. Horst H. von BrandUsuario #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sizeof problem in kernel modules
Alan Shutko <[EMAIL PROTECTED]> writes: |> Alan Shutko <[EMAIL PROTECTED]> writes: |> |> > You can look at other things too... you can memcpy structures, pass |> > them into functions, call sizeof, put them in arrays... it _is_ a |> > physical representation. |> |> One more tidbit: ISO/IEC 9899:1990 3.14 |> |> 3.14 object: A region of data storage in the execution environment, |> the contents of which can represent values. Except for |> bit-fields, objects are composed of contiguous sequences of one or |> more bytes, the number, order and encoding of which are either |> explicitely specified or implementation-defined. |> |> This would specifically prohibit separating any part of a structure |> from the rest. But only under the as-if rule, that is, if you never take the address of a structure object the compiler can actually put the parts of it anywhere it likes, because you couldn't notice the difference. Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: sizeof problem in kernel modules
struct { short x; long y; short z; }bad_struct;
struct { long y; short x; short z; }good_struct;
I would expect both structs to be 8byte in size , or atleast the same size !
but good_struct turns out to be 8bytes and bad_struct 12 .
what am I doing wrong here ?
thx !
hofrat
///
It's general padding performed everywhere for a 32-bit m/c. Since the short
number is considered to be of 2 bytes whereas new data should start at the
next 32 bit alignment( if the data length exceeds the padding required )
hence next 2 bytes are left as padding, so the actual struct. of your
defined structutres are as follows,
struct{
short x; /* 2- bytes */
/* again 2- bytes padding */
long y; /* 4 - bytes */
short z; /* 2 - bytes */
/* again 2 - bytes padding
}bad_struct;
struct{
long y; /* 4 - bytes */
short x; /* 2 - bytes */
short z; /* 2 - bytes */
}good_struct;
anil
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sizeof problem in kernel modules
On Sat, Jun 23, 2001 at 10:43:14PM -0400, Richard B. Johnson wrote: > Previous to the "Draft" "Proposal" of C98, there were no such > requirements. And so-called ANSI -C specifically declined to > define any order within structures. As one of the founding members of the X3J11 ANSI committee, and having served on the committee for 10 1/2 years, I can state categorically that Appendix A of the original K&R (which was one of the 3 base documents for ANSI C) had the requirement that non-bitfield fields are required to have monotonically increasing addresses (bitfields don't have addresses, and different compiler ABIs do lay them out in different fashions within the words). C89 never changed the wording that mandates this. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sizeof problem in kernel modules
On Sat, 23 Jun 2001, Richard B. Johnson wrote: > On Sun, 24 Jun 2001, Keith Owens wrote: > > > On Sat, 23 Jun 2001 21:56:06 -0400 (EDT), > > "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: > > >FYI, structures are designed to be accessed only by their member-names. > > >Therefore, the compiler is free to put members at any offset. In fact, > > >members, other than the first, don't even have to be in the order > > >written! > > > > Bzzt! I don't know where people get these ideas from. Extracts from > > the C9X draft. > > > > A structure type describes a sequentially allocated nonempty set of > > member objects (and, in certain circumstances, an incomplete array), > > each of which has an optionally specified name and possibly distinct > > type. > > > > When two pointers are compared ... If the objects pointed to are > > members of the same aggregate object, pointers to structure members > > declared later compare greater than pointers to members declared > > earlier in the structure. > > > > Two objects may be adjacent in memory because they are adjacent > > elements of a larger array or adjacent members of a structure with no > > padding between them, > > > > As discussed in 6.2.5, a structure is a type consisting of a sequence > > of members, whose storage is allocated in an ordered sequence, > > > > Within a structure object, the non-bit-field members and the units > > in which bit-fields reside have addresses that increase in the order > > in which they are declared > > > > C requires that members of a structure be defined in ascending address > > order as specified by the programmer. The compiler may not reorder > > structure fields, although bitfields are a special case. > > > > Previous to the "Draft" "Proposal" of C98, there were no such > requirements. And so-called ANSI -C specifically declined to > define any order within structures. Maybe Ansi didn't but K&R certainly did Frank > > > Cheers, > Dick Johnson > > Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). > > "Memory is like gasoline. You use it up when you are running. Of > course you get it all back when you reboot..."; Actual explanation > obtained from the Micro$oft help desk. > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > HI! I'm a .signature virus! cp me into your .signature file to help me spread! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sizeof problem in kernel modules
On Sun, 24 Jun 2001, Keith Owens wrote: > On Sat, 23 Jun 2001 21:56:06 -0400 (EDT), > "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: > >FYI, structures are designed to be accessed only by their member-names. > >Therefore, the compiler is free to put members at any offset. In fact, > >members, other than the first, don't even have to be in the order > >written! > > Bzzt! I don't know where people get these ideas from. Extracts from > the C9X draft. > > A structure type describes a sequentially allocated nonempty set of > member objects (and, in certain circumstances, an incomplete array), > each of which has an optionally specified name and possibly distinct > type. > > When two pointers are compared ... If the objects pointed to are > members of the same aggregate object, pointers to structure members > declared later compare greater than pointers to members declared > earlier in the structure. > > Two objects may be adjacent in memory because they are adjacent > elements of a larger array or adjacent members of a structure with no > padding between them, > > As discussed in 6.2.5, a structure is a type consisting of a sequence > of members, whose storage is allocated in an ordered sequence, > > Within a structure object, the non-bit-field members and the units > in which bit-fields reside have addresses that increase in the order > in which they are declared > > C requires that members of a structure be defined in ascending address > order as specified by the programmer. The compiler may not reorder > structure fields, although bitfields are a special case. > Previous to the "Draft" "Proposal" of C98, there were no such requirements. And so-called ANSI -C specifically declined to define any order within structures. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sizeof problem in kernel modules
On Sat, 23 Jun 2001, Der Herr Hofrat wrote:
>
> Hi !
>
> can someone explain to me whats happening here ?
>
> --simple.c--
> #include
> #include
>
> struct { short x; long y; short z; }bad_struct;
> struct { long y; short x; short z; }good_struct;
>
[SNIPPED...]
> ---
>
> I would expect both structs to be 8byte in size , or atleast the same size !
> but good_struct turns out to be 8bytes and bad_struct 12 .
>
> what am I doing wrong here ?
You are assuming something that is wrong. Many programmers use
a structure as a "template", assuming that what they write is
exactly what exists in memory. This is not how the 'C' standards
are written! The only thing guaranteed by the standard is that
the first structure member will exist as the same address as the
structure itself -- nothing else.
So that structures can be used as templates, many compilers including
gcc, have non-standard extensions that can be used to "pack" structure
members. __attribute__ ((packed)) will probably do what you want.
FYI, structures are designed to be accessed only by their member-names.
Therefore, the compiler is free to put members at any offset. In fact,
members, other than the first, don't even have to be in the order
written!
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sizeof problem in kernel modules
On Sat, Jun 23, 2001 at 04:54:20PM +0200, Der Herr Hofrat wrote:
> struct { short x; long y; short z; }bad_struct;
> struct { long y; short x; short z; }good_struct;
>
> I would expect both structs to be 8byte in size , or atleast the same size !
> but good_struct turns out to be 8bytes and bad_struct 12 .
>
> what am I doing wrong here ?
You're expecting the compiler to lay them out without any spacing between
them. There is no such requirement in C.
The compiler knows that its more efficient for long words to be accessed
on a long word boundary, so it wastes two bytes after each short in your
bad_struct case. However, it won't waste them in this case, because there
isn't a long:
struct { short x; short y; short z; }
If you really really really want that layout, then use
__attribute__((packed)) (read the gcc info files to find out what this
does), but don't unless you absolutely must.
Here is another struct layout example:
struct foo {
short x;
char y; /* implicit 1 byte padding after this element */
short z;
};
Again, the 1 byte padding can be removed by use of the __attribute__
above.
--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
sizeof problem in kernel modules
Hi !
can someone explain to me whats happening here ?
--simple.c--
#include
#include
struct { short x; long y; short z; }bad_struct;
struct { long y; short x; short z; }good_struct;
int init_module(void){
printk("good_struct %d, bad_struct
%d\n",sizeof(good_struct),sizeof(bad_struct));
return 0;
}
void cleanup_module(void){
}
--Makefile--
all: simple.o
CC= gcc
CFLAGS= -pipe -fno-strength-reduce -DCPU=686 -march=i686 \
-Wall -Wstrict-prototypes -g -D__KERNEL__ -DMODULE \
-D_LOOSE_KERNEL_NAMES -O2 -c
INCLUDE= -I/usr/include/linux
clean:
rm -f simple.o
---
I would expect both structs to be 8byte in size , or atleast the same size !
but good_struct turns out to be 8bytes and bad_struct 12 .
what am I doing wrong here ?
thx !
hofrat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
