From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26598 invoked by alias); 30 Aug 2018 00:22:03 -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 26583 invoked by uid 89); 30 Aug 2018 00:22:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HX-Received:1456, HX-Received:sk:83-v6mr X-HELO: mail-pf1-f196.google.com Received: from mail-pf1-f196.google.com (HELO mail-pf1-f196.google.com) (209.85.210.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 Aug 2018 00:22:01 +0000 Received: by mail-pf1-f196.google.com with SMTP id d4-v6so3044800pfn.0 for ; Wed, 29 Aug 2018 17:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=e+1pii2F9JxBDyWiLEwqaZPkisyPt63hZers7rlw5hg=; b=LH31hBFE5r/yhjh5pXSHQaMglKmpRdgpWZ4ma6rVzNuRC6mirCecIXKI6ux2DaTmU9 8iWV54M3zR2V8g3VGiFZaZKTC0VPECZFJrnijCBJag315ok5C7PIsiBvydc3m6zAknTi zLplecNq8sO90oX4mVvqfztubBhmf7uZ+sUMfon+Y4gF/bG/iTlYhf2I4hbwHfXsvdCB RPbPYmeYGsxrlPsb30V25DpMxNvwFYOlgnqRk3oVh3/dawLGPE/MTKWU0fkQj2xk/BPZ eq+8amrMtqTJsGv52kMtSJ7GOlpp//UaeJhOdN8L6rH/OP6VAulv3/r3LGcdwqdSVpht DVpQ== Return-Path: Received: from localhost ([12.206.222.5]) by smtp.gmail.com with ESMTPSA id a2-v6sm6139120pgc.68.2018.08.29.17.21.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Aug 2018 17:21:58 -0700 (PDT) Date: Thu, 30 Aug 2018 00:22:00 -0000 X-Google-Original-Date: Wed, 29 Aug 2018 17:07:25 PDT (-0700) Subject: Re: [PATCH] gdb: Ensure compiler doesn't optimise variable out in test In-Reply-To: <20180829180259.2718-1-andrew.burgess@embecosm.com> CC: gdb-patches@sourceware.org, andrew.burgess@embecosm.com From: Palmer Dabbelt To: andrew.burgess@embecosm.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2018-08/txt/msg00791.txt.bz2 On Wed, 29 Aug 2018 11:02:59 PDT (-0700), andrew.burgess@embecosm.com wrote: > In the test gdb.base/funcargs.exp, there's this function: > > void recurse (SVAL a, int depth) > { > a.s = a.i = a.l = --depth; > if (depth == 0) > hitbottom (); > else > recurse (a, depth); > } > > The test script places a breakpoint in hitbottom, and runs the > executable which calls recurse with an initial depth of 4. > > When GDB hits the breakpoint in hitbottom the testscript performs a > backtrace, and examines 'a' at each level. > > The problem is that 'a' is not live after either the call to > 'hitbottom' or the call to 'recurse', and as a result the test fails. > > In the particular case I was looking at GCC for RISC-V 32-bit, the > variable 'a' is on the stack and GCC selects the register $ra (the > return address register) to hold the pointer to 'a'. This is fine, > because, by the time the $ra register is needed to hold a return > address (calling hitbottom or recurse) then 'a' is dead. > > In this patch I propose that a use of 'a' is added after the calls to > hitbottom and recurse, this should cause the compiler to keep 'a' > around, which should ensure GDB can find it. > > gdb/testsuite/ChangeLog: > > * gdb.base/funcargs.c (use_a): New function. > (recurse): Call use_a. > --- > gdb/testsuite/ChangeLog | 5 +++++ > gdb/testsuite/gdb.base/funcargs.c | 7 +++++++ > 2 files changed, 12 insertions(+) > > diff --git a/gdb/testsuite/gdb.base/funcargs.c b/gdb/testsuite/gdb.base/funcargs.c > index 600792f0a7e..515631f5491 100644 > --- a/gdb/testsuite/gdb.base/funcargs.c > +++ b/gdb/testsuite/gdb.base/funcargs.c > @@ -424,6 +424,10 @@ void hitbottom () > { > } > > +void use_a (SVAL a) > +{ > +} > + > void recurse (SVAL a, int depth) > { > a.s = a.i = a.l = --depth; > @@ -431,6 +435,9 @@ void recurse (SVAL a, int depth) > hitbottom (); > else > recurse (a, depth); > + > + /* Ensure A is not discarded after the above calls. */ > + use_a (a); > } > > void test_struct_args () Isn't the compiler still free to kill "a" here because it can see into use_a() and therefor inline it? I'd expected it to choose to inline use_a(), as doing nothing is always cheaper than calling a function.