From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id iYzuFMb8EmAvewAAWB0awg (envelope-from ) for ; Thu, 28 Jan 2021 13:04:54 -0500 Received: by simark.ca (Postfix, from userid 112) id 465151EF80; Thu, 28 Jan 2021 13:04:54 -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 E8F2B1E945 for ; Thu, 28 Jan 2021 13:04:53 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7EAA9383443C; Thu, 28 Jan 2021 18:04:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7EAA9383443C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1611857093; bh=PjGxsZMDioZ+ISOLRISaHCYYW5DFPu1f9IPPekkwuOQ=; 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=Iyruofr9lB/AF+xtD0gaIAfQUJj+tOLrNasIesdOmdc9/Wa7cBrmst3a+yV15+MOJ eked094btwq0e2k8ePh7bWvlPlSmo/3+gYYb/LraydV1temSeUvoniKRQqiT+vxbgD 2ay8TenhqacSfRfluvGGFiEj5JDL+Mt5Tlgk6FaI= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 9B7DD398EC08 for ; Thu, 28 Jan 2021 18:04:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9B7DD398EC08 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 10SI4jac027138 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Jan 2021 13:04:49 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 10SI4jac027138 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 045641E945; Thu, 28 Jan 2021 13:04:44 -0500 (EST) Subject: Re: [PATCH][gdb/testsuite] Fix gdb.opt/solib-intra-step.exp with -m32 and gcc-10 To: Tom de Vries , gdb-patches@sourceware.org References: <20210126180312.GA7860@delia> <8713098d-e196-bf9d-3b8f-a8d2920e7caa@suse.de> Message-ID: Date: Thu, 28 Jan 2021 13:04:44 -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: <8713098d-e196-bf9d-3b8f-a8d2920e7caa@suse.de> 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 18:04:45 +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" >>> @@ -89,7 +89,7 @@ gdb_test_multiple "step" $test { >>> exp_continue >>> } >>> -re -wrap "get_pc_thunk.*" { >>> - if { $state != 1 } { >>> + if { $state != 0 && $state != 1 } { >>> set state -1 >>> } else { >>> set state 2 >>> >> >> I don't really understand what happens here, what state value means what. >> >> A bit of commenting would help. > > I tried to add comments but didn't manage to come up with something > sensible. > > Instead, I simplified gdb_test_multiple to just track the order of > events, and then added a few asserts about order of events. > > I hope this clarifies what the test is trying to do. WDYT? Hmm, it's still not clear to me what the intention of the test is. It's not clear what kind of good or bad behavior from GDB we are looking for. That intention needs to be recorded in a comment, otherwise, I can't tell if the code matches what we want (since I don't know what we want). I kind of understand now that we do a step, we want to get until the "first-hit" line (or "second-hit" in the second case), but it's possible that we land on intermediary states, which are acceptable. But there also seems to be an ordering component? Why is that important? Why don't we simply "exp_continue" when seeing "retry" or "get_pc_thunk", why bother recording anything? Simon