[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261028221813.GM23438@brightrain.aerifal.cx>
Date: Wed, 28 Oct 2026 18:18:15 -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
On Wed, Oct 28, 2026 at 11:16:35AM -0700, Colin Cross wrote:
> On Wed, Oct 28, 2026 at 5:37 AM Rich Felker <dalias@...c.org> wrote:
> > 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.
>
> That's not what I see with the latest musl-cross-make:
> $ output/bin/aarch64-linux-musl-cc /tmp/test.c -o /tmp/a.out
> $ output/bin/aarch64-linux-musl-objdump /tmp/a.out -d -j .init -p
> ...
> Dynamic Section:
> NEEDED libc.so
> INIT 0x00000000004003e0
> FINI 0x00000000004005a4
> ...
> Disassembly of section .init:
>
> 00000000004003e0 <_init>:
> 4003e0: a9bf7bfd stp x29, x30, [sp, #-16]!
> 4003e4: 910003fd mov x29, sp
> 4003e8: a8c17bfd ldp x29, x30, [sp], #16
> 4003ec: d65f03c0 ret
>
> The ld man page says:
> -init=name
> When creating an ELF executable or shared object, call NAME
> when the executable or shared
> object is loaded, by setting DT_INIT to the address of
> the function. By default, the
> linker uses "_init" as the function to call.
Oh, so we do have crti/crtn for aarch64 still, just not for 32-bit
arm. I'm not sure why. We should probably make this consistent one way
or the other. Either getting rid of the _init and _fini, or making it
so they're actually run.
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.
