From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 1D35C21790 for ; Wed, 24 Apr 2024 04:54:18 +0200 (CEST) Received: (qmail 13463 invoked by uid 550); 24 Apr 2024 02:54:13 -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 13428 invoked from network); 24 Apr 2024 02:54:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1713927245; x=1714532045; i=nullplan@gmx.net; bh=9LYNV4o8XBmOlPnGQOI3Tdy9cZtW7aXuP7IMkwjv+OM=; h=X-UI-Sender-Class:Date:From:To:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To:Content-Transfer-Encoding: cc:content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=K5Fl6CMdbleWX8GSutzl9jFGYQiCvW3cvQpU7f7DQ1aHbfWr/dHxE0qpRJhjTkAO 0gPdtYmfqXADLc5kpxyVl3dKLGExzALSUZLbE/uAGdF740Y+deumRFpgpPRuJSSNq NBUiZ0lWI8xtQZyaqIKrZ7VX2vNK6jTG4TwGJOiB/gEFnuNXVcRtDb8xaGVJxl7Nq CkCN3/G2SHw7CULvcsSwnEiyFUrosk8Mnh5mp12GwTuF7vn4ad8Dia+b4CXajIO6b pr4f5B7UIpGuekyGcilTxMk3JY0oAy+/5FzVJCAcyovXzmoTvGc+PpYz3/1ySI3EG KZJcJhbHHz9lrAl65Q== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Wed, 24 Apr 2024 04:54:03 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: References: <3KDMGHI91MHTL.24XCHF6E4X1XG@mforney.org> <20240421234809.GK4163@brightrain.aerifal.cx> <1Z2XU7Z5OB2AV.26EJYFLGNXL0W@mforney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1Z2XU7Z5OB2AV.26EJYFLGNXL0W@mforney.org> X-Provags-ID: V03:K1:EswvVP5aFfQbKUOEtq+ZmzoQyLXyUUWYqHVv29+LeLBUNJXn0Z2 36e1JmqhF/4t/lGbcUewsdNtie8Rmk85Cl1STw0X7WqEpdN3KYlskOi3y/z0QzDIW3EEWqg oyK31D3kyyAug211NqItNx2bAMMZfuUUBwVw+ODOD6T1/lkPOGsl52tt9tLXZKdRVk730dN a673FBWKNuO2O5/ky6xnA== UI-OutboundReport: notjunk:1;M01:P0:ak/mNjXa8XM=;KD7VNkeM5YF6eMqEltWZqaLbFoA i37c74ivqGifF69lAyKwdPVlesXA47b+06RPrbhhzthIt16SxXRzRF8MrzOfkVBoIe8YyMHsz Y5X96M0FcRh+PEZKbXbaqMe5R1jAkyawVa/ckhfI/HRml0+iNUIm04HU0B0dcJi/66OsqFccX 3ClzFL1EvqKCze0J+srURsn4nugvIhxJFviNdTCYmiWiHm5gQ09PBIaLd0T51fjff/nWfa2aI CuCFvMjVfcYi72a3oSL6Hvl/AylWU/iR7t0H+CT4Hg3aiF6zin4TcotX26KhEdr5vuq1jXJJ8 IQdk2RCVrkdm68pGPC+EDFXsHJVO98a7ahZkC0XZloxuoYmYuKjc5zqMirxQdZsSOUpEaI0Ez imVxqsOwFwk46nckuj2zweUwsJ1GYMpvp4QO3jyEreSW8BOFd4j4NioEbGu96+sqJeXDImMx/ 8ZluE3nMVj6m64J7zGGo1M9E994RcM3KTV3jqnzdUadcuPRwsREZ3xox0+GwSti5YwbqKEh5L 3cTJ6sawdJgFQ65q5TuYEpYDLkDMeLTDN3YpDWdqp+Jx8Po+1CCoXBW5LFu/oFMNxkZS+WKA8 VgYESQJM8tWV+DWUHSYbmYt5C3TnlUflcQu/Xi0FtXD/4F9zJ3gm+X9C84H2m1xRp4sa/3n1r qezMWKAj2GD8dWWtfxp0q4SVMGyibwQNqWJ/2pbE2aAUwvl4CyKJ7FzksZjLGWhDcOe7CZzFt pec/8me67V9cFCQqZ9ra/DVw2M5OBWnbKgNO6wcMBljQd74SXsG7TK3veQOhOhaBAwbBblJjd LLpxtiRy1/rFc0Ylu6iR7PqgkQT+iTIN8yGJbox104mBM= Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Alignment attribute in headers Am Tue, Apr 23, 2024 at 05:45:31PM -0700 schrieb Michael Forney: > Rich Felker wrote: > > Most of these I didn't remember, and were likely added begrudgingly. > > There's really no point in having alignment specifiers on the > > sigcontext/mcontext stuff, as it's kernel-allocated. If there are > > places where explicit padding to match the layout is missing, these > > are bugs and should be corrected. I tried to get explicit padding put > > everywhere, asking folks doing new ports to add it (or refrain from > > deleting it), but it's possible some places were missed. Let's fix > > them. > > I checked the other instances, and I think the ones that Markus > identified (riscv32/riscv64 bits/signal.h) are the only ones that > are missing padding. I can prepare a patch if Markus doesn't plan > to. > I don't plan to. > > For all of this, I think it's perfectly acceptable to just use the GNU > > C attribute and condition it on __GNUC__. Once any missing padding is > > fixed, the alignment attribute doesn't really matter. > > If there's really no point to the alignment specifiers for mcontext > sub-structures, should they just be removed completely? > > If there is a point to the alignment specifiers, I think the structs > should be defined in such a way that their alignment doesn't depend > on the compiler you used. > My worry is that someone is using something like libucontext, manipulating ucontexts directly, and allocating them in the static data section or on the stack. In that case, the alignment is important, or else the getcontext()/setcontext() call will fail because the vector register access will fail. A few ABIs have vector registers as preserved registers (PowerPC with Altivec comes to mind). Failure would be fine if it had just never worked, but we already have versions out there that work right now. And updating your libc only to find new unexplained crashes is not really a good way to spend a work day. > My worry is that some application might use these structs as fields > inside their own structs, and save data from a signal handler in > them. Without the alignment specifier, they could potentially have > incorrect offsets, breaking ABI compatibility between GNU C and > non-GNU C compilers. > That is also a good point. Ciao, Markus