From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id MI03C1jbEmBEdQAAWB0awg (envelope-from ) for ; Thu, 28 Jan 2021 10:42:16 -0500 Received: by simark.ca (Postfix, from userid 112) id 29FE61EF80; Thu, 28 Jan 2021 10:42:16 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 3DA261E945 for ; Thu, 28 Jan 2021 10:42:15 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EE5D93851C22; Thu, 28 Jan 2021 15:42:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EE5D93851C22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1611848535; bh=A93i1yxs9DC8ePDabZYS8/ciwdp3Krx85XXusxjUBQ0=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=e171ldSDSojO1/Kxu8kmqZuFxqRjwTL7JCPC4eR/pFgWawHAk6GfrOCCEnBYQjG2G iUhvHfefiMhYL9mp4JCU/nhDiF1HRHH0salxhlbjoPKBXTkAb/NA3xuelkJOh55msK HV+HuMeWZCD4caTb6dneNx2Zso5+l7Y6pYvYl1uk= Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by sourceware.org (Postfix) with ESMTPS id 8D56E385800F for ; Thu, 28 Jan 2021 15:42:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8D56E385800F Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 14B6C2DE3BE; Thu, 28 Jan 2021 10:42:12 -0500 (EST) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id VvX8uywqHEca; Thu, 28 Jan 2021 10:42:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id C967E2DE3BD; Thu, 28 Jan 2021 10:42:11 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com C967E2DE3BD X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rjIdJx2ftPPI; Thu, 28 Jan 2021 10:42:11 -0500 (EST) Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) by mail.efficios.com (Postfix) with ESMTPSA id A73492DE2CA; Thu, 28 Jan 2021 10:42:11 -0500 (EST) Subject: Re: [PATCH 01/13] gdb/dwarf: change read_loclist_index complaints into errors To: Zoran Zaric , Simon Marchi , gdb-patches@sourceware.org References: <20210120053925.142862-1-simon.marchi@polymtl.ca> <20210120053925.142862-2-simon.marchi@polymtl.ca> <6d8498e3-8580-e537-d5b4-4dcb041bb7a9@amd.com> Message-ID: <4630fd66-61d9-319c-fc06-bf6e3f6fc34c@efficios.com> Date: Thu, 28 Jan 2021 10:42:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <6d8498e3-8580-e537-d5b4-4dcb041bb7a9@amd.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2021-01-28 10:17 a.m., Zoran Zaric wrote: >> From: Simon Marchi >> >> Unlike read_rnglists_index, read_loclist_index uses complaints when it >> detects an inconsistency (a DW_FORM_loclistx value without a >> .debug_loclists section or an offset outside of the section). I really >> think they should be errors, since there's no point in continuing if >> this situation happens, we will likely segfault or read garbage. >> > > Makes sense. > > Although unless I misunderstand something, isn't the difference here that the error will actually throw an exception and therefore stop reading of the compilation unit if not the whole object file debug information? > > If this is the case, then considering the difference in usage between the two, having a wrong loclist information can still provide a correct line table information, but having a wrong rnglist information in my mind creates a more serious issue. > > On the other hand, how much can one trust in the information correctness if either of those are wrong. Indeed, `error` throws an exception that gets handled... I don't know where. If you are reading partial symtabs, it probably goes up to dwarf2_build_psymtabs, so it stops the processing for the whole object file. I think it's correct from the read_rnglists_index and read_loclist_index functions point of view to throw if they encounter invalid data and can't return something meaningful. If we want to make error handling a bit more granular, we could catch the error in the caller (read_attribute_reprocess), make it display a complaint, and continue as if the attribute wasn't present. We won't have location or range information for this entity (or perhaps for all entities, if we fail to read all of them), but perhaps other parts of the debug info will be read fine. And those other parts could maybe be useful to some user, versus aborting completely and having no debug info at all. However, I don't intend to do this at the moment, because it would be quite a lot of work to do and test properly, in the end to accomodate an hypothetical buggy compiler. Maybe if/when we have a concrete instance of a widely available compiler producing such buggy debug info, we can revisit this idea. Thanks for the review! Simon