From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66542 invoked by alias); 7 Mar 2019 08:27:54 -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 66528 invoked by uid 89); 7 Mar 2019 08:27:54 -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=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=hundred X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_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.redhat.com Date: Tue, 01 Jan 2019 00:00:00 -0000 From: Jakub Jelinek To: Tom de Vries Cc: dwz@sourceware.org Subject: Re: [PATCH] Error out on DW_AT_location with invalid encoding Message-ID: <20190307082748.GU7611@tucnak> Reply-To: Jakub Jelinek References: <20190307072241.GA22169@delia> <20190307075541.GS7611@tucnak> <2fe7d53a-6bdd-7d5c-bb9d-1cd428f86c5d@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2fe7d53a-6bdd-7d5c-bb9d-1cd428f86c5d@suse.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 07 Mar 2019 08:27:52 +0000 (UTC) X-SW-Source: 2019-q1/txt/msg00092.txt.bz2 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 > ... 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 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? Jakub