From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29154 invoked from network); 23 Nov 2021 20:22:44 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 23 Nov 2021 20:22:44 -0000 Received: (qmail 19484 invoked by uid 550); 23 Nov 2021 20:22:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 18431 invoked from network); 23 Nov 2021 20:22:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637698950; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ENR0MVIJJ4LdOYABDQmHqqmsCIXtn+OmbhSmcOAKHK8=; b=Hj5mbYPjFGML0NfE7VJLuCMWti7AXfO+MDfxi7d9gUaYv/1UJ+6eodSLx2lvqj5BPvWQEi a+OqMuHPRIWJhKe6589ntpS94YUMM/oJD+Jrokwv21Jpf5IT/QK0Gq/8LomBBdUwNSWuow i+requAdAJSqSrjho1so3nmruIsH3bY= X-MC-Unique: YObRsDlVN0uDShPFAlGZpA-1 From: Florian Weimer To: Rich Felker Cc: musl@lists.openwall.com References: <875ysips53.fsf@oldenburg.str.redhat.com> <20211123201438.GA7074@brightrain.aerifal.cx> Date: Tue, 23 Nov 2021 21:22:24 +0100 In-Reply-To: <20211123201438.GA7074@brightrain.aerifal.cx> (Rich Felker's message of "Tue, 23 Nov 2021 15:14:38 -0500") Message-ID: <87y25eoc5b.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=fweimer@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: 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". :-) Sorry? I typo'ed =E2=80=9Cbit=E2=80=9D, 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 >>=20 >> 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 =3D=3D 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