From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111498 invoked by alias); 31 Dec 2019 17:37:19 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 111490 invoked by uid 89); 31 Dec 2019 17:37:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=George, H*r:10.0.0, george, achieved X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 31 Dec 2019 17:37:18 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 0FA621E50B; Tue, 31 Dec 2019 12:37:16 -0500 (EST) Subject: Re: [PATCH] Fix handling of null stap semaphores To: George Barrett Cc: gdb-patches@sourceware.org References: <5we87igzwt5_kr.5b-38floyexzwmozuj6vb-.hmx8r4u3r41_sy@mail.bob131.so> <63-043i577lrr0nz3p9q-864io50kubhf/q6&oul1hzd/xh4.u6c@mail.bob131.so> <825af859-3594-5e29-9921-822f4193750a@simark.ca> <9rhhdg5t27f6viytriu_m1zufab3j6qfbalt3izvvhcvmzp2bhad@mail.bob131.so> From: Simon Marchi Message-ID: <55c5578c-5b24-6987-9b8d-46a40ac36587@simark.ca> Date: Tue, 31 Dec 2019 17:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <9rhhdg5t27f6viytriu_m1zufab3j6qfbalt3izvvhcvmzp2bhad@mail.bob131.so> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-12/txt/msg01082.txt.bz2 On 2019-12-30 11:39 p.m., George Barrett wrote: > On Mon, Dec 30, 2019 at 12:59:30PM -0500, Simon Marchi wrote: >> Yeah, I know writing a test case is not the most fun part, but it pays in >> the long run. I can help if you are not familiar enough with >> tcl/expect/dejagnu. > > I can stumble through enough to get something ready for review, but there is > a bit of a hiccup I wanted some advice on: the testing strategy you outlined > hinges on prepare_for_testing producing PIC executables, but AFAICS this is > neither done by default nor can I find a facility in the test suite utilities > to achieve this. Is adding -pie/-fPIC to additional_flags acceptable in this > instance? If nothing else is specified, the testsuite produces executables with the default settings of the toolchain. If, for a test, you need to force creating a PIE or a non-PIE, you can pass these flags to gdb_compile & al: - pie: Force creation of PIE executables. - nopie: Prevent creation of PIE executables. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/testsuite/lib/gdb.exp;h=8b1ec62c9c21570f3d3cb4c9d3fa0bdce016876e;hb=HEAD#l3686 If there are some differences in how PIE and non-PIE are handled, it can be good to run the test with both. This can be achieved relatively easily with a: foreach_with_prefix pie { "nopie" "pie" } { ... } Here's an example: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/testsuite/gdb.base/break-idempotent.exp;h=96f91c50f906955b289b7ee7dfd65dc7c375e79a;hb=HEAD#l149 > On a related note, I was a bit surprised to discover that the test case > doesn't actually ever define USE_PROBES since the argument provided to > stap_test(_no_debuginfo) is `-DUSE_PROBES' instead of > `additional_flags=-DUSE_PROBES'. This seems like a trivial enough fix to be > rolled into a single commit, but I was thinking that the fix wouldn't be > particularly evident from the diff if the -pie flags were added in the same > patch. Would this be worth splitting into an independent patch? Yes, totally, a separate patch (ideally before, in the same series) would be perfect. This shows that the test is written in a poor way, it does not appear to actually test anything related to semaphores. At least, I think it should parse the output of "info probes" and expect an hexadecimal number for the semaphore address. Good catch, btw. Also, shouldn't it be called USE_SEMAPHORES and not USE_PROBES? Thanks for looking into this. Simon