From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id o+3JFgvNpF9EBQAAWB0awg (envelope-from ) for ; Thu, 05 Nov 2020 23:11:55 -0500 Received: by simark.ca (Postfix, from userid 112) id 5098C1F08B; Thu, 5 Nov 2020 23:11:55 -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 9F9BC1E552 for ; Thu, 5 Nov 2020 23:11:54 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DD1593892002; Fri, 6 Nov 2020 04:11:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DD1593892002 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1604635913; bh=CFmhI5tRK/+eht1mxaxf+QwbVTe+NUiPnAbV0x/pj+4=; h=Subject:To:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=RN++jEhKXVyQ9iMvkp+OwWqmv9hg/8B10RqOkEOiEar5reIkDLmm0G/68XfSCSgDc 6VVi4WOaZOyH5TduutuM8eEdVlyeHmMolwQciUqYPVdyByj8X/QlWfaGh9UQ/rzHZS 9f1gqjATG+pXevrv8vynJd7OGGtS9Ssi29yXgRMo= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id EF8113892002 for ; Fri, 6 Nov 2020 04:11:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EF8113892002 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 0A64BiYl012589 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Nov 2020 23:11:49 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 0A64BiYl012589 Received: from [10.0.0.11] (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) (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 5044C1E552; Thu, 5 Nov 2020 23:11:44 -0500 (EST) Subject: Split DWARF and rnglists, gcc vs clang To: GDB patches , gcc-patches List Message-ID: Date: Thu, 5 Nov 2020 23:11:43 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 6 Nov 2020 04:11:44 +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 Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Hi, I'm currently squashing some bugs related to .debug_rnglists in GDB, and I happened to notice that clang and gcc do different things when generating rnglists with split DWARF. I'd like to know if the two behaviors are acceptable, and therefore if we need to make GDB accept both. Or maybe one of them is not doing things correctly and would need to be fixed. clang generates a .debug_rnglists.dwo section in the .dwo file. Any DW_FORM_rnglistx attribute in the DWO refers to that section. That section is not shared with any other object, so DW_AT_rnglists_base is never involved for these attributes. Note that there might still be a DW_AT_rnglists_base on the DW_TAG_skeleton_unit, in the linked file, used if the skeleton itself has an attribute of form DW_FORM_rnglistx. This rnglist would be found in a .debug_rnglists section in the linked file, shared with the other units of the linked file. gcc generates a single .debug_rnglists in the linked file and no .debug_rnglists.dwo in the DWO files. So when an attribute has form DW_FORM_rnglistx in a DWO file, I presume we need to do the lookup in the .debug_rnglists section in the linked file, using the DW_AT_rnglists_base attribute found in the corresponding skeleton unit. This looks vaguely similar to how it was done pre-DWARF 5, with DW_AT_GNU_ranges base. So, is gcc wrong here? I don't see anything in the DWARF 5 spec prohibiting to do it like gcc does, but clang's way of doing it sounds more in-line with the intent of what's described in the DWARF 5 spec. So I wonder if it's maybe an oversight or a misunderstanding between the two compilers. But if both ways are correct, then we just need to know so we can implement it in GDB. Although we'll probably need to implement reading what gcc currently produces, since it's already in the wild. Simon