Re: [musl] dynlink.c tests

[Rich Felker <dalias@libc.org>]

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