From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 251543858D28 for ; Tue, 24 Jan 2023 15:53:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 251543858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 1FBDD1FEB8; Tue, 24 Jan 2023 15:53:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1674575584; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Bx6q4iyZKILJ9kXOiaKRESdUdKPcwOXH1+Oa1SVD9uw=; b=E/hCx3hflS9Y0BNmjTZUWJAjOFK/TOMjmpvCSYnTq4pSN2Ok7ymGAqyIULu886/6CR2WqP my806eZXsv/LCZzaFQsHA1GeBbpWQVl90/wAb/U1r2jFbwBwq+ARcCU1Ne5bas2hXsBpcr vIP9u1WYeG5Z/EBbdyctYbCtT/k+aks= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1674575584; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Bx6q4iyZKILJ9kXOiaKRESdUdKPcwOXH1+Oa1SVD9uw=; b=SH6A6lQMBoFi5bT5aMYvkvUZBW8GMkFHOiVRsYo5N5uwWDZWdLXj/bvaxx5cD6DxOzFVYq hUPWslyviz8SvLBA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id EB05D13487; Tue, 24 Jan 2023 15:53:03 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id uUkrON/+z2MpNgAAMHmgww (envelope-from ); Tue, 24 Jan 2023 15:53:03 +0000 Message-ID: Date: Tue, 24 Jan 2023 16:53:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH 1/2 version 3] fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp Content-Language: en-US To: Pedro Alves , Carl Love , Bruno Larsen , Ulrich Weigand , "will_schmidt@vnet.ibm.com" , gdb-patches@sourceware.org References: <50474aa92ba82eff05cdc8f49001eae56be29670.camel@us.ibm.com> <89331c26795e3f7743e1e068dce43b3c2dd53008.camel@us.ibm.com> <071f24ecf9b3a2bbbe8fee7db77492eb55c5f3ff.camel@us.ibm.com> <1d9b21914354bef6a290ac30673741e722e11757.camel@de.ibm.com> <3e3c9c40f07ab01c79fe10915e76ffa187c42ad9.camel@us.ibm.com> <122f5d2d3db9ef1979b0f8da927d005f32bba82c.camel@us.ibm.com> <011768e8-2b76-f8ed-1174-fbaa020b15e7@redhat.com> <58cebd1a-7883-fbc6-ac94-c67293f8fc8d@redhat.com> <5e5dc4a49aa8feb370419a1efecf277673b7dfc7.camel@us.ibm.com> From: Tom de Vries In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_MANYTO,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 1/23/23 20:17, Pedro Alves wrote: > I'd think this was on purpose. Note that next/step/reverse-{next/step} are line-oriented > stepping commands, they step/next until the previous/next line. While "finish" is described > as undoing the_function call_. > > The manual says: > > reverse-finish > Just as the finish command takes you to the point where the current function returns, > reverse-finish takes you to the point where it was called. Instead of ending up at the end of > the current function invocation, you end up at the beginning. As well as: ... finish Continue running until just after function in the selected stack frame returns. Print the returned value (if any). This command can be abbreviated as fin. ... It's only now that you mention the non-line nature of finish/reverse-finish that I realize that that is the case. So I suppose the docs could be a bit more explicit about this aspect. I suppose an intuitive way to make available the two approaches (so without the user losing options) would be to introduce finishi next to finish and reverse-finishi next to finish, with the new commands retaining the current functionality and the old ones being adjusted to respect line boundaries. But having the commands change behaviour is likely to cause confusion (well, assuming users notice the difference in the first place), so I'm not sure if that's a good idea. Thanks, - Tom