From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id 5A3883858D39 for ; Mon, 27 Mar 2023 12:43:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5A3883858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=deneb.enyo.de Received: from [172.17.203.2] (port=55199 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) id 1pgmBc-00FSes-0L; Mon, 27 Mar 2023 12:42:56 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.96) (envelope-from ) id 1pgmBb-0029Ac-2w; Mon, 27 Mar 2023 14:42:55 +0200 From: Florian Weimer To: John David Anglin Cc: Sam James , John David Anglin , deller@gmx.de, libc-alpha@sourceware.org Subject: Re: [committed] hppa: Drop 16-byte pthread lock alignment References: <87sfdrvxry.fsf@mid.deneb.enyo.de> <87zg7zc9km.fsf@gentoo.org> <20cc14ed-d49d-d655-b866-f8f9bb49e0eb@bell.net> Date: Mon, 27 Mar 2023 14:42:55 +0200 In-Reply-To: <20cc14ed-d49d-d655-b866-f8f9bb49e0eb@bell.net> (John David Anglin's message of "Sun, 26 Mar 2023 21:58:19 -0400") Message-ID: <87ilemwek0.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * John David Anglin: > On 2023-03-26 8:37 p.m., Sam James wrote: >> Florian Weimer writes: >> >>> * John David Anglin: >>> >>>> hppa: Drop 16-byte pthread lock alignment >>>> >>>> Linux threads were removed about 12 years ago and the current >>>> nptl implementation only requires 4-byte alignment for pthread >>>> locks. >>>> >>>> The 16-byte alignment causes various issues. For example in >>>> building ignition-msgs, we have: >>>> >>>> /usr/include/google/protobuf/map.h:124:37: error: static assertion fai= led >>>> 124 | static_assert(alignof(value_type) <=3D 8, ""); >>>> | ~~~~~~~~~~~~~~~~~~~~^~~~ >>>> >>>> This is caused by the 16-byte pthread lock alignment. >>> This was done deliberately to preserve ABI. This change needs a mass >>> rebuild because struct offsets after pthread_mutex_t members are >>> likely to change. > Although the change may change some structure offsets, I don't > believe the change requires a mass rebuild. I am running a Debian > hppa system with the reduced lock alignment and so far I haven't > observed any breakage. I checked this prior to committing the > change. With nothing rebuilt, no struct offsets change, so this isn't unexpected. Maybe it's still the easiest way to fix the underlying issue, but it's likely not going to stop at just changing the glibc headers. > Here is comment in map.h: > =A0 // MapAllocator does not support alignments beyond 8. Technically we= should > =A0 // support up to std::max_align_t, but this fails with ubsan and tcm= alloc > =A0 // debug allocation logic which assume 8 as default alignment. > =A0 static_assert(alignof(value_type) <=3D 8, ""); > > It was the above comment that convinced me that we needed to change > the pthread lock alignment. It seems that current tcmalloc honors GCC's __STDCPP_DEFAULT_NEW_ALIGNMENT__: On panama.debian.net, it seems correct: $ gcc -x c++ -E - < /dev/null -dM | grep __STDCPP_DEFAULT_NEW_ALIGNMENT__ #define __STDCPP_DEFAULT_NEW_ALIGNMENT__ 16 Is it a matter of an outdated bundled tcmalloc copy? Or is the assert merely incorrect and should use __STDCPP_DEFAULT_NEW_ALIGNMENT__ as well?