This looks a bid suspicious: arch/x32/bits/reg.h:#undef __WORDSIZE arch/x32/bits/reg.h:#define __WORDSIZE 32 arch/x32/bits/user.h:#undef __WORDSIZE arch/x32/bits/user.h:#define __WORDSIZE 64 I don't know if it causes any actual problems. I discovered it while checking whether musl defines/uses __WORDSIZE. Thanks, Florian
On Tue, Nov 23, 2021 at 08:51:36PM +0100, Florian Weimer wrote: > This looks a bid suspicious: Come on, you missed a chance to say "sus". :-) > arch/x32/bits/reg.h:#undef __WORDSIZE > arch/x32/bits/reg.h:#define __WORDSIZE 32 > arch/x32/bits/user.h:#undef __WORDSIZE > arch/x32/bits/user.h:#define __WORDSIZE 64 > > I don't know if it causes any actual problems. I discovered it while > checking whether musl defines/uses __WORDSIZE. Thanks for the find. Now... which is it supposed to be? commit 664cd341921007cea52c8891f27ce35927dca378 introduced x32 as a patch against a copy of x86_64 and changed one instance from 64 to 32, so presumably the intent was to change both. Is this in agreement with what it means on glibc or elsewhere? Rich
* Rich Felker: > On Tue, Nov 23, 2021 at 08:51:36PM +0100, Florian Weimer wrote: >> This looks a bid suspicious: > > Come on, you missed a chance to say "sus". :-) Sorry? I typo'ed “bit”, but that's not it? >> arch/x32/bits/reg.h:#undef __WORDSIZE >> arch/x32/bits/reg.h:#define __WORDSIZE 32 >> arch/x32/bits/user.h:#undef __WORDSIZE >> arch/x32/bits/user.h:#define __WORDSIZE 64 >> >> I don't know if it causes any actual problems. I discovered it while >> checking whether musl defines/uses __WORDSIZE. > > Thanks for the find. Now... which is it supposed to be? > > commit 664cd341921007cea52c8891f27ce35927dca378 introduced x32 as a > patch against a copy of x86_64 and changed one instance from 64 to 32, > so presumably the intent was to change both. Is this in agreement with > what it means on glibc or elsewhere? glibc uses __WORDSIZE == 64 to differentiate x86-64 from x86-64-32, so it should be 32 for x32. However, arch/x32/bits/user.h looks written as if define __WORDSIZE to 64 changes the width of long to 64. I think struct user_regs_struct needs to have unsigned long long members on x32. (It's what glibc uses for both x86-64 and x86-64-32.) Likewise a most of the members of struct user. Thanks, Florian
OK, following up on this rather late... On Tue, Nov 23, 2021 at 09:22:24PM +0100, Florian Weimer wrote: > * Rich Felker: > > > On Tue, Nov 23, 2021 at 08:51:36PM +0100, Florian Weimer wrote: > >> This looks a bid suspicious: > > > > Come on, you missed a chance to say "sus". :-) > > Sorry? I typo'ed “bit”, but that's not it? In the past year or two, "sus" has entered the vernacular for gaming-related reasons. ;-) > >> arch/x32/bits/reg.h:#undef __WORDSIZE > >> arch/x32/bits/reg.h:#define __WORDSIZE 32 > >> arch/x32/bits/user.h:#undef __WORDSIZE > >> arch/x32/bits/user.h:#define __WORDSIZE 64 > >> > >> I don't know if it causes any actual problems. I discovered it while > >> checking whether musl defines/uses __WORDSIZE. > > > > Thanks for the find. Now... which is it supposed to be? > > > > commit 664cd341921007cea52c8891f27ce35927dca378 introduced x32 as a > > patch against a copy of x86_64 and changed one instance from 64 to 32, > > so presumably the intent was to change both. Is this in agreement with > > what it means on glibc or elsewhere? > > glibc uses __WORDSIZE == 64 to differentiate x86-64 from x86-64-32, so > it should be 32 for x32. Fixing this now. > However, arch/x32/bits/user.h looks written as if define __WORDSIZE to > 64 changes the width of long to 64. I think struct user_regs_struct > needs to have unsigned long long members on x32. (It's what glibc uses > for both x86-64 and x86-64-32.) Likewise a most of the members of > struct user. For user_regs_struct, it's pretty clear they need to be 64-bit. I'm not sure about the long fields in struct user -- these may be 32-bit on ELF32? Let's keep this part open until someone looks into it more. Rich