From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id E77FE3858D38 for ; Thu, 16 Jul 2020 02:35:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E77FE3858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca 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)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id E62F21E5F9; Wed, 15 Jul 2020 22:35:00 -0400 (EDT) Subject: Re: [PATCH V5] Fix issues with reading rnglists, especially from dwo files, for DWARF v5 To: Caroline Tice , "H.J. Lu" Cc: Eric Christopher , Tom Tromey , Caroline Tice via Gdb-patches References: <5eab18a1-c7e9-1a77-7f65-944eea10aa85@simark.ca> <5ccfe911-6049-e8f3-4874-9991b2649512@simark.ca> <4da310be-fa9f-9f21-8988-81af58ec73e3@simark.ca> From: Simon Marchi Message-ID: Date: Wed, 15 Jul 2020 22:34:58 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_NUMSUBJECT, SPF_HELO_PASS, 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: Thu, 16 Jul 2020 02:35:04 -0000 On 2020-07-15 6:35 p.m., Caroline Tice wrote: > 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. I'd be fine merging the patch with the current test and keep working on improving the test coverage. I think that we'll need indeed need to do a bit of infrastructure work to improve the testing of DWARF5 in general. Can you please provide a final patch version where you mention in the commit message how to run the test in order to provoke a failure. Please make sure to include the compiler version as well (output of `clang --version`) because, as you said, the code compilers output changes with time. So in order to be able to reproduce the failure, it would be useful to know the compiler version. I'm not sure what you mean by "the .o version of the test case". Do you mean check-in the .o in the git repository? We currently don't check in binary test artifacts for GDB. However, I'm of the opinion that it could be useful sometimes (like here). But we'd need to have a discussion about this first, how we want to do that, which guidelines to follow. About this comment, in your other message: > 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. Just wondering, doesn't gcc emit at least *some* DWARF 5 by now? If so, can't the GNU assembler deal with it? Simon