From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 2B2D53858D1E for ; Tue, 24 Jan 2023 14:23:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2B2D53858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674570198; h=from:from:reply-to:subject:subject: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=nfykpWFo/8WIhtlI4ehQQC1YpM6VX5SiZqA4cZy/+fA=; b=Nth0p0WYHtimeWP82i3+JLzOhACLXPWU/ek/eJyH4qNEArjkJ/Meg3smUUr9aBd+6W8sE4 84uW95Q11i1m4NBAjJzUifwPbC9S6DuUDqY6hA93SWoRR4w8WqBugPTZKpH+W7qlKLtaCy ucNlqETcpFQmoFnX4S414XlJSsxUPag= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-428-TKAlUVHrMjO7gtx3htDYxA-1; Tue, 24 Jan 2023 09:23:17 -0500 X-MC-Unique: TKAlUVHrMjO7gtx3htDYxA-1 Received: by mail-ed1-f71.google.com with SMTP id z18-20020a05640235d200b0049d84165065so10842245edc.18 for ; Tue, 24 Jan 2023 06:23:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nfykpWFo/8WIhtlI4ehQQC1YpM6VX5SiZqA4cZy/+fA=; b=IXyElQkghdFg4yITWK/LDe4XSr4NHBWyNiZxT5mhHfISOg+/jSHVOLxD7AXBowSMKS RsplFH2wT8SlpV34nkMQH5v4XTFW0gVzivsYsVsBUr5IL9oqX6hsUVkUprqG7OL8MKHR nWXBMZ6dLpGJKLL4HbH4xR+zAog1hTi0ndbrzDB87q9SpUQTTkXuqvqCP6cfnvt206PK pyf00aM4jJfpGAqFH9ooyh55/zbbDGEjwY5QefA9UhCuZm3RbLA/hSwRe7IFjn1zrFZQ bmrd+6wFP9aoFPCFS1XRqqPTxHRLQ57SF9E8tNhSIlQ9cgaWTd+CtQ9x/FBAjm1f1mD+ S+GA== X-Gm-Message-State: AFqh2krkVK2cja0ftlqYAWk3TLLy+UeiBczaAnVL7oFiQComvf3gECzU i0PqyP7IYqh/V0D6a6gqgcTzd8jrEK4ES6Ovi9mUZYCtHtNvK6CGLJ7tAFTZ9JShSBWyh8Y7zO4 tcLC+iJNfUdZcJK003IUnag== X-Received: by 2002:a05:6402:2906:b0:499:c294:77b6 with SMTP id ee6-20020a056402290600b00499c29477b6mr29712727edb.9.1674570195774; Tue, 24 Jan 2023 06:23:15 -0800 (PST) X-Google-Smtp-Source: AMrXdXvkK+3jDIKnDQP6yzVrMz7ApjMWZyhqbaadEFwqEAdXh/IkdgyuFNSvq4Zwhw0yjTPc6CyJnQ== X-Received: by 2002:a05:6402:2906:b0:499:c294:77b6 with SMTP id ee6-20020a056402290600b00499c29477b6mr29712712edb.9.1674570195463; Tue, 24 Jan 2023 06:23:15 -0800 (PST) Received: from [192.168.0.45] (ip-62-245-66-121.bb.vodafone.cz. [62.245.66.121]) by smtp.gmail.com with ESMTPSA id a10-20020aa7d74a000000b004a09015497dsm299236eds.49.2023.01.24.06.23.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Jan 2023 06:23:14 -0800 (PST) Message-ID: <8c4ebc33-f7b5-14a3-3bb0-155fe03e92d8@redhat.com> Date: Tue, 24 Jan 2023 15:23:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH 1/2 version 3] fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp To: Pedro Alves , Carl Love , Ulrich Weigand , "will_schmidt@vnet.ibm.com" , gdb-patches@sourceware.org References: <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> <610d5f171d5f4baeb94887217e69d0e6d70e9d66.camel@us.ibm.com> <873eb58a-a6ab-08b2-0827-ca6e0c8088ae@palves.net> From: Bruno Larsen In-Reply-To: <873eb58a-a6ab-08b2-0827-ca6e0c8088ae@palves.net> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no 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 24/01/2023 15:08, Pedro Alves wrote: > On 2023-01-23 9:13 p.m., Carl Love wrote: >> Pedro: >> >> On Mon, 2023-01-23 at 19:17 +0000, Pedro Alves wrote: >>>> Currently on X86, when executing the finish command in reverse, gdb >>>> does a >>>> single step from the first instruction in the callee to get back to >>>> the >>>> caller. GDB stops on the last instruction in the source code line >>>> where >>>> the call was made. When stopped at the last instruction of the >>>> source code >>>> line, a reverse next or step command will stop at the first >>>> instruction >>>> of the same source code line thus requiring two step/next commands >>>> to >>>> reach the previous source code line. It should only require one >>>> step/next >>>> command to reach the previous source code line. >>>> >>>> By contrast, a reverse next or step command from the first line in >>>> a >>>> function stops at the first instruction in the source code line >>>> where the >>>> call was made. >>> 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. >>> >>> Say you have a line with multiple statements involving multiple >>> function calls. >>> The simplest would be: >>> >>> func1 (); func2 (); >>> >>> Say you'd stopped inside 'func2'. If you do finish there, in current >>> master gdb >>> stops at the call to 'func2', and you can then decide to reverse step >>> into 'func1'. >> I don't think you followed the issue. > Totally possible! > >> So, if you are in func2 and do a reverse-finish, without the patch gdb >> stops on the last instruction for the line that calls func2. > Right. > >> Now if >> you issue a reverse-step, you stop at the first instruction for the >> call to func2, i.e. you are still on the same source code line. > Wait. That right there sounds bogus. The source line looks like: > > func1 (); func2 (); > > so stepping backwards over that line should always stop at the first > instruction of the line, not in the middle. Let's simplify this. > > Here's the full source code of my example: > > (gdb) list 1 > 1 void func1 () > 2 { > 3 } > 4 > 5 void func2 () > 6 { > 7 } > 8 > 9 int main () > 10 { > 11 func1 (); func2 (); > 12 } > I think you are describing a different issue to what Carl is trying to solve. Using your example code, I have the following debugging session: $ ./gdb -q reverse Reading symbols from reverse... (gdb) start Temporary breakpoint 1 at 0x401118: file t.c, line 8. Starting program: /home/blarsen/Documents/build/gdb/reverse [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Temporary breakpoint 1, main () at t.c:8 8           func1(); func2(); (gdb) record (gdb) n 9       } (gdb) rs func2 () at t.c:5 5       } (gdb) reverse-finish Run back to call of #0  func2 () at t.c:5 0x0000000000401127 in main () at t.c:8 8           func1(); func2(); (gdb) rs 8           func1(); func2(); (gdb) func1 () at t.c:2 2       } (gdb) Notice how there were two "reverse-step" commands needed after the "reverse-finish" used to exit func2. What Carl is proposing we do is make it so GDB only needs one command. If I compare the $pc of where GDB is stopped and the linetable, we get: (gdb) print $pc $2 = (void (*)()) 0x401127 (gdb) maint info line-table objfile: /home/blarsen/Documents/downstream_build/gdb/reverse ((struct objfile *) 0x10f7750) compunit_symtab: t.c ((struct compunit_symtab *) 0x116c330) symtab: /home/blarsen/Documents/downstream_build/gdb/t.c ((struct symtab *) 0x116c3b0) linetable: ((struct linetable *) 0x11aec80): INDEX  LINE   ADDRESS            IS-STMT PROLOGUE-END 0      1      0x0000000000401106 Y 1      2      0x000000000040110a Y 2      4      0x000000000040110d Y 3      5      0x0000000000401111 Y 4      7      0x0000000000401114 Y 5      8      0x0000000000401118 Y 6      8      0x0000000000401122 Y 7      9      0x0000000000401131 Y 8      END    0x0000000000401133 Y We can see that GDB shouldn't even be able to stop at that $pc, it isn't an is_stmt. We should have stopped at 0x401122, which is where the first reverse-step stops: (gdb) rs 8           f1(); f2(); (gdb) p $pc $4 = (void (*)()) 0x401122 So not only are we needing an extra command to re-sync with user expectations, we are in an instruction where the inferior state might be all over the place. -- Cheers, Bruno