From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id B092E3857C7E; Mon, 17 May 2021 10:06:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B092E3857C7E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id CD194B16D; Mon, 17 May 2021 10:06:16 +0000 (UTC) Subject: Re: [PATCH] Fail if dwz fails. To: Mark Wielaard , =?UTF-8?Q?Martin_Li=c5=a1ka?= Cc: debugedit@sourceware.org, dwz@sourceware.org References: <0c4f9c78-ee2b-fb6f-a0f9-20c3731bfa0e@suse.cz> <0cfabb5c75508dc7dc419caa7c0e935ebc241bb3.camel@klomp.org> <153645a1-cdd7-e5cc-a392-e63ad3d44433@suse.cz> From: Tom de Vries Message-ID: <709b6355-a15e-ee99-df50-786f045eb44b@suse.de> Date: Mon, 17 May 2021 12:06:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: debugedit@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: debugedit development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 10:06:20 -0000 On 5/16/21 10:14 PM, Mark Wielaard wrote: > Hi Martin, > > On Fri, May 14, 2021 at 12:46:15PM +0200, Martin Liška wrote: >> On 5/13/21 4:07 PM, Mark Wielaard wrote: >>>> On 4/22/21 1:11 PM, Martin Liška wrote: >>>>> Right now, dwz return code is 0 or a small integer value (<= 3) >>>>> for situations like: >>>>> >>>>> - dwz: Too few files for multifile optimization >>>>> - dwz: Multi-file optimization not allowed for different pointer sizes or endianity >>>>> >>>>> These are not fatal errors and the script should continue. On the other >>>>> hand abort or segfault error values should cause failure of the script. >>>>> >>>>> Let's reserve values 1-16 for a recoverable dwz exit codes. >>> >>> With "recoverable" you mean that dwz did do compression, but could not >>> deliver optimal compression? >> >> No, I speak about cases, where compression cannot be done >> (different endianess, ptr sizes, not beneficial, any other reason). > > I think we are talking about somewhat the same thing. In those cases > dwz does something. The result is just not optimal. > >>> It would be good to have an ack from the dwz developers that 1 to 16 >>> are "recoverable" errors (I added dwz@sourceware.org to CC). >> >> Yes. That's why I CCed Tom. >> >>> AFAIK, the exit codes are either 0 or 1 (excluding abort/assert). FWIW, also invalid input dwarf results in exit code 1. >>> Would it be possible to tweak the find-debuginfo.sh script to avoid >>> them? e.g. Could we see how many arguments we have so that we only use >>> -m when there are 1+ debug files? And/Or detect debug files using >>> different endianess and ptr sizes so they are processed in different >>> batches? >> >> No, I would leave it to dwz. There may be other reasons. > > But for the reasons we do know about we could improve > find-debuginfo.sh to do the right thing (not use -m if there is only > one file, sort files by endianess/ptrsize). Ideally you call > find-debuginfo.sh and it does the right thing even if you only have > one ELF file or a mix of ELF files. > >>> Ideally an error code from dwz means something went terribly wrong and >>> we abort find-debuginfo.sh. IMHO. >> >> I would allow the mentioned "soft" error codes. > > Couldn't optimize is an "soft" error indeed. I don't know about the > others. Couldn't optimize is not an error: ... $ ./dwz hello ; echo $? 0 $ ./dwz hello ; echo $? ./dwz: hello: DWARF compression not beneficial - old size 3372 new size 3372 0 $ ... OTOH, failing to create a file specified with -o is: ... $ ./dwz hello -o hello.1; echo $? 0 $ ./dwz hello.1 -o hello.2; echo $? ./dwz: hello.1: DWARF compression not beneficial - old size 3372 new size 3372 1 $ ... FWIW, I don't have a strong opinion on this patch. As dwz developer, more bug reports means a better dwz, so this is good for me. I just wonder whether this is a good choice for package developers. Isn't a dwz crash for them just a case of "no debuginfo compression"? Thanks, - Tom