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 30811 invoked from network); 23 Oct 2023 17:57:40 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 23 Oct 2023 17:57:40 -0000 Received: (qmail 3492 invoked by uid 550); 23 Oct 2023 17:57:37 -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 3427 invoked from network); 23 Oct 2023 17:57:36 -0000 Date: Mon, 23 Oct 2023 13:57:30 -0400 From: Rich Felker To: Farid Zakaria Cc: musl@lists.openwall.com Message-ID: <20231023175730.GB22081@brightrain.aerifal.cx> References: <20231021000003.GO4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] dynlink.c tests On Mon, Oct 23, 2023 at 10:08:41AM -0700, Farid Zakaria wrote: > Sorry for the late reply Rich. > > That's what my current plan of attack is but I was wondering if the > musl codebase itself has such a test suite already > (something similar to the libc test suite) > > How do dynlink authors validate they haven't broken any edge cases in > program loading? > (i.e. such as DT_GNU_HASH etc..) Generally this code has almost zero churn, and is expected to be that way. Your example of gnu hash for example is a pure mathematical function that never has any reason to be changed. On top of that, none of this is code that dynamically succeeds or fails based on any complex runtime condition. For the most part, either it does the right thing or it doesn't, and if it doesn't, nothing would load. This doesn't mean testability is unwanted, just that this code is rather low priority for testing compared to things with a lot more dynamic corner cases. Rich > On Fri, Oct 20, 2023 at 5:00 PM Rich Felker wrote: > > > > On Fri, Oct 20, 2023 at 11:18:44AM -0700, Farid Zakaria wrote: > > > What's the best way to test dynlink.c ? > > > I'm making some small changes (actually just simplifying it by > > > removing some code for unneeded arch like DL_FDPIC) but would like to > > > make sure I didn't bork anything. > > > > > > I found https://wiki.musl-libc.org/writing-tests but that seems > > > focused strictly on the libc itself. > > > Is there a dynamic-loader test suite anyone is familiar with ? > > > > The general strategy I would use would be to setup recipes to build > > binaries/shared libraries that make use of particular dynamic linking > > features, then load/execute them in ways that assert that the relevant > > feature operated as expected. > > > > Rich