[musl] dynlink.c tests

[musl] dynlink.c tests

[Farid Zakaria]

What's the best way to test dynlink.c ?
I'm making some small changes (actually just simplifying it by
removing some code for unneeded arch like DL_FDPIC) but would like to
make sure I didn't bork anything.

I found https://wiki.musl-libc.org/writing-tests but that seems
focused strictly on the libc itself.
Is there a dynamic-loader test suite anyone is familiar with ?

Re: [musl] dynlink.c tests

[Rich Felker]

On Fri, Oct 20, 2023 at 11:18:44AM -0700, Farid Zakaria wrote:
> What's the best way to test dynlink.c ?
> I'm making some small changes (actually just simplifying it by
> removing some code for unneeded arch like DL_FDPIC) but would like to
> make sure I didn't bork anything.
> 
> I found https://wiki.musl-libc.org/writing-tests but that seems
> focused strictly on the libc itself.
> Is there a dynamic-loader test suite anyone is familiar with ?

The general strategy I would use would be to setup recipes to build
binaries/shared libraries that make use of particular dynamic linking
features, then load/execute them in ways that assert that the relevant
feature operated as expected.

Rich

Re: [musl] dynlink.c tests

[Farid Zakaria]

Sorry for the late reply Rich.

That's what my current plan of attack is but I was wondering if the
musl codebase itself has such a test suite already
(something similar to the libc test suite)

How do dynlink authors validate they haven't broken any edge cases in
program loading?
(i.e. such as DT_GNU_HASH etc..)

On Fri, Oct 20, 2023 at 5:00 PM Rich Felker <dalias@libc.org> wrote:
>
> On Fri, Oct 20, 2023 at 11:18:44AM -0700, Farid Zakaria wrote:
> > What's the best way to test dynlink.c ?
> > I'm making some small changes (actually just simplifying it by
> > removing some code for unneeded arch like DL_FDPIC) but would like to
> > make sure I didn't bork anything.
> >
> > I found https://wiki.musl-libc.org/writing-tests but that seems
> > focused strictly on the libc itself.
> > Is there a dynamic-loader test suite anyone is familiar with ?
>
> The general strategy I would use would be to setup recipes to build
> binaries/shared libraries that make use of particular dynamic linking
> features, then load/execute them in ways that assert that the relevant
> feature operated as expected.
>
> Rich

Re: [musl] dynlink.c tests

[Rich Felker]

On Mon, Oct 23, 2023 at 10:08:41AM -0700, Farid Zakaria wrote:
> Sorry for the late reply Rich.
> 
> That's what my current plan of attack is but I was wondering if the
> musl codebase itself has such a test suite already
> (something similar to the libc test suite)
> 
> How do dynlink authors validate they haven't broken any edge cases in
> program loading?
> (i.e. such as DT_GNU_HASH etc..)

Generally this code has almost zero churn, and is expected to be that
way. Your example of gnu hash for example is a pure mathematical
function that never has any reason to be changed.

On top of that, none of this is code that dynamically succeeds or
fails based on any complex runtime condition. For the most part,
either it does the right thing or it doesn't, and if it doesn't,
nothing would load.

This doesn't mean testability is unwanted, just that this code is
rather low priority for testing compared to things with a lot more
dynamic corner cases.

Rich


> On Fri, Oct 20, 2023 at 5:00 PM Rich Felker <dalias@libc.org> wrote:
> >
> > On Fri, Oct 20, 2023 at 11:18:44AM -0700, Farid Zakaria wrote:
> > > What's the best way to test dynlink.c ?
> > > I'm making some small changes (actually just simplifying it by
> > > removing some code for unneeded arch like DL_FDPIC) but would like to
> > > make sure I didn't bork anything.
> > >
> > > I found https://wiki.musl-libc.org/writing-tests but that seems
> > > focused strictly on the libc itself.
> > > Is there a dynamic-loader test suite anyone is familiar with ?
> >
> > The general strategy I would use would be to setup recipes to build
> > binaries/shared libraries that make use of particular dynamic linking
> > features, then load/execute them in ways that assert that the relevant
> > feature operated as expected.
> >
> > Rich

Re: [musl] dynlink.c tests

[Farid Zakaria]

Just to be pedantic, few ideas come to mind:
- One could change the symbol count method to only use DT_HASH and it
would succeed until GCC removed it ;)
- The order of resolution for dependencies
- $ORIGIN replacement

I am very appreciative of the codebase.
I'm going through it at the moment "stripping it down" a bit to be for
x86-64 and adding some comments to help me better understand the
process.
I was going to look at whether I can take on a C++ standard as a
dependency as well.

If you are interested in my fork + what I'm hoping to accomplish,
please reach out.

Thank you Rich.

On Mon, Oct 23, 2023 at 10:57 AM Rich Felker <dalias@libc.org> wrote:
>
> On Mon, Oct 23, 2023 at 10:08:41AM -0700, Farid Zakaria wrote:
> > Sorry for the late reply Rich.
> >
> > That's what my current plan of attack is but I was wondering if the
> > musl codebase itself has such a test suite already
> > (something similar to the libc test suite)
> >
> > How do dynlink authors validate they haven't broken any edge cases in
> > program loading?
> > (i.e. such as DT_GNU_HASH etc..)
>
> Generally this code has almost zero churn, and is expected to be that
> way. Your example of gnu hash for example is a pure mathematical
> function that never has any reason to be changed.
>
> On top of that, none of this is code that dynamically succeeds or
> fails based on any complex runtime condition. For the most part,
> either it does the right thing or it doesn't, and if it doesn't,
> nothing would load.
>
> This doesn't mean testability is unwanted, just that this code is
> rather low priority for testing compared to things with a lot more
> dynamic corner cases.
>
> Rich
>
>
> > On Fri, Oct 20, 2023 at 5:00 PM Rich Felker <dalias@libc.org> wrote:
> > >
> > > On Fri, Oct 20, 2023 at 11:18:44AM -0700, Farid Zakaria wrote:
> > > > What's the best way to test dynlink.c ?
> > > > I'm making some small changes (actually just simplifying it by
> > > > removing some code for unneeded arch like DL_FDPIC) but would like to
> > > > make sure I didn't bork anything.
> > > >
> > > > I found https://wiki.musl-libc.org/writing-tests but that seems
> > > > focused strictly on the libc itself.
> > > > Is there a dynamic-loader test suite anyone is familiar with ?
> > >
> > > The general strategy I would use would be to setup recipes to build
> > > binaries/shared libraries that make use of particular dynamic linking
> > > features, then load/execute them in ways that assert that the relevant
> > > feature operated as expected.
> > >
> > > Rich

Re: [musl] dynlink.c tests

[Rich Felker]

On Mon, Oct 23, 2023 at 11:08:31AM -0700, Farid Zakaria wrote:
> Just to be pedantic, few ideas come to mind:
> - One could change the symbol count method to only use DT_HASH and it
> would succeed until GCC removed it ;)

There are already distros building with GNU-hash-only, so one of them
would catch such breakage.

> - The order of resolution for dependencies

This has changed before from whatever-it-was to something very
intentional, and basic testing of the intended order was done at the
time, but we don't have regularly run tests for it. While future
changes here would come with manual testing like that again, it would
be nice to have an automated framework for this.

> - $ORIGIN replacement

This is probably under-tested but I'm not aware of any reported bugs,
and it's not code that's churning.

> I am very appreciative of the codebase.
> I'm going through it at the moment "stripping it down" a bit to be for
> x86-64 and adding some comments to help me better understand the
> process.

I'm not sure that makes much sense. The code as it is isn't overly
general or using any expensive abstraction layers to support all
archs. It's very intentionally designed around the concept that all
archs are basically the same in regards to how dynamic linking works.
Trying to specialize to just supporting one *obscures* that property
and makes the arch-specific naming/numbering of relocation types, etc.
look like a relevant difference when it's not.

> I was going to look at whether I can take on a C++ standard as a
> dependency as well.

I mean you can do whatever you like in your own hacking around, but
without being really intentional about what parts of C++ you do and
don't use, it's easy to pull in circular dependencies, dependencies on
things that depend on stuff before it has been (and before it's
possible to have been) initialized, etc.

Also, of course, C and C++ are different languages -- in particular,
C++ is a not a superset of C. There's no guarantee that any of the
code in musl behaves as intended when compiled as C++, because it's
not C++. This wouldn't matter if you're working with separate C++ TUs
but it would possibly matter if you started trying to put C++ in
existing C files.

Rich

Re: [musl] dynlink.c tests

[Farid Zakaria]

On Mon, Oct 23, 2023 at 5:03 PM Rich Felker <dalias@libc.org> wrote:
>
> On Mon, Oct 23, 2023 at 11:08:31AM -0700, Farid Zakaria wrote:
> > Just to be pedantic, few ideas come to mind:
> > - One could change the symbol count method to only use DT_HASH and it
> > would succeed until GCC removed it ;)
>
> There are already distros building with GNU-hash-only, so one of them
> would catch such breakage.
>
> > - The order of resolution for dependencies
>
> This has changed before from whatever-it-was to something very
> intentional, and basic testing of the intended order was done at the
> time, but we don't have regularly run tests for it. While future
> changes here would come with manual testing like that again, it would
> be nice to have an automated framework for this.
>
> > - $ORIGIN replacement
>
> This is probably under-tested but I'm not aware of any reported bugs,
> and it's not code that's churning.
>
> > I am very appreciative of the codebase.
> > I'm going through it at the moment "stripping it down" a bit to be for
> > x86-64 and adding some comments to help me better understand the
> > process.
>
> I'm not sure that makes much sense. The code as it is isn't overly
> general or using any expensive abstraction layers to support all
> archs. It's very intentionally designed around the concept that all
> archs are basically the same in regards to how dynamic linking works.
> Trying to specialize to just supporting one *obscures* that property
> and makes the arch-specific naming/numbering of relocation types, etc.
> look like a relevant difference when it's not.

Agreed that it's pretty minimal already.
Some of the code is quite terse, I'm guessing also favoring performance.
As a learning exercise, I'm trying to change the trade-off for clarity
in spite of performance.

>
> > I was going to look at whether I can take on a C++ standard as a
> > dependency as well.
>
> I mean you can do whatever you like in your own hacking around, but
> without being really intentional about what parts of C++ you do and
> don't use, it's easy to pull in circular dependencies, dependencies on
> things that depend on stuff before it has been (and before it's
> possible to have been) initialized, etc.
>
> Also, of course, C and C++ are different languages -- in particular,
> C++ is a not a superset of C. There's no guarantee that any of the
> code in musl behaves as intended when compiled as C++, because it's
> not C++. This wouldn't matter if you're working with separate C++ TUs
> but it would possibly matter if you started trying to put C++ in
> existing C files.
>
> Rich

I will have to learn more about C/C++ distinction.
I would think that the only dependency the STL has is libc and from
what I understand the dynamic linker relocates itself so that libc can
be used by the time stage3 rolled around.
The C++ can be separate compilation units and linked in -- I don't see
a problem setting that up if its easier.
I'm thinking of introducing it only for all the stage3+ stuff.
I already like how the functions largely work on the DSO struct itself.

I'm also doing some exploratory stuff with SQLite which I am finding
quite interesting.

Re: [musl] dynlink.c tests

[Fangrui Song]

> Is there a dynamic-loader test suite anyone is familiar with ?

FreeBSD rtld-elf has very few test
https://github.com/freebsd/freebsd-src/tree/main/libexec/rtld-elf/tests

glibc/elf contains extensive rtld tests. The Makefile-based test
system may be a bit tricky to deal with... but the coverage is quite
decent.
`configure --enable-hardcoded-path-in-tests` makes it easy to invoke a test.

On Mon, Oct 23, 2023 at 5:04 PM Rich Felker <dalias@libc.org> wrote:
>
> On Mon, Oct 23, 2023 at 11:08:31AM -0700, Farid Zakaria wrote:
> > Just to be pedantic, few ideas come to mind:
> > - One could change the symbol count method to only use DT_HASH and it
> > would succeed until GCC removed it ;)
>
> There are already distros building with GNU-hash-only, so one of them
> would catch such breakage.

Yes.

(For the curious, https://maskray.me/blog/2023-04-12-elf-hash-function
describes a bug in *BSD that dlsym(dl, "ZZZZZW9p") returned NULL for a
DSO linked with -shared -fuse-ld=lld -Wl,--hash-style=sysv.)

> > - The order of resolution for dependencies
>
> This has changed before from whatever-it-was to something very
> intentional, and basic testing of the intended order was done at the
> time, but we don't have regularly run tests for it. While future
> changes here would come with manual testing like that again, it would
> be nice to have an automated framework for this.

Absolutely! Things like the path precedence, constructor order, etc
will be very useful to have test coverage.

> > - $ORIGIN replacement
>
> This is probably under-tested but I'm not aware of any reported bugs,
> and it's not code that's churning.
>
> > I am very appreciative of the codebase.
> > I'm going through it at the moment "stripping it down" a bit to be for
> > x86-64 and adding some comments to help me better understand the
> > process.
>
> I'm not sure that makes much sense. The code as it is isn't overly
> general or using any expensive abstraction layers to support all
> archs. It's very intentionally designed around the concept that all
> archs are basically the same in regards to how dynamic linking works.
> Trying to specialize to just supporting one *obscures* that property
> and makes the arch-specific naming/numbering of relocation types, etc.
> look like a relevant difference when it's not.
>
> > I was going to look at whether I can take on a C++ standard as a
> > dependency as well.
>
> I mean you can do whatever you like in your own hacking around, but
> without being really intentional about what parts of C++ you do and
> don't use, it's easy to pull in circular dependencies, dependencies on
> things that depend on stuff before it has been (and before it's
> possible to have been) initialized, etc.
>
> Also, of course, C and C++ are different languages -- in particular,
> C++ is a not a superset of C. There's no guarantee that any of the
> code in musl behaves as intended when compiled as C++, because it's
> not C++. This wouldn't matter if you're working with separate C++ TUs
> but it would possibly matter if you started trying to put C++ in
> existing C files.
>
> Rich