|
Message-ID: <CAJnvVWVG8EtGgKHGc3biF+9kLJdMQ1ce+MAZs22CWdBOY-L+0A@mail.gmail.com> Date: Fri, 12 Apr 2013 14:23:18 +0300 From: Ivan Kanakarakis <ivan.kanak@...il.com> To: musl@...ts.openwall.com Subject: Re: Fix for fields in utmp I update musl-git and rerun nsz's test, here are the current results in case you see something to be fixed before the release.. --- data/glibc.sizeof 2013-04-12 14:01:35.768425683 +0300 +++ data/musl.sizeof 2013-04-12 14:01:35.771759052 +0300 @@ -112,4 +112,4 @@ int8_t 1 -int_fast16_t 8 -int_fast32_t 8 +int_fast16_t 4 +int_fast32_t 4 int_fast64_t 8 @@ -122,3 +122,3 @@ intptr_t 8 -jmp_buf 200 +jmp_buf 64 key_t 4 @@ -183,4 +183,4 @@ register_t 8 -regmatch_t 8 -regoff_t 4 +regmatch_t 16 +regoff_t 8 res_state 8 @@ -222,3 +222,3 @@ struct cmsghdr 16 -struct crypt_data 131232 +struct crypt_data 260 struct dirent 280 @@ -282,3 +282,3 @@ struct itimerval 32 -struct lastlog 292 +struct lastlog 296 struct lconv 96 @@ -312,3 +312,3 @@ struct ns_tsig_key 2072 -struct ntptimeval 72 +struct ntptimeval 32 struct option 32 @@ -326,4 +326,4 @@ struct rtentry 120 -struct rusage 144 -struct sched_param 4 +struct rusage 272 +struct sched_param 48 struct sembuf 6 @@ -361,3 +361,3 @@ struct strrecvfd 20 -struct sysinfo 112 +struct sysinfo 368 struct termios 60 @@ -376,3 +376,3 @@ struct utimbuf 16 -struct utmpx 384 +struct utmpx 400 struct utsname 390 @@ -399,4 +399,4 @@ uint8_t 1 -uint_fast16_t 8 -uint_fast32_t 8 +uint_fast16_t 4 +uint_fast32_t 4 uint_fast64_t 8 also attached the diff On 5 March 2013 00:06, Rich Felker <dalias@...ifal.cx> wrote: > On Sun, Mar 03, 2013 at 12:29:57AM +0100, Szabolcs Nagy wrote: > > > > > -int_fast16_t 8 > > > > > -int_fast32_t 8 > > > > > +int_fast16_t 4 > > > > > +int_fast32_t 4 > > > > > > > > these diffs may cause problems > > > > > > These are actually omitted from the ABI documents if I remember > > > > ok then keep it as is > > This still should be checked. It _could_ be changed if it matters.. > > > > > > -regex_t 64 > > > > > +regex_t 56 > > > > > > I think this should be fixed to match. > > > > glibc's definition is something like: > > > > typedef struct { > > char *__x1; > > long __x2; > > long __x3; > > long __x4; > > char *__x5; > > char *__x6; > > size_t re_nsub; > > char __x7; > > } regex_t; > > > > musl's definition (only re_nsub and __opaque are used): > > > > typedef struct { > > size_t re_nsub; > > void *__opaque, *__padding[4]; > > size_t __nsub2; > > } regex_t; > > Fixed, even though it doesn't matter with the other ABI > incompatibility issues. > > > > > > -regmatch_t 8 > > > > > -regoff_t 4 > > > > > +regmatch_t 16 > > > > > +regoff_t 8 > > > > > > These are a bug in glibc; their types do not conform to the > > > requirements imposed on regex.h and regexec(). > > > > so regex abi wont be compatible > > Yes, this will need some special dynamic linker glue if we want to be > able to run glibc libs/bins using regex. But it's likely they might > not work anyway without glibc extensions... > > > > > > -siginfo_t 128 > > > > > +siginfo_t 136 > > > > > > This is probably a mistake, maybe in the padding..? > > > > yes, the si_fields union is 8byte aligned > > Fixed. > > > > > > -struct arpd_request 40 > > > > > +struct arpd_request 28 > > > > > > No idea. > > > > i think this is not used anymore > > Fixed anyway. > > > > > > -struct lastlog 292 > > > > > +struct lastlog 296 > > > > > > Probably needs to be checked. > > > > glibc's definition: > > (using the same hack for time_t as in utmpx) > > This can probably be ignored. The files will be incompatible, but it's > intended that they not be used anyway.. > > > > > > -struct ntptimeval 72 > > > > > +struct ntptimeval 32 > > > > > > Should we change this? Probably. > > > > musl does not have ntp_gettime so it probably > > should not define this struct > > You're probably right, but I'm holding off a bit on removing it in > case others have input.. > > > > > > -struct rusage 144 > > > > > -struct sched_param 4 > > > > > +struct rusage 272 > > > > > +struct sched_param 48 > > > > > > Not sure about rusage. For sched_param, we support the extra fields > > > for the sporadic server option even though we don't support it (and > > > Linux probably never will). > > > > musl's rusage (the difference is the __reserved part): > > Should we change it or keep the extra reserved space? > > > > > > -struct sockaddr_storage 128 > > > > > +struct sockaddr_storage 136 > > > > > > Probably wrong. > > > > wrong padding > > Fixed. > > > > > > -wctrans_t 8 > > > > > -wctype_t 8 > > > > > +wctrans_t 4 > > > > > +wctype_t 4 > > > > > > > > it seems wctype_t is unconditionally long in glibc > > > > > > As it should be. This is a bug in musl. Being an opaque type that > > > could (and often should) be implemented as a pointer, wctype_t should > > > always be pointer-sized. > > > > then this should be fixed > > I will fix this, but as a separate commit since it actually has > nontrivial effects. > > Rich > -- *Ivan c00kiemon5ter Kanakarakis* >:3 Content of type "text/html" skipped Download attachment "sizeof.diff" of type "application/octet-stream" (1154 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.