From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) by sourceware.org (Postfix) with ESMTPS id D6B30385700D for ; Wed, 15 Jul 2020 17:05:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D6B30385700D Received: by mail-io1-xd44.google.com with SMTP id l1so3016081ioh.5 for ; Wed, 15 Jul 2020 10:05:18 -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=k/ftxPTOh2EikBZIiFrDiMwLerfDHyIR88mUBBqSbFA=; b=dZ4Elckpwxif8fBy9Q0pCLRp0HRGFbb3poN0DxeO5SVnWc53ycXsCu2gnoWjIMxNLc 2wqE+0n2hRA5h9bsni34nDsXLG/ztnbomdV17AGukcQzKzWiicLF6t53KNUtU+PvB6sX iqaxiSBEtbU8Nh0Bn8s3wYpGq1V2/RsFbuLoDx87m6CyGCi8zn7HeKzcKin8KR8Ty/dE LN3G3gRLjoItik96n8inS3I+q5eBHiCbbr0VBW2Q8Ito2kVfziuYfWJzorxEFOMU5G+c 9PLI6AS++Fa8Eo4VtWExThgQhcbvJhTqjH/03ZXSVkGD7KjrCpIgXawyMuWEL60DpE4Y IB6Q== X-Gm-Message-State: AOAM533s6ur0tMXrOunt20ZXmiFNOuzAzV865iczibwUBBG6AHd65GcO uR/RtTQrTj3ajYsA83MtCdw7RjTItR5ysDqm5KRKlBY3Fvs= X-Google-Smtp-Source: ABdhPJzJ5buluBZ+k697mMnXpHzBpXECHDCejJOIoOFJrW7SnzwDOS2yVRgINF244LdC3+4UeyWeE6abhriZSMgmZuQ= X-Received: by 2002:a5d:8552:: with SMTP id b18mr294135ios.28.1594832718255; Wed, 15 Jul 2020 10:05:18 -0700 (PDT) MIME-Version: 1.0 References: <87h7vsqk5h.fsf@tromey.com> <87h7v815n7.fsf@tromey.com> <5eab18a1-c7e9-1a77-7f65-944eea10aa85@simark.ca> <5ccfe911-6049-e8f3-4874-9991b2649512@simark.ca> <4da310be-fa9f-9f21-8988-81af58ec73e3@simark.ca> In-Reply-To: From: "H.J. Lu" Date: Wed, 15 Jul 2020 10:04:41 -0700 Message-ID: Subject: Re: [PATCH V5] Fix issues with reading rnglists, especially from dwo files, for DWARF v5 To: Caroline Tice Cc: Simon Marchi , Eric Christopher , Tom Tromey , Caroline Tice via Gdb-patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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: Wed, 15 Jul 2020 17:05:20 -0000 On Wed, Jul 15, 2020 at 9:58 AM Caroline Tice via Gdb-patches wrote: > > On Tue, Jul 14, 2020 at 8:15 PM Simon Marchi wrote: > > > > On 2020-07-14 10:04 p.m., Simon Marchi wrote: > > > I don't think I have any more comments. Tom, are you ok with this? > > > > I just had a thought about the test, and testing in general of DWARF5 and > > split DWARF. Right now, it's not really testing DWARF5 range lists, as the > > name implies. It's more a general program that may happen to fail given the > > right compiler and compiler version. > > > > [In fact, could you mention (here and in the commit message) how to run your > > test case so that it fails, when the rest of your patch is not applied? The > > full "make check" command line, plus the compiler version used to compiler > > the test case. > > > > Ideally, we would have: > > > > - one test such for the very specific case you are fixing (DW_AT_ranges inside > > a dwo with DWARF5). We would use the DWARF assembler in lib/dwarf.exp to > > generate exactly what we want to test. It would probably need to be improved > > a bit to learn about rnglists though. > > - a new board file that tests with "-gsplit-dwarf -gdwarf5". A bit like > > fission.exp, but for DWARF5. I think a plain "-gdwarf5" board file would > > be useful too. > > > > Simon > > > > > > The test program is the best I could manage under difficult > constraints. It does (currently) generate a lexical block with a > DW_AT_ranges attribute of the form DW_FORM_rnglistx, if it is compiled > with clang. If it is compiled with GCC, then, sadly, the > DW_AT_ranges is not of the form DW_FORM_rnglistx, so the test always > passes. In order to test with clang, I do: > > $ export CLANG_CC="/usr/local/google3/cmtice/llvm-project/build2/bin/clang" > $ export CLANG_CXX="/usr/local/google3/cmtice/llvm-project/build2/bin/clang++" > > $ make check RUNTESTFLAGS="CC_FOR_TARGET=${CLANG_CC} > CXX_FOR_TARGET=${CLANG_CXX} dw5-rnglist-test.exp" > > With ToT GDB (without my patch), the result is: > > Running /usr/local/google/home/cmtice/fsf-gdb.clean.obj/gdb/testsuite/../../../fsf-gdb.clean/gdb/testsuite/gdb.dwarf2/dw5-rnglist-test.exp > ... > FAIL: gdb.dwarf2/dw5-rnglist-test.exp: print curr > FAIL: gdb.dwarf2/dw5-rnglist-test.exp: print *curr > > === gdb Summary === > > # of expected passes 1 > # of unexpected failures 2 > > I did try, originally, to make this an assembly code test, as I do > understand that compilers change, and the code they generate today is > not necessarily the code they generate tomorrow. Unfortunately the > GNU assembler cannot process the DWARF v5 that is generated by clang > (e.g. it can't handle file numbers that start at 0 instead of 1 (which > is in the DWARF v5 spec, and which clang generates); and I have not > been able to figure out a way to get GDB test to use the clang > integrated assembler. > I have used object files in binutils tests: commit d0dded5bc251e506ef65b13696c624ea8669ed6e Author: H.J. Lu Date: Tue Jun 23 09:19:05 2020 -0700 Add a testcase for PR binutils/26160 PR binutils/26160 * testsuite/binutils-all/pr26160.dwp.bz2: New file. * testsuite/binutils-all/pr26160.r: Likewise. * testsuite/binutils-all/readelf.exp: Run PR binutils/26160 test. -- H.J.