[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261028123652.GD20479@brightrain.aerifal.cx>
Date: Wed, 28 Oct 2026 08:36:53 -0400
From: Rich Felker <dalias@...c.org>
To: Colin Cross <ccross@...roid.com>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] Remove NO_LEGACY_INITFINI
Please keep the list cc'd.
On Tue, Oct 27, 2026 at 08:20:49PM -0700, Colin Cross wrote:
> On Tue, Oct 27, 2026 at 1:07 PM Rich Felker <dalias@...c.org> wrote:
> > On Tue, Oct 27, 2026 at 11:12:10AM -0700, Colin Cross wrote:
> > > NO_LEGACY_INITFINI was added in 1da53dad ("disable legacy init/fini
> > > processing on ARM") because crt/arm/crti.s was running the init/fini
> > > arrays from _init/_fini, which caused the init/fini arrays to be run
> > > twice after e69ae844 ("add support for init_array/fini_array
> > > ctors/dtors to dynamic linker").
> > >
> > > NO_LEGACY_INITFINII is no longer necessary after 976c0fdc ("remove
> > > init/fini array asm from arm crti/crtn files"). Keeping it enabled on
> >
> > This is not the case. crti/crtn are *linked into binaries* not part of
> > libc.so. With your patch applied, any binary predating
> > NO_LEGACY_INITFINI would now be subject to double-init.
>
> I see.
>
> The aarch64 architecture never had init/fini array processing in
> _init/_fini, but still sets NO_LEGACY_INITFINI. Removing
> NO_LEGACY_INITFINI from aarch64 would fix my specific issue.
I don't understand what the original problem you're trying to solve
is, and we're not going to make a change that's not well-motivated.
This is *probably* the tooling you were talking about doing something
very wrong, but I can't tell from the limited description:
"This conflicts with tools that rewrite the DT_INIT entry if it
exists. The problem was seen with LLVM BOLT, which in some cases
inserts its initializers in DT_INIT."
In arm or aarch64 binaries, except for very old ones produced before
we had init_array support, DT_INIT should not be present. So if there
is tooling that only rewrites them if they exist, I don't see how it
would be having any problem now. The only problem would be if it's
*adding* a DT_INIT when it doesn't already exist and expecting that to
be run. And if that's the case, it should just be fixed to not do
that. I don't think we want to be adding a contract to run legacy
DT_INIT code where we previously haven't just to support some
particular tooling, when the tooling could just be fixed to not do
that.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
