[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMbhsRSKezGzo352W4MHu1=p888FbgcaJofcPM1+5aLACThzdg@mail.gmail.com>
Date: Wed, 28 Oct 2026 17:02:17 -0700
From: Colin Cross <ccross@...roid.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] Remove NO_LEGACY_INITFINI
On Wed, Oct 28, 2026 at 3:18 PM Rich Felker <dalias@...c.org> wrote:
>
> 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.
The symbols exist for 32-bit arm too:
$ output/bin/arm-linux-musleabihf-cc /tmp/test.c -o /tmp/a.out
$ output/bin/arm-linux-musleabihf-objdump /tmp/a.out -d -j .init -p
...
INIT 0x00010278
FINI 0x00010424
...
Disassembly of section .init:
00010278 <_init>:
10278: e92d4001 push {r0, lr}
1027c: e8bd4001 pop {r0, lr}
10280: e12fff1e bx lr
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.
