On Fri, Mar 01, 2002 at 12:34:49PM -0500, Jeff Trawick wrote:
> I'll punt for the moment on whether or not that code is bad. The
> shared memory code definitely needs to be fixed. Look at this simple
> test of alignment:
>
> #include <stddef.h>
> #include <stdio.h>
>
> int main(void)
> {
> struct s1 {
> char a;
> char b;
> } s1;
> struct s2 {
> char a;
> int b;
> } s2;
> struct s3 {
> char a;
> long long b;
> } *s3;
> struct s4 {
> char a;
> double b;
> } s4;
>
> printf("%d %d %d %d\n",
> offsetof(struct s1,b),
> offsetof(struct s2,b),
> offsetof(struct s3,b),
> offsetof(struct s4,b));
>
> s3 = (struct s3 *)((char *)malloc(100) + 4);
Of course it gives us a SIGBUS here, this is guaranteed on a sparc.
I'm not entirely sure what you're trying to illustrate here though.
> printf("%p\n",s3);
> s3->a = 'A';
> s3->b = 10241024;
Shouldn't this be: s3->b = 10241024LL; ?
(Probably not important.)
> return 0;
> }
>
> On my sparc machine it prints
> 1 4 8 8
> for the offsets of the variables of different types. Note that gcc
> places long long and double on 64-bit boundaries.
>
> It then dies with SIGBUS when I trick it into trying to store a
> 64-bit quantity into storage which s 32-bit aligned but not 64-bit
> aligned.
As expected.
> Back to the code above that you posted:
>
> I think that it too needs to take into account alignment. It would
> need to round the size of each structure up to 64-bit alignmet before
> multiplying to ensure that objects of any type can live in that
> storage. This currently isn't causing problems because the size of
> each structure is consistent with 64-bit alignment (208 bytes for
> worker_score, 24 bytes for global_score, 16 bytes for process_score),
> at least in a 32-bit build for Sparc.
Yes, I completely agree that each structure needs to be 64-bit aligned.
I don't see how the shared memory code itself is incorrect. It must be
mapping the segment at a properly aligned boundary, so as long as the
contents of that segment are accessed in an aligned manner than we're
safe, right?
-aaron
