httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: [PATCH] fix alignment on shared memory
Date Fri, 01 Mar 2002 18:29:27 GMT
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

Mime
View raw message