From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id DvzIFso5GmCAQAAAWB0awg (envelope-from ) for ; Wed, 03 Feb 2021 00:51:06 -0500 Received: by simark.ca (Postfix, from userid 112) id 513541EF80; Wed, 3 Feb 2021 00:51:06 -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.0 required=5.0 tests=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 5309F1E945 for ; Wed, 3 Feb 2021 00:51:05 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 99F79387088C; Wed, 3 Feb 2021 05:51:04 +0000 (GMT) Received: from rock.gnat.com (rock.gnat.com [205.232.38.15]) by sourceware.org (Postfix) with ESMTP id DBD84387088C for ; Wed, 3 Feb 2021 05:51:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DBD84387088C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=brobecker@adacore.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 9E7311170E7; Wed, 3 Feb 2021 00:51:01 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1+9iSXk4C6By; Wed, 3 Feb 2021 00:51:01 -0500 (EST) Received: from float.home (localhost.localdomain [127.0.0.1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPS id 404501170F8; Wed, 3 Feb 2021 00:51:01 -0500 (EST) Received: by float.home (Postfix, from userid 1000) id 6F445A78CF; Wed, 3 Feb 2021 09:50:56 +0400 (+04) Date: Wed, 3 Feb 2021 09:50:56 +0400 From: Joel Brobecker To: Simon Marchi Subject: Re: GDB 10.2 release (respin) -- 2021-01-31 Update Message-ID: <20210203055056.GA2717@adacore.com> References: <20210131064557.GA72834@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" > > Simon also requested we consider: > > > > * [SimonM] > > DW_FORM_rnglistx and DW_FORM_loclistx not fully supported > > https://sourceware.org/bugzilla/show_bug.cgi?id=26813 > > > > Simon posted a patch series on Jan 20th: > > [PATCH 00/13] DWARF 5 rnglists & loclists fixes (PR 26813) > > https://sourceware.org/pipermail/gdb-patches/2021-January/175221.html > > This is now pushed on master. Do I have your OK to backport it? My > argument for backporting it is that support for processing these DWARF5 > attributes was new in GDB 10, but GDB chokes on any non-trivial use of > them (like when there are two compile units using rnglists). > > Not all patches are tagged with PR 26813 (because they are > cleanups/refactor), but the important ones, that contain the actual > fixes, do have it. Is that ok for the release branch? I don't know if I'll be able to provide a well educated answer, but here are some thoughts and questions. Generally speaking, anything that touches purely on rnglist seems OK to backport because I understand this support is entirely new. I'm a little less sure about the changes to liclist support, though. Is there something I don't know that puts the changes to loclist handling in the same category as the rnglist changes? Is it possible to skip some patches that are not strictly necessary, and if yes, would that actually be a good idea? With that in mind, my best thoughts on the matter so far: [PATCH 01/13] gdb/dwarf: change read_loclist_index complaints into errors Although unnecessary, I think this one is fine, and perhaps even desirable to avoid some weird behavior in GDB... [PATCH 02/13] gdb/dwarf: fix bound check in read_rnglist_index OK for gdb-10-branch [PATCH 03/13] gdb/dwarf: add missing bound check to read_loclist_index Seems straightforward and adds safety; OK for gdb-10-branch. [PATCH 04/13] gdb/dwarf: remove unnecessary check in read_{rng,loc}list_index Maybe drop this patch, on the basis that this is just a cleanup that should, in fine, be a no-op in practice. [PATCH 05/13] gdb/dwarf: few fixes for handling DW_FORM_{rng,loc}listx After verification in the DWARF 5 standard that those are unsigned ULEBs, this one looks good to me for gdb-10-branch. [PATCH 06/13] gdb/dwarf: read correct rnglist/loclist header in read_{rng, loc}list_index I will need to trust you on that one, as I think I would need to delve more deeply into DWARF 5, and I'm lacking the time (at least until this weekend). [PATCH 07/13] gdb/dwarf: read DW_AT_ranges value as unsigned in partial_die_info::read A little scarier for me, but the justification that we are already doing this in dwarf2_get_pc_bounds is convincing. OK for gdb-10-branch. [PATCH 08/13] gdb/testsuite: add .debug_rnglists tests [PATCH 09/13] gdb/testsuite: DWARF assembler: add context parameters to _location [PATCH 10/13] gdb/testsuite: add .debug_loclists tests No problem for me. [PATCH 11/13] gdb/dwarf: split dwarf2_cu::ranges_base in two Do we need this? Looks like you are saying that this is an enhancement for a case that is unlikely to happen in practice? [PATCH 12/13] gdb/dwarf: make read_{loc, rng}list_index return sect_offset OK for gdb-10-branch, with perhaps a question regarding the gains-vs-risks ratio? [PATCH 13/13] gdb/testsuite: add test for .debug_{rng, loc}lists section without offset array No problem for me. -- Joel