From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by sourceware.org (Postfix) with ESMTPS id 2CF373857C63 for ; Thu, 16 Jul 2020 18:29:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2CF373857C63 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wr1-x443.google.com with SMTP id z2so8125307wrp.2 for ; Thu, 16 Jul 2020 11:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=9WCeMmjVrpTyHnVRWeFEKY/Z7LpXuctPPB1whfIGjp4=; b=dpomkTH6DBQ1Imr3E9eho+hWvfmeJzhUPniN9Tbk8q2gC2HVzs5db/tK0GgR+KGTm6 MRpbWA+pfIaW8643JAlqb5rgPfCDV9yL6RvlDaOVfcTgnHipYXJyDBDxhdcSp7dqkjF2 gTqc0bd0FdosVNoaE9wl5RQpj6aaeH9e9dM33AMrZCCK+gxo8te3d/v5F+TcxVwLqW/T yX7IAja64JKyxYW0ouydPvwAOJJdVTs1xq/vrzKb+AfBQjfLQBQ49T3EGU73YZJExpXR MRxJj++S5q5b9r2+I9gRvRH4Jl6CfAb3BxrBH8HZjmp4/g9ZYQn0lUfYtpCAzD0fK6MK XGhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=9WCeMmjVrpTyHnVRWeFEKY/Z7LpXuctPPB1whfIGjp4=; b=fKcxlIgrX/xAriKDUC01oZ2x1D0e5AgBW50B88/vVbR6U9maeiPGg83ATIa4MBRM4C /LhdJHYYRVdeTZ3oQJ3kDrghN9ELSzRx4IzMVldFFfQXkDpgOmCkBHB83EMwhEeR3Nwa SW34Z6qJgXJ3OsgQ+I1hPG+bcWH/2Ul4e4EYEUQMElqQ3bjHt3W0F7OggharEkWhA02a TCFUAFSdcv32qj98CMx0UlwCp5g9oRQGMUEHwq314Y7fWJDBQ+W6fRWZW3F9Cos2rd9r 89f26j1t/YjJR8j89BpWQgwoYCjxPnma0ZsfY4cSsuG5chpBlcDvMYart7rEc0TTcUhE lOGQ== X-Gm-Message-State: AOAM532OGjpOqPrRgV83rzLweMqm0PtC6nlYWAWmlw8YF6QDAHjMkHds YJz6O9EJDc6m9HYPVgNgG0ZTHA== X-Google-Smtp-Source: ABdhPJxnUe45Dj9LFM9ROTuyZ3VFfyBv8VL28MHT94op3uu3DEiW+OZ/i9YPyyuaiLkj/4NGBCJgQA== X-Received: by 2002:a5d:4d8b:: with SMTP id b11mr6265411wru.341.1594924182162; Thu, 16 Jul 2020 11:29:42 -0700 (PDT) Received: from localhost (host86-128-12-23.range86-128.btcentralplus.com. [86.128.12.23]) by smtp.gmail.com with ESMTPSA id d13sm10064815wrq.89.2020.07.16.11.29.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jul 2020 11:29:41 -0700 (PDT) Date: Thu, 16 Jul 2020 19:29:40 +0100 From: Andrew Burgess To: Caroline Tice Cc: Caroline Tice via Gdb-patches , Eric Christopher , Tom Tromey , Simon Marchi Subject: Re: [PATCH] Update testsuite mechanism to allow object files as source files. Message-ID: <20200716182940.GH2737@embecosm.com> References: <20200716172149.GG2737@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux/5.6.15-200.fc31.x86_64 (x86_64) X-Uptime: 19:21:25 up 38 days, 8:28, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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 18:29:44 -0000 * Caroline Tice [2020-07-16 11:07:39 -0700]: > This text, extracted from my detailed explanation, DOES explain (I > thought) why the existing DWARF assembler can't be used: > > > > A further twist is that > > > the GNU assembler currently chokes on DWARF v5 .debug_line sections, because > > > they start their file index at 0 instead of 1, and the GNU assembler has not > > > been updated to handle this. This is not a problem for > > > assembly files generated by GCC, because GCC generates DWARF v3 > > > .debug_line sections, even when passed -gdwarf-5. Clang on the other hand, > > > when passed -gdwarf-5, generates DWARF v5 .debug_line tables. So using a > > > clang-generated .s file for the test is not an option, because the GNU > > > assembler chokes on it. But GDB's DWARF assembler (gdb/testsuite/lib/dwarf.exp) just generates .byte/.word/etc? I don't see why there would be any problems extending this to cover the features you'd want (again, I say this without actually looking at your example test). It seems like the text above would apply to the GNU assembler trying to assemble .file directives as generated by a compiler. Also, on further reflection, we already have tests like: gdb/testsuite/gdb.arch/amd64-entry-value-param-dwarf5.S where the DWARF has been compiled down to a raw assembler file. Given that, as has already been pointed out, any object file is going to be architecture and maybe even OS specific anyway, there doesn't appear to be much (any?) difference between adding object files into the testsuite and just adding the test as a raw assembler file. Have you considered this approach? Thanks, Andrew > > -- Caroline > cmtice@google.com > > On Thu, Jul 16, 2020 at 10:21 AM Andrew Burgess > wrote: > > > > * Caroline Tice via Gdb-patches [2020-07-16 09:50:36 -0700]: > > > > > Since this patch will be resulting in something of a policy change, I > > > expect there will be a fair > > > amount of discussion around it. > > > > > > High level summary: > > > In some (hopefully rare) cases, certain tests MUST be built with a > > > particular compiler to work. If that compiler is not GCC, then it > > > makes it very burdensome for developers to run the GDB testsuite and > > > test those tests. This change allows those tests to use object files > > > (generated by the required compiler) as the test source file, so that > > > when the test suite is run with GCC those tests will still > > > execute/test properly. > > > > > > Details: > > > This change is motivated by the fact that clang and GCC sometimes generate > > > different output, which affects whether or not a test works properly. The > > > particular motivating example is the gdb.dwarf2/dw5-rnglist-test.exp test, > > > which tests whether or not GDB is properly reading/handling DWARF v5 > > > DW_AT_ranges of the form DW_FORM_rnglistx in lexical block dies. GCC does > > > not generate that code, so compiling the test with GCC does not successfully > > > test anything. Clang does generate that code, so the only way to properly > > > test this is to compile the test case with clang. A further twist is that > > > the GNU assembler currently chokes on DWARF v5 .debug_line sections, because > > > they start their file index at 0 instead of 1, and the GNU assembler has not > > > been updated to handle this. This is not a problem for > > > assembly files generated by GCC, because GCC generates DWARF v3 > > > .debug_line sections, even when passed -gdwarf-5. Clang on the other hand, > > > when passed -gdwarf-5, generates DWARF v5 .debug_line tables. So using a > > > clang-generated .s file for the test is not an option, because the GNU > > > assembler chokes on it. > > > > > > This patch updates lib/gdb.exp to allow it to properly handle test > > > cases where the source file is in fact an object file, and it updates > > > the dw5-rnglist-test to use an object file rather than the .cc file. This > > > in turn makes the test itself compiler-agnostic. > > > > I haven't looked at this particular test, but I think any > > justification for this change, especially when the example you cite is > > about different DWARF, should include an explanation about why the > > existing DWARF assembler can't be used in this case. > > > > Thanks, > > Andrew > > > > > > > > > > > -- Caroline Tice > > > cmtice@google.com > > > > > > gdb/testsuite/ChangeLog > > > > > > 2020-07-16 Caroline Tice > > > > > > * lib/gdb.exp (build_executable_from_specs): Create output_dir > > > variable from call to standard_output_file; update code that > > > compiles source files to object files and copies them to output > > > directory, to check first and make sure they are not already > > > object file. If they are already object files, just copy them to > > > output directory. > > > * gdb.dwarf2/dw5-rnglist-test.o: New file (object file) > > > * gdb.dwarf2/dw5-rnglist-test.exp: Update to use .o file rather than > > > .cc file; this removes the dependency of this test on clang and > > > allows it to work with GCC as well. > > > >