[musl] __WORDSIZE on x32

[musl] __WORDSIZE on x32

[Florian Weimer]

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

Re: [musl] __WORDSIZE on x32

[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". :-)

> 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

Re: [musl] __WORDSIZE on x32

[Florian Weimer]

* 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

Re: [musl] __WORDSIZE on x32

[Rich Felker]

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