Date: Mon, 23 Oct 2023 18:23:20 -0700 From: Farid Zakaria <fmzakari@...c.edu> To: Rich Felker <dalias@...c.org> Cc: musl@...ts.openwall.com Subject: Re: dynlink.c tests On Mon, Oct 23, 2023 at 5:03 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. > > > - 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.
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.