From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9988 invoked from network); 24 Oct 2023 00:04:20 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 24 Oct 2023 00:04:20 -0000 Received: (qmail 16200 invoked by uid 550); 24 Oct 2023 00:04:16 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 16005 invoked from network); 24 Oct 2023 00:04:01 -0000 Date: Mon, 23 Oct 2023 20:03:58 -0400 From: Rich Felker To: Farid Zakaria Cc: musl@lists.openwall.com Message-ID: <20231024000358.GP4163@brightrain.aerifal.cx> References: <20231021000003.GO4163@brightrain.aerifal.cx> <20231023175730.GB22081@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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