[musl] DT_PREINIT_ARRAY support

[musl] DT_PREINIT_ARRAY support

[Fangrui Song]

There is a DT_PREINIT_ARRAY patch that falls through the cracks:
 https://www.openwall.com/lists/musl/2016/05/17/2
I wonder whether it can be visited again.

I ported sanitizers to upstream compiler-rt. I have not had time to
track the latest status for musl, but I know that quite a few
sanitizers will benefit from musl supporting the feature and see
another recent issue about tsan
(https://github.com/llvm/llvm-project/issues/78452).

---

Some notes about DT_PREINIT_ARRAY

The linker defines DT_PREINIT_ARRAY and DT_PREINIT_ARRAYSZ according
to the address and size of .preinit_array. The linker also defines
__preinit_array_start and __preinit_array_end if referenced.

The generic ABI says:

> DT_PREINIT_ARRAY: This element holds the address of the array of pointers to pre-initialization functions, discussed in ``Initialization and Termination Functions'' below. The DT_PREINIT_ARRAY table is processed only in an executable file; it is ignored if contained in a shared object.

DT_PREINIT_ARRAY only applies to the executable. This feature gives
the executable a way to run initialization functions before shared
object dependencies.

There is no .postfini_array.

Most ld.so implementations support DT_PREINIT_ARRAY.

Re: [musl] DT_PREINIT_ARRAY support

[Rich Felker]

On Sun, Jan 21, 2024 at 03:33:05PM -0800, Fangrui Song wrote:
> There is a DT_PREINIT_ARRAY patch that falls through the cracks:
>  https://www.openwall.com/lists/musl/2016/05/17/2
> I wonder whether it can be visited again.

I looked it over, and I think the latest version dropped the dummy
definitions of __preinit_array_start/_end in dynlink.c. Accordig to
the text in commit 19caa25d0a8e587bb89b79c3f629085548709dd4, I think
they need to be added back. Otherwise it looks reasonable. So maybe
with that change it can be merged?

Rich

Re: [musl] DT_PREINIT_ARRAY support

[Fangrui Song]

On Sun, Feb 25, 2024 at 5:25 PM Rich Felker <dalias@libc.org> wrote:
>
> On Sun, Jan 21, 2024 at 03:33:05PM -0800, Fangrui Song wrote:
> > There is a DT_PREINIT_ARRAY patch that falls through the cracks:
> >  https://www.openwall.com/lists/musl/2016/05/17/2
> > I wonder whether it can be visited again.
>
> I looked it over, and I think the latest version dropped the dummy
> definitions of __preinit_array_start/_end in dynlink.c. Accordig to
> the text in commit 19caa25d0a8e587bb89b79c3f629085548709dd4, I think
> they need to be added back. Otherwise it looks reasonable. So maybe
> with that change it can be merged?
>
> Rich

Commit 19caa25d0a8e587bb89b79c3f629085548709dd4 (2015) says that it
works around an old (by the standards of 2015) GNU ld bug.
Do we know what the bug is and how old it is? 2010?

For practical purposes (compiler-rt uses), it seems the ancient bug
would be very unlikely to matter, as those ancient binutils would
unlikely be able to link the programs that need __preinit_array
feature anyway. (Modern LLVM requires a GCC that is released after
circa 2018. It's unclear that the GCC versions can work with a
multi-year older binutils.)

Re: [musl] DT_PREINIT_ARRAY support

[Rich Felker]

On Mon, Feb 26, 2024 at 02:31:13PM -0800, Fangrui Song wrote:
> On Sun, Feb 25, 2024 at 5:25 PM Rich Felker <dalias@libc.org> wrote:
> >
> > On Sun, Jan 21, 2024 at 03:33:05PM -0800, Fangrui Song wrote:
> > > There is a DT_PREINIT_ARRAY patch that falls through the cracks:
> > >  https://www.openwall.com/lists/musl/2016/05/17/2
> > > I wonder whether it can be visited again.
> >
> > I looked it over, and I think the latest version dropped the dummy
> > definitions of __preinit_array_start/_end in dynlink.c. Accordig to
> > the text in commit 19caa25d0a8e587bb89b79c3f629085548709dd4, I think
> > they need to be added back. Otherwise it looks reasonable. So maybe
> > with that change it can be merged?
> >
> > Rich
> 
> Commit 19caa25d0a8e587bb89b79c3f629085548709dd4 (2015) says that it
> works around an old (by the standards of 2015) GNU ld bug.
> Do we know what the bug is and how old it is? 2010?
> 
> For practical purposes (compiler-rt uses), it seems the ancient bug
> would be very unlikely to matter, as those ancient binutils would
> unlikely be able to link the programs that need __preinit_array
> feature anyway. (Modern LLVM requires a GCC that is released after
> circa 2018. It's unclear that the GCC versions can work with a
> multi-year older binutils.)

This is not about breaking linking of programs that need
__preinit_array. It breaks linking of libc.so itself.

Rich