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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 13275 invoked from network); 24 Oct 2023 01:23:48 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 24 Oct 2023 01:23:48 -0000 Received: (qmail 19930 invoked by uid 550); 24 Oct 2023 01:23:45 -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 19845 invoked from network); 24 Oct 2023 01:23:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google-2018; t=1698110612; x=1698715412; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HISrVi2ZyEcb6+Si8/0PrBT9HeTMuMxyA5klwtJQTAM=; b=sEuq/amEB3LwnUqspzpJvKEduWUwyv7hk1ZKtrJPLF29RNq4fu24RIY/K+t03ziO9Y DYyIlmw6g11ZSXmi/PvUmFPazNDYdV+gS4370w3lk+RQgdG9XqpM9xSwxgUgI1sVo5uy Kout8ybB1VzB+f6AxdSSJrH/TAFF61nzYqhLsMJ4AHogY7AD6kKh/7G5fv76cegESW1l jJYSjXiTOuSNF8mQUJdQZDe9GDDSX51Z5THpLwze0SZ1E/9AkpGXvdWUjMv0DhH8SyK/ 66xpPdZTQZmz8DL+WX+2p+ocfbq0Fb0rawRsaYVSAOooPqCHvDZ8OXScqzSs4t7e+DBx EG+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698110612; x=1698715412; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HISrVi2ZyEcb6+Si8/0PrBT9HeTMuMxyA5klwtJQTAM=; b=a2ZbJ75srx5pm8Wd6H1oMNufgTdj3LGdtgO4L+VBa9hYHyRMHy8sW5Fm0iD/f9meKz NU/5r6xasYo9c88OkbQJfSZ5bj66w5ErRfzt3lWS/pvi39+d3rix5UiBRVr+Kc6WQzfR 18sxSBiyq330wyrgxyB5Z9IDv1ttykO8mK0eSuWQLRTRLE1rBeI6UNwAOZ3MovRDtNst ayOEIyUN1h7ir8sF+gZoYjwrktb5nzz8Czk9fPkW+nfUg2x3RyjQBB5NO84W4KjvUVnS Y7X4ffnUaTOu0refXa0ZpgzRGxQ1eqrEfDWrn+jTSQDktVyIRle+N4ils+TGKj1JRnur I/Eg== X-Gm-Message-State: AOJu0YyIP1QRpYuXG/P+w/6JGY42PovM2UwubNnu6dCAa6ZzziJqRqPo T5x8XCCGN+uyPV6IbULqdLWvgWk3xQ/fzdanBQb8yw== X-Google-Smtp-Source: AGHT+IErr2kGM0RvTVZuGKXr/18aQivm4KJWj/LELfBIcGV2HEsra90iiDkgnxaUa0Gh4EITJJ8wbcZm1r7CgtfROuM= X-Received: by 2002:a17:90a:1648:b0:27d:51c4:1681 with SMTP id x8-20020a17090a164800b0027d51c41681mr8469685pje.18.1698110611726; Mon, 23 Oct 2023 18:23:31 -0700 (PDT) MIME-Version: 1.0 References: <20231021000003.GO4163@brightrain.aerifal.cx> <20231023175730.GB22081@brightrain.aerifal.cx> <20231024000358.GP4163@brightrain.aerifal.cx> In-Reply-To: <20231024000358.GP4163@brightrain.aerifal.cx> From: Farid Zakaria Date: Mon, 23 Oct 2023 18:23:20 -0700 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] dynlink.c tests On Mon, Oct 23, 2023 at 5:03=E2=80=AFPM Rich Felker 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.