From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by sourceware.org (Postfix) with ESMTPS id 6393C385700D for ; Wed, 15 Jul 2020 16:57:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6393C385700D Received: by mail-wm1-x343.google.com with SMTP id f139so6494814wmf.5 for ; Wed, 15 Jul 2020 09:57:47 -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=QG8qD1wuiXM092KUEJWHIih2O2bARqiFDjy/3DUIhfM=; b=eXzaVl2LZqIh39OJE9XpGRXlZN3JzqWQ5mN6m5R5WELXPZmPDT8PDTsSgexKhn9RLa m4EEFfA0FdGbG7ewilBMNR7BVR1UanNMbAK8EeeJlzyfSYwbbWirKw7enRzUUxjzpZdw nluje/wrcLUiidQsI1NsURJ8RAiFyFpj7VsRsfrURPUKEYfbYPvArjMNm5jXUmzmiYeS XCFzTctjjetYPxztDTUAT8YHTUn8gz9aqxzWzv8dSAUcKjZwxEDcMHjMH1zWmDNxhNtt 0gBuzPgXnO2Dnq0RF5c8CWVVBUQ+CzPHHeVbxVgxiQSuWDy+JZzKx33FNySFIATf1Yc1 n6sg== X-Gm-Message-State: AOAM530oky6ZDQMV+QYFVdlKAwcvUe5yZRBB9DooAxlrsjm6DMovYBDT B7CtNbYKDqVJ2vfF4Kh47aR3Cba3wTy6htETvTsR4A== X-Google-Smtp-Source: ABdhPJz8PE5othRno/5T1+qirJ6G7WvSLz1WIXY19lbFHefj/WmC1XyDHT4ib/pWWqBoD7ggIFlHBSw5vdu20Z8WKzE= X-Received: by 2002:a1c:1fd1:: with SMTP id f200mr355783wmf.162.1594832266176; Wed, 15 Jul 2020 09:57:46 -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 09:57:33 -0700 Message-ID: Subject: Re: [PATCH V5] Fix issues with reading rnglists, especially from dwo files, for DWARF v5 To: Simon Marchi Cc: Eric Christopher , Tom Tromey , Caroline Tice via Gdb-patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.4 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 16:57:48 -0000 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. So I'm not sure what else I can do at this point,. -- Caroline Tice cmtice@google.com >