From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0IR0OnXTEmC3cwAAWB0awg (envelope-from ) for ; Thu, 28 Jan 2021 10:08:37 -0500 Received: by simark.ca (Postfix, from userid 112) id DEEF11EF80; Thu, 28 Jan 2021 10:08:37 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 8D98D1E945 for ; Thu, 28 Jan 2021 10:08:37 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 403F63850422; Thu, 28 Jan 2021 15:08:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 403F63850422 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1611846517; bh=J6YrKrvy8CsLXpt9crKA1+V5S75GURDmdLEugV/Exig=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=sCJFtTvvd95Ks57yqpARra2Aoay3vSiboXVeLmOt8FG3/NFqU4ZGRxqb2v7Vns7G7 PQzhFHA9sLb8x40uOMpGaCGZv4OwaapZCVXNa2FC3bxqVJByNp+Ni8fldBzhChb8j7 0x6AHneMY+Iicw/0CRcvHtaFlg6m5S8DjytKV9Ys= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id A84A83851416 for ; Thu, 28 Jan 2021 15:08:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A84A83851416 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 10SF8UYm010469 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Jan 2021 10:08:34 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 10SF8UYm010469 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (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 19D8C1E945; Thu, 28 Jan 2021 10:08:30 -0500 (EST) Subject: Re: [PATCH][gdb/testsuite] Fix gdb.arch/i386-gnu-cfi.exp To: Tom de Vries , gdb-patches@sourceware.org References: <20210126180411.GA7951@delia> Message-ID: <77788279-b609-82f7-e39f-02fbd3e8542a@polymtl.ca> Date: Thu, 28 Jan 2021 10:08:29 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <20210126180411.GA7951@delia> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Thu, 28 Jan 2021 15:08:30 +0000 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2021-01-26 1:04 p.m., Tom de Vries wrote: > Hi, > > When running test-case gdb.arch/i386-gnu-cfi.exp with target board unix/-m32, I get: > ... > (gdb) up 3^M > 79 abort.c: No such file or directory.^M > (gdb) FAIL: gdb.arch/i386-gnu-cfi.exp: shift up to the modified frame > ... > > The preceding backtrace looks like this: > ... > (gdb) bt^M > #0 0xf7fcf549 in __kernel_vsyscall ()^M > #1 0xf7ce8896 in __libc_signal_restore_set (set=0xffffc3bc) at \ > ../sysdeps/unix/sysv/linux/internal-signals.h:104^M > #2 __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:47^M > #3 0xf7cd0314 in __GI_abort () at abort.c:79^M > #4 0x0804919f in gate (gate=0x8049040 , data=0x0) at gate.c:3^M > #5 0x08049176 in main () at i386-gnu-cfi.c:27^M > ... > with function gate at position #4, while on another system where the test passes, > I see instead: > ... > (gdb) PASS: gdb.arch/i386-gnu-cfi.exp: continue to abort() > backtrace^M > (gdb) PASS: gdb.arch/i386-gnu-cfi.exp: backtrace > ... > function gate at position #3. > > Fix this by capturing the position of function gate in the backtrace, and > using that in the rest of the test instead of hardcoded constant 3. > > Tested on x86_64-linux. > > Any comments? > > Thanks, > - Tom > > [gdb/testsuite] Fix gdb.arch/i386-gnu-cfi.exp > > gdb/testsuite/ChangeLog: > > 2021-01-26 Tom de Vries > > * gdb.arch/i386-gnu-cfi.exp: Capturing the position of function gate > in the backtrace, and use that in the rest of the test instead of > hardcoded constant 3. > > --- > gdb/testsuite/gdb.arch/i386-gnu-cfi.exp | 22 +++++++++++++++++----- > 1 file changed, 17 insertions(+), 5 deletions(-) > > diff --git a/gdb/testsuite/gdb.arch/i386-gnu-cfi.exp b/gdb/testsuite/gdb.arch/i386-gnu-cfi.exp > index 4228140fc35..8f6fbb8bf44 100644 > --- a/gdb/testsuite/gdb.arch/i386-gnu-cfi.exp > +++ b/gdb/testsuite/gdb.arch/i386-gnu-cfi.exp > @@ -60,19 +60,31 @@ gdb_test_multiple {} "continue to abort()" { > > # Backtrace would crash before. > > -gdb_test "bt" \ > - "main \\(\\) at .*${testfile}.c.*" \ > - "backtrace" > +set gate_n "" > +set backtrace_re \ > + [multi_line \ > + "" \ > + "#($decimal) *$hex in gate \[^\r\n\]*" \ > + "#$decimal *$hex in main \\(\\) at .*${testfile}.c.*"] > +gdb_test_multiple "backtrace" "" { > + -re -wrap $backtrace_re { > + set gate_n $expect_out(1,string) > + pass $gdb_test_name > + } > +} Please add a comment above this describing the intent, finding the frame number for function "gate". > +if { $gate_n == "" } { > + return -1 > +} > > # Check we see the inserted `DW_CFA_GNU_negative_offset_extended' CFI. > # We see there the original CFI-stored filename `gate.c'. > > -gdb_test "up 3" \ > +gdb_test "up $gate_n" \ > "gate \\(\[^()\]*\\) at .*gate.c.*" \ > "shift up to the modified frame" Since $gate_n is the frame number, perhaps use the "frame" command instead? It still works with "up" because frame #0 is initially selected, but using "frame" would be more robust. Otherwise, LGTM. Simon