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.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED 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 A5BDC2D15A for ; Thu, 10 Oct 2024 23:22:17 +0200 (CEST) Received: (qmail 8111 invoked by uid 550); 10 Oct 2024 21:22:11 -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 x-ms-reactions: disallow Received: (qmail 8076 invoked from network); 10 Oct 2024 21:22:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alexrp.com; s=alexrp; t=1728595323; x=1729200123; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+9rDbq0Rkeh0I9+NfBjWaHHsBp3hkoJAkfrU6YwKGS4=; b=PCp/Owlkks0UGqjJchXaXKFb1/juk7XV0xvo6UVF2uWa6SIZ0aSMauXyyXqVy0i8zY Y4Huc37WDL3w7hNaGpB8NxMvUNOqHgumOw6d3ey7wcMKQ03FhBes3F1v2TVZ0CrgVOm+ R0sHJZVmylHY4B+Aoi3JDpsd+n7gmxZ3d+XjMojp+75UKzzneWf9XwBjhYEZHe5Hjcv5 HLsw+kcBCqaugTFZHQSRBGxdD7YGi0Dy2APvNMT8IfvMmR4oUo0do3EOmCEde/Dinv3w TDu4Ax1RMdYH5/dZq9pmS6sjcEa/jaoWETRq49hq67FIsF0cTYuTdoM6M4O/GWwpPS7C zcpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728595323; x=1729200123; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+9rDbq0Rkeh0I9+NfBjWaHHsBp3hkoJAkfrU6YwKGS4=; b=QsJoRytz07q7QCw83a0r0ldevSjsf1bNCX3eqrpCBCDL7lwSNbfBKiwlQfuBu3Uiyd wRj6DQ4v98659I3qBOx3P+cNiZKYvVgLA0MpxFnyCw4wW0XLXZYuvouX6csTvYmGJFXD 8+4DUzaTt75UNcAr/UP2bI/s2g183E8cTZANhnr2qZv3NTXi4eKsXPlLv6HCLoV0NKAC 1ISxes+bSli65MWRvyBl3YqNkKeFxVlennA4pwCtNjuqlmmVGxx3tk7EORppWZLKyuuE otzkMtGZZhrnWgVziuZQXskrQXkhBWiCw1v/PUGR04oD4VbDBIuqonc1kHFGZftPyQXS rAuA== X-Gm-Message-State: AOJu0YzCRELMv5cqEk87FKcKOuYw8NAlXO7CutykBI22szUNwodGa8QM uqIqpxBA240wYG8+YnaAw0N/n5/++Dk76ozaHVBFToetWj7tvJncq2u+oraf3DyqAcGVqF+HvQz Q2kHvPdAnutmDQBMdYdiVN/cfUaY1pGa/5BFSRxp/dbsHTvmbPCC0XQ== X-Google-Smtp-Source: AGHT+IEOjhZVC5mG2arjGYTvbVefnuqP3nb6RuX+kZompGHNFWBeQI7LwB0ud7yKjHiE5ttjlwwEKElHFnuX7Ke8KKw= X-Received: by 2002:a5d:5442:0:b0:37d:4f69:c9b with SMTP id ffacd0b85a97d-37d551fcb37mr401599f8f.35.1728595323480; Thu, 10 Oct 2024 14:22:03 -0700 (PDT) MIME-Version: 1.0 References: <20241010205046.2087319-1-alex@alexrp.com> <20241010205716.GN10433@brightrain.aerifal.cx> In-Reply-To: <20241010205716.GN10433@brightrain.aerifal.cx> From: =?UTF-8?Q?Alex_R=C3=B8nne_Petersen?= Date: Thu, 10 Oct 2024 23:21:27 +0200 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [PATCH] arm: Fix _init/_fini alignment in crti.o. On Thu, Oct 10, 2024 at 10:57=E2=80=AFPM Rich Felker wrot= e: > > On Thu, Oct 10, 2024 at 10:50:46PM +0200, Alex R=C3=B8nne Petersen wrote: > > This is just cbf59dd6 applied to arm. It manifested when compiling for = thumb2 > > with zig cc (clang) + lld at -O1 or above, but not at -O0. > > --- > > crt/arm/crti.s | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/crt/arm/crti.s b/crt/arm/crti.s > > index 18dc1e41..cccda3ea 100644 > > --- a/crt/arm/crti.s > > +++ b/crt/arm/crti.s > > @@ -3,11 +3,13 @@ > > .section .init > > .global _init > > .type _init,%function > > +.align 2 > > _init: > > push {r0,lr} > > > > .section .fini > > .global _fini > > .type _fini,%function > > +.align 2 > > _fini: > > push {r0,lr} > > -- > > 2.40.1 > > No objection to this fix, but I wonder if after applying it we should > just remove these files entirely. We have NO_LEGACY_INITFINI defined > on arm due to a historical mistake, so these will never be called in > dynamic-linked programs. I guess theoretically they could be used with > static linking, but all functional toolchains will be using init/fini > arrays instead or they would be incompatible with dynamic linking. FWIW, most musl usage with Zig is statically linked, including the conditions under which this issue occurred. That said, we unconditionally use init/fini arrays for Zig code, and it appears that clang, and by extension zig cc, uses them by default as well (you *can* opt out... not sure why you would though). > > Rich