[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 Oct 2023 20:03:58 -0400
From: Rich Felker <dalias@...c.org>
To: Farid Zakaria <fmzakari@...c.edu>
Cc: musl@...ts.openwall.com
Subject: Re: dynlink.c tests
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
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.
