From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id pfNXDy3dEmCXdQAAWB0awg (envelope-from ) for ; Thu, 28 Jan 2021 10:50:05 -0500 Received: by simark.ca (Postfix, from userid 112) id 323E81EF80; Thu, 28 Jan 2021 10:50:05 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [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 791AC1E945 for ; Thu, 28 Jan 2021 10:50:04 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0A3AD39960FC; Thu, 28 Jan 2021 15:50:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0A3AD39960FC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1611849004; bh=KbrAPyieEp7ozMBCEe30z2DponzDDhJSs4xMuJrD8cs=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=BX5xsDJGrrFKm19yDrc2+wYcYlM4wniOFo27HFHQSrgPBEQg4t4lxlykVIpFu/NZ0 vnCv1Bsbhva/GT2bTL989SEDPLhAU3Ux5B8LK+V+8YmqOph0xKEiWWikt61E6X/zvm BWzPdEfTnOn7Sy4WHfH6kzInA+vqODrW0E2/LsK0= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id A6E6C3870850 for ; Thu, 28 Jan 2021 15:50:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A6E6C3870850 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 10SFnlfS019497 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Jan 2021 10:49:52 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 10SFnlfS019497 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id A38231E945; Thu, 28 Jan 2021 10:49:47 -0500 (EST) Subject: Re: [PATCH 06/13] gdb/dwarf: read correct rnglist/loclist header in read_{rng,loc}list_index To: Zoran Zaric , gdb-patches@sourceware.org References: <20210120053925.142862-1-simon.marchi@polymtl.ca> <20210120053925.142862-7-simon.marchi@polymtl.ca> <17a5bb39-2268-67ce-f75c-fce75188975b@amd.com> Message-ID: Date: Thu, 28 Jan 2021 10:49:47 -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: <17a5bb39-2268-67ce-f75c-fce75188975b@amd.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Thu, 28 Jan 2021 15:49:47 +0000 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 Cc: Simon Marchi Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2021-01-28 10:39 a.m., Zoran Zaric wrote:>> From: Simon Marchi >> >> When loading the binary from PR 26813 in GDB, we get: >> >> DW_FORM_rnglistx index pointing outside of .debug_rnglists offset array [in module /home/simark/build/binutils-gdb/gdb/MagicPurse] >> >> ... and the symbols fail to load. >> >> In read_rnglist_index and read_loclist_index, we read the header >> (documented in sections 7.28 and 7.29 of DWARF 5) of the CU's >> contribution to the .debug_rnglists / .debug_loclists sections to >> validate that the index we want to read makes sense. However, we always >> read the header at the beginning of the section, rather than the header >> for the contribution from which we want to read the index. >> >> To illustrate, here's what the binary from PR 26813 contains. There are >> two compile units: >> >> 0x0000000c: DW_TAG_compile_unit 1 >> DW_AT_ranges [DW_FORM_rnglistx]: 0x0 >> DW_AT_rnglists_base [DW_FORM_sec_offset]: 0xC >> >> 0x00003ec9: DW_TAG_compile_unit 2 >> DW_AT_ranges [DW_FORM_rnglistx]: 0xB >> DW_AT_rnglists_base [DW_FORM_sec_offset]: 0x85 >> >> The layout of the .debug_rnglists is the following: >> >> [0x00, 0x0B]: header for CU 1's contribution >> [0x0C, 0x0F]: list of offsets for CU 1 (1 element) >> [0x10, 0x78]: range lists data for CU 1 >> >> [0x79, 0x84]: header for CU 2's contribution >> [0x85, 0xB4]: list of offsets for CU 2 (12 elements) >> [0xB5, 0xBD7]: range lists data for CU 2 >> >> The DW_AT_rnglists_base attrbute points to the beginning of the list of >> offsets for that CU, relative to the start of the .debug_rnglists >> section. That's right after the header for that contribution. >> >> When we try to read the DW_AT_ranges attribute for CU 2, >> read_rnglist_index reads the header for CU 1 instead of the one for CU >> 2. Since there's only one element in CU 1's offset list, it believes >> (wrongfully) that the index 0xB is out of range. >> >> Fix it by reading the header just before where DW_AT_rnglists_base >> points to. With this patch, I am able to load GDB built with clang-11 >> and -gdwarf-5 in itself, with and without -readnow. >> > > I came to the same conclusion, the issue was probably never noticed because the tested compilers only ever generated one rangelist entry. > > Even LLVM didn't seem to generate it before version 11, or at least I haven't noticed the issue when I was previously testing the DWARF 5 support. Indeed, and I think it was only used on the compilation unit's DIE? >> >> Change-Id: Ie53ff8251af8c1556f0a83a31aa8572044b79e3d >> > > Are these Gerrit change ID's? They shouldn't be part of the patches right? > > Zoran I do use Gerrit personally to track the patches I work on, their versions, which ones have been merged and which ones haven't. When I push the patches upstream and then sync my Gerrit instance's master branch, it automatically sees which patches have been merged in the master branch and closes the corresponding reviews. So keeping the Gerrit Change-Id really helps me, and I don't think it bothers anyone, so I leave them there. Simon