Date: Sun, 5 Nov 2023 09:01:59 -0800 From: Fangrui Song <i@...kray.me> To: musl@...ts.openwall.com Cc: Farid Zakaria <fmzakari@...c.edu> Subject: Re: dynlink.c tests > 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@...c.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
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.