From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) by sourceware.org (Postfix) with ESMTPS id 37C293857C60 for ; Thu, 16 Jul 2020 15:47:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 37C293857C60 Received: by mail-io1-xd43.google.com with SMTP id v8so6514445iox.2 for ; Thu, 16 Jul 2020 08:47:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HnjUIjF1rZbx0YVDAq87BDbmGZSlNgZCMfi+4f4383Q=; b=qMTt05GCQB2vg1uFEWgHvDuqLotpCH40hqqqfxWvRcsB2J+5dbcWAcCLvniboePcWM wGMvUoZcrWTcQ0fde8nP9A3pqP/H5qT6AIUE760jJlI9fgJKJWbZMLmaWAEWdlU0KOMl zgCxvg6QatjmD6KHm1PioHHyx2wxjwP6VbU3PooYA7Xsy115skC0Am9EQPC01G1pLBKk Yxygd88JtSbSf/FRIHZPUVQGUZ08H1ZbboXxFQ73VP4WNuBEVoweFdV12X2lTHqr+OGt S0PbWbyysnbSIxTa1XceuGGrVZ/Ut4yxRQIEv+IsWTlJ4Am58y3+wghcApoyYctRUxMW t6uA== X-Gm-Message-State: AOAM533xHOp+9YZ2J+cil7ofhO/0oGPgh48BOpv6Q5q4FWtY8z3yHAu/ LyHz7EwBn5t6/jsGmUN8wT5Wjud/+TP205REoHVWig== X-Google-Smtp-Source: ABdhPJwQam5Z216rWsRQGEb2DaclEFUV390MJXlLTs2hFnbV/Bd22dI9pAZzKKSbvU38NoPzudI8Gz3edocWIWCI6QI= X-Received: by 2002:a5e:a60d:: with SMTP id q13mr5028875ioi.199.1594914419416; Thu, 16 Jul 2020 08:46:59 -0700 (PDT) MIME-Version: 1.0 References: <5eab18a1-c7e9-1a77-7f65-944eea10aa85@simark.ca> <5ccfe911-6049-e8f3-4874-9991b2649512@simark.ca> <4da310be-fa9f-9f21-8988-81af58ec73e3@simark.ca> <804c1d3e-522f-f6bf-0106-330dcfd1fc50@simark.ca> In-Reply-To: <804c1d3e-522f-f6bf-0106-330dcfd1fc50@simark.ca> From: Caroline Tice Date: Thu, 16 Jul 2020 08:46:48 -0700 Message-ID: Subject: Re: [PATCH V5] Fix issues with reading rnglists, especially from dwo files, for DWARF v5 To: Simon Marchi Cc: "H.J. Lu" , Eric Christopher , Tom Tromey , Caroline Tice via Gdb-patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-19.1 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Thu, 16 Jul 2020 15:47:01 -0000 On Thu, Jul 16, 2020 at 8:41 AM Simon Marchi wrote: > > On 2020-07-16 12:46 a.m., Caroline Tice wrote: > > The attached patch has an updated commit message that explains how to > > run the test and what version of clang was used. Other than that it > > is identical to the previous patch. > > Thanks, I've now merged it. Thank you! :-) > > >> Just wondering, doesn't gcc emit at least *some* DWARF 5 by now? If so, > >> can't the GNU assembler deal with it? > >> > > > > Not that it matters for this patch, but I believe you are > > misunderstanding the situation. GCC *does* emit some DWARF 5, but at > > least the GCC version I'm using (Debian 9.3.0-8) does not seem to be > > generating DWARF v5 line table sections; the line table section it > > generates (when I compile with -gdwarf-5) is a DWARF v3 .debug_line > > sections. > > > > In fact my gcc-generated binary has the following debug sections, > > which are a mix of various dwarf versions: > > > > .debug_aranges (dwarf v2) > > .debug_info (dwarf v5) > > .debug_abbrev (dwarf v5) > > .debug_line (dwarf v3) > > .debug_str > > .debug_addr (dwarf v5) > > .debug_gnu_pubnames (dwarf v2) > > .debug_gnu_pubtypes (dwarf v2) > > .debug_rnglists (dwarf v5) > > I see. But if we generate a synthetic test case (using the DWARF assembler > in the GDB testsuite) for the current issue, that deals with range lists, > I don't think we even need a .debug_line section, do we? And if we do, we > always have the option of generating a v3 one. We do in fact need the .debug_line section, because the test relies on setting a breakpoint at a particular line, and then seeing whether or not we can find the value of a variable in the lexical block there; without line table information I don't think GDB will be able to do that. > > > In contrast, here are the sections my clang compiler, when passed > > -gdwarf-5 is generating dwarf v5 versions > > of nearly all the sections: > > > > .debug_info (dwarf v5) > > .debug_abbrev (dwarf v5) > > .debug_line (dwarf v5) > > .debug_str > > .debug_addr (dwarf v5) > > .debug_rnglists (dwarf v5) > > .debug_str_offsets (dwarf v5) > > .debug_gnu_pubnames (dwarf v2) > > .debug_gnu_pubtypes (dwarf v2) > > .debug_line_str (dwarf v5) > > > > So either the GNU assembler has not been updated to handle DWARF v5 > > .debug_line file indices because GCC is not yet generating them; or > > GCC is not yet generating them because the GNU assembler has not yet > > been > > updated to handle them. Take your pick. > > > > In any case, I hope my patch is now acceptable! :-) > > Simon >