From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86097 invoked by alias); 20 Mar 2019 18:01:04 -0000 Mailing-List: contact dwz-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: dwz-owner@sourceware.org Received: (qmail 85762 invoked by uid 89); 20 Mar 2019 18:00:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-8.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=16k, Vries, 16K, vries X-Spam-Status: No, score=-8.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Message-ID: Subject: Re: [RFC] External testsuite using binaries From: Mark Wielaard To: Tom de Vries , Jakub Jelinek Cc: dwz@sourceware.org Date: Tue, 01 Jan 2019 00:00:00 -0000 In-Reply-To: <3ed89fb7-ae0c-23de-a6c5-78cc7c370083@suse.de> References: <3ed89fb7-ae0c-23de-a6c5-78cc7c370083@suse.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-2.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-SW-Source: 2019-q1/txt/msg00153.txt.bz2 Hi Tom, Sorry for the late response. I saw others (on overseers) already gave some feedback. I don't think my feedback is really very different, but here are my 2 cents. On Thu, 2019-03-07 at 14:51 +0100, Tom de Vries wrote: > since large files tend to be a problem in git, I've created a > testsuite > containing binaries, that can be downloaded from ftp and plugged into > the dwz sources. >=20 > It contains the following executables: > ... > 272M cc1 > 223M cc1.dwz-processed > 16K dw2-restrict > 16K dw2-skip-prologue > 9,1M etcd > 8,2M etcdctl > 16K multidictionary > 8,0K py-section-script.debug > ... >=20 > Is it ok to move some of these (based on a size limit) to dwz.git, or > do we want to keep these separate? - I think the binaries shouldn't be in the main git repo. - For the smaller ones adding .S files might be acceptable in the main git repo. - If you offer them on some ftp site you want some mechanism (hash?) to make sure people don't need to redownload these binaries over and over again (especially important for the autobuilders). - So a (separate) git repo seems better. I don't think you really need an extension for large binary files unless you intend to replace or alter the binaries checked in. If it is just adding new binaries I believe git handles that fine as is. - It IMHO essential that they come with corresponding source and build instructions. So they can be reproduced. - If at all possible I would try to only use small ones of a couple of K. I am not sure what multi-megabyte binaries add. - If multi-megabyte binaries are really essential how would we handle the extra memory and disk space needed on the test machines? Can skip processing if there isn't enough disk/memory available? - Have you considered extending the dwz.tests/dwz.sh self test instead? Build the different .o files with -g(123) -g[no-]strict-dwarf, -gdwarf-(2345), -f[no-]debug-types-section, etc. And see if dwz handles itself when combining those object files? Or is this for catching different issues? Cheers, Mark