mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Subject: Re: [musl] Alignment attribute in headers
Date: Wed, 24 Apr 2024 04:54:03 +0200	[thread overview]
Message-ID: <Zih0S2a54IoyEBBi@voyager> (raw)
In-Reply-To: <1Z2XU7Z5OB2AV.26EJYFLGNXL0W@mforney.org>

Am Tue, Apr 23, 2024 at 05:45:31PM -0700 schrieb Michael Forney:
> Rich Felker <dalias@libc.org> 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

  reply	other threads:[~2024-04-24  2:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-21  3:51 Michael Forney
2024-04-21  4:54 ` Markus Wichmann
2024-04-21  7:16   ` Jₑₙₛ Gustedt
2024-04-21  7:38     ` Markus Wichmann
2024-04-21 10:23       ` Jₑₙₛ Gustedt
2024-04-21 10:31         ` Sam James
2024-04-21 17:40         ` Markus Wichmann
2024-04-21 15:50 ` Thorsten Glaser
2024-04-21 16:44   ` Alexander Monakov
2024-04-21 17:20   ` Markus Wichmann
2024-04-21 18:23     ` Thorsten Glaser
2024-04-21 19:04     ` Michael Forney
2024-04-21 23:48 ` Rich Felker
2024-04-24  0:45   ` Michael Forney
2024-04-24  2:54     ` Markus Wichmann [this message]
2024-04-24  7:39     ` Jon Chesterfield
2024-04-24  7:55       ` Jeffrey Walton
2024-04-24  9:49         ` Jon Chesterfield

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zih0S2a54IoyEBBi@voyager \
    --to=nullplan@gmx.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).