From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x142.google.com (mail-il1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) by sourceware.org (Postfix) with ESMTPS id 6FCD4384240C for ; Wed, 15 Jul 2020 22:35:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6FCD4384240C Received: by mail-il1-x142.google.com with SMTP id h16so3405465ilj.11 for ; Wed, 15 Jul 2020 15:35:26 -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=zlm3iQ4zPZsE0cO0yoa7Ux0QvsSvZRm0xVqmbgBZs4k=; b=LizVn9qRO1Hylkra/w/Xhgm9M3ZFrzhFUbUaT0HFg+rRoiw50RBWDyvG+MjToWGXU0 +1V7UYu+CurcYjQdJ/lVpLBdkFOsOUZKTOzcITlqTF8/RLSgN9bEPxJ7HStD1sz4K7tH AIAHB8jJVDxP1OvTO+EAleoS69NMaXunP54SiUXZGZoYwy+aPXp9mA9jofOnySsEz3L7 W6wDRwslTy1ZWzB3VA428dgwaoaH31fptz21Ey3qDLpPpaKfdDGSqMlwCCc8rTIKwfjD 4UgZ2q3ePuCtjskT+47gbiqM3K1REDoZNpG8HQgMDMBI4TfM7G+4MRThwMHJ3ANTyEEC B/hA== X-Gm-Message-State: AOAM5300Gfk/jYIrn5A20vfWvnhKontJu9b0mHPL2SOAC1ILiBAu1SmW pEd7BGPkiAaplNGhl8Ek5cAD3NGlO8VGJgOmbh7puA== X-Google-Smtp-Source: ABdhPJyv5tZaN1/BR0yTx3rW8Qs9sAFAxvDGxN+ReR0kkgY2YzCaJCyRCM45G+Hg4OjaHfiHcP5hdRD0nMrfG4PRCuA= X-Received: by 2002:a92:c0c8:: with SMTP id t8mr1748185ilf.229.1594852525580; Wed, 15 Jul 2020 15:35:25 -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: Caroline Tice Date: Wed, 15 Jul 2020 15:35:14 -0700 Message-ID: Subject: Re: [PATCH V5] Fix issues with reading rnglists, especially from dwo files, for DWARF v5 To: "H.J. Lu" Cc: Simon Marchi , Eric Christopher , Tom Tromey , Caroline Tice via Gdb-patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-19.5 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: Wed, 15 Jul 2020 22:35:27 -0000 Thank you for that suggestion! It turns out that I CAN create the .o file with clang, then use that for the basis of my test; linking it with GCC works and gives the results I expect (it fails with ToT GDB , but passes with my patch). In order to make this work, however, I have to make a small change to gdb/testsuite/lib/gdb.exp (in build_executable_from_specs, I have to check to see if the source file is already an object file before trying to compile it into an object file, and if it is an object file, copy it into the proper directory)l Should I add that (and the .o version of the test case) to this patch, or should I make it a separate patch? If the latter (which is what feels right to me), then if this patch can receive final approval (and someone can commit it, as I do not have write privileges to the GDB code base), then I will submit the subsequent patch to replace the current test with the .o version and update gdb/testsuite/lib/gdb.exp to make it work. -- Caroline cmtice@google.com On Wed, Jul 15, 2020 at 10:05 AM H.J. Lu wrote: > > 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.