mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Mike Granby <>
To: Rich Felker <>
Cc: "" <>
Subject: RE: [musl] sizeof(pthread_mutex_t) on aarch64
Date: Wed, 23 Aug 2023 13:57:04 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Yeah, that all makes sense. I suspected that would be the case, but I figured I'd memorialize the issue in case someone else came across it. This way, they might at least find it via a search. Just for my interest, I'm going to have a quick look to figure out why glibc ends up with the different size on aarch64: It seems like it is the outlie, although my sample size is not large. Re gcompat, that didn't fix this particular issue and in any case, I really didn't like what it did to cmdline in procfs with its shimming, but I'll certainly keep an eye on its development. Thanks for the prompt response...

-----Original Message-----
From: Rich Felker <> 
Sent: Wednesday, August 23, 2023 9:30 AM
To: Mike Granby <>
Subject: Re: [musl] sizeof(pthread_mutex_t) on aarch64

On Wed, Aug 23, 2023 at 02:09:35AM +0000, Mike Granby wrote:
> I've been running glibc-compiled programs on Alpine and thus on musl 
> with a high level of success, but I just hit the wall when working on 
> a Raspberry PI running aarch64 Alpine. I tracked the issue down to a 
> difference in the size of pthread_mutex_t. It appears that musl uses 6 
> ints for platforms with 32-bit longs, and 10 ints for those with 
> 64-bit longs, and this seems to match glibc on all of the platforms 
> I've played with to date. But on aarch64, it appears that glibc is 
> using 48 bytes rather than 40 bytes that musl expects. This doesn't 
> actually cause an issue in many cases as the application just 
> allocates too much space, but if you're using inlining and 
> std::ofstream, for example, you end up with the inline code in the 
> application having a different layout for the file buffer object 
> compared to that implemented on the target platform. Now, perhaps the 
> answer is just, well, stop expecting to run glibc code on musl, but 
> given that aarch64 seems to be an outlier in my experience to date, I 
> thought I'd mention it.

I guess that's interesting to know, but not something actionable. It's not like we can change and break ABI for the sake of glibc-ABI-compat, nor like we'd want to make every program use even more excess memory space for mutexes than they're already using. At some point the decision was made, based on our existing practice at the time and possibly loosely on glibc doing the same, to have the pthread types be arch-independent and only depend on wordsize, and this determined the ABI for all archs added later, without the types getting evaluated for glibc-ABI-compat since they were no longer arch types.

FWIW I think the program would likely "work" with a glibc version of
libstdc++. However, there are a lot of other places the ABI-compat
breaks down, like mismatching stat structs, ipc structs, etc. The future roadmap is for glibc-ABI-compat handling to be shifted out of libc to the gcompat package, which could do some sort of shims (and which musl ldso would assist it in shimming by letting a delegated library interpose on modules that have dep) and perhaps make something like this work..


  reply	other threads:[~2023-08-23 13:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-23  2:09 Mike Granby
2023-08-23 13:29 ` Rich Felker
2023-08-23 13:57   ` Mike Granby [this message]
2023-08-23 20:04     ` Rich Felker

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:

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

  git send-email \ \ \ \ \

* 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

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).