Okay, after all my hand conversion, I am left with a nice struct definition. The only thing is, when I print out the "sizeof(struct peer)" in the c program, I get 720. But when I print "sizeof(struct peer)" in the BEGIN clause of the d script, I get 716. I cannot verify all of the fields at runtime, but I was able to print fields very near the end and verify their numbers, and the only remaining fields are 5 uint32_ts. How can I get different values of sizeof, but have the field offset correct? Okay, I a little address arithmetic, and the address of the last field minus the address of the first field plus the length of the last field is equal for D, 32 bit and 64 bit, and this value is the value that D is printing for the sizeof. So, why is the sizeof for the C programs 4 bytes larger? It must be padding at the end, but why? Someone suggested that the struct would be aligned to the type of the first field, but that is a uint32_t, so I would expect 0-3 bytes of padding, but I am getting 4. What gives? -- blu Remember when SOX compliant meant they were both the same color? ---------------------------------------------------------------------- Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
On Wed, Aug 17, 2005 at 02:27:43PM -0400, Brian Utterback wrote:> Okay, after all my hand conversion, I am left with a nice > struct definition. The only thing is, when I print out the > "sizeof(struct peer)" in the c program, I get 720. But when > I print "sizeof(struct peer)" in the BEGIN clause of the > d script, I get 716. I cannot verify all of the fields at > runtime, but I was able to print fields very near the end > and verify their numbers, and the only remaining fields > are 5 uint32_ts. How can I get different values of sizeof, > but have the field offset correct? > > Okay, I a little address arithmetic, and the address of > the last field minus the address of the first field plus > the length of the last field is equal for D, 32 bit and > 64 bit, and this value is the value that D is printing > for the sizeof. So, why is the sizeof for the C programs > 4 bytes larger? It must be padding at the end, but why? > Someone suggested that the struct would be aligned to the > type of the first field, but that is a uint32_t, so I > would expect 0-3 bytes of padding, but I am getting 4. > > What gives?If your structure contains any uint64_ts, the whole structure must have 8-byte alignment. D is getting this wrong: % dtrace -n ''struct foo {uint32_t a, b; uint64_t c; uint32_t d;}; BEGIN {printf("%d", sizeof (struct foo)); exit(0)}'' dtrace: description ''struct foo '' matched 1 probe CPU ID FUNCTION:NAME 0 1 :BEGIN 20 % cat foo.c #include <sys/types.h> #include <stdio.h> struct foo { uint32_t a, b; uint64_t c; uint32_t d; }; int main(int argc, char *argv[]) { printf("%d\n", sizeof (struct foo)); return (0); } % cc -o foo foo.c % ./foo 24 % Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development
On Wed, Aug 17, 2005 at 11:36:46AM -0700, Jonathan Adams wrote:> If your structure contains any uint64_ts, the whole structure must > have 8-byte alignment. D is getting this wrong: >I''ve filed 6312373 D struct alignment padding can be incorrect to cover this. - jonathan -- Jonathan Adams, Solaris Kernel Development
Jonathan Adams wrote:> On Wed, Aug 17, 2005 at 02:27:43PM -0400, Brian Utterback wrote: > >>Okay, after all my hand conversion, I am left with a nice >>struct definition. The only thing is, when I print out the >>"sizeof(struct peer)" in the c program, I get 720. But when >>I print "sizeof(struct peer)" in the BEGIN clause of the >>d script, I get 716. I cannot verify all of the fields at >>runtime, but I was able to print fields very near the end >>and verify their numbers, and the only remaining fields >>are 5 uint32_ts. How can I get different values of sizeof, >>but have the field offset correct? >> >>Okay, I a little address arithmetic, and the address of >>the last field minus the address of the first field plus >>the length of the last field is equal for D, 32 bit and >>64 bit, and this value is the value that D is printing >>for the sizeof. So, why is the sizeof for the C programs >>4 bytes larger? It must be padding at the end, but why? >>Someone suggested that the struct would be aligned to the >>type of the first field, but that is a uint32_t, so I >>would expect 0-3 bytes of padding, but I am getting 4. >> >>What gives? > > > If your structure contains any uint64_ts, the whole structure must > have 8-byte alignment. D is getting this wrong: > > % dtrace -n ''struct foo {uint32_t a, b; uint64_t c; uint32_t d;}; BEGIN {printf("%d", sizeof (struct foo)); exit(0)}'' > dtrace: description ''struct foo '' matched 1 probe > CPU ID FUNCTION:NAME > 0 1 :BEGIN 20 > % cat foo.c > #include <sys/types.h> > #include <stdio.h> > > struct foo { > uint32_t a, b; > uint64_t c; > uint32_t d; > }; > > int > main(int argc, char *argv[]) > { > printf("%d\n", sizeof (struct foo)); > return (0); > } > % cc -o foo foo.c > % ./foo > 24 > % > > Cheers, > - jonathan >Ah. It has a few doubles in it. -- blu Remember when SOX compliant meant they were both the same color? ---------------------------------------------------------------------- Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
> On Wed, Aug 17, 2005 at 11:36:46AM -0700, Jonathan Adams wrote: > > If your structure contains any uint64_ts, the whole structure must > > have 8-byte alignment. D is getting this wrong: > > > I''ve filed > 6312373 D struct alignment padding can be incorrect > to cover this. > > - jonathanMy apologies for this. Bryan ran into this over the weekend, too. Following the usual DTrace model, the bug exists for a long time, and then coincidentally everyone hits it simultaneously. In any case, I will have a fix forthcoming. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/