From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97707 invoked by alias); 7 Mar 2019 08:58:30 -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 97691 invoked by uid 89); 7 Mar 2019 08:58:30 -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=-14.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=guessed, HX-Languages-Length:1597, hundred X-Spam-Status: No, score=-14.4 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: mx1.suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Subject: Re: [PATCH] Error out on DW_AT_location with invalid encoding To: Jakub Jelinek Cc: dwz@sourceware.org References: <20190307072241.GA22169@delia> <20190307075541.GS7611@tucnak> <2fe7d53a-6bdd-7d5c-bb9d-1cd428f86c5d@suse.de> <20190307082748.GU7611@tucnak> From: Tom de Vries Message-ID: <05497c45-630c-a90f-be7a-983bb9d588eb@suse.de> Date: Tue, 01 Jan 2019 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <20190307082748.GU7611@tucnak> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SW-Source: 2019-q1/txt/msg00093.txt.bz2 On 07-03-19 09:27, Jakub Jelinek wrote: > On Thu, Mar 07, 2019 at 09:23:19AM +0100, Tom de Vries wrote: >> On 07-03-19 08:55, Jakub Jelinek wrote: >>> On Thu, Mar 07, 2019 at 08:22:42AM +0100, Tom de Vries wrote: >>>> Hi, >>>> >>>> When processing a file containing an DW_AT_location with encoding DW_FORM_addr, >>> >>> What kind of generator generates that? Ugh. >> >> AFAICT it's the result of generating a .s file from a .c file and then >> hand-editing the debug info ( >> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/testsuite/gdb.dwarf2/dw2-restrict.S;h=7108b86ec109ce5a1bd299e2c36696a12024e0d5;hb=HEAD >> ): >> ... >> .byte 16 # DW_AT_stmt_list >> .byte 1 # DW_FORM_addr >> ... > Hmm, I guessed it was an error introduced by hand-editing, but digging a little further, it was in fact a generator error (clang 2.9): https://bugs.llvm.org/show_bug.cgi?id=9995 . > Is it worth bothering with that then? Shouldn't just gdb be fixed? > Or is it intentional that the test tests how it deals with invalid DWARF? > I'm not sure if the test-case should be fixed. Gdb testcases are known to contain invalid dwarf, although indeed in this case the test-case is just to test handling of DW_TAG_restrict_type, not invalid dwarf. > I mean, dwz has over hundred asserts and many of them will fail if fed > complete garbage. Do we want to turn them all into errors? I'd propose we just fix the ones that show up with gdb testsuite (which are just a couple), because it's a known way to test dwz. Thanks, - Tom