From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by sourceware.org (Postfix) with ESMTPS id 0ED9C3858D35 for ; Wed, 1 Feb 2023 14:37:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0ED9C3858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f47.google.com with SMTP id bk16so17498969wrb.11 for ; Wed, 01 Feb 2023 06:37:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NtC7LeYoYVL/dNWKU4P34vlujqsgPs86THiFkjqQNWc=; b=m0gHlNDki3bj4OMEAntK1oq/pAWWli1qlaDE2UoorO/jbsaJXX/3RzgsWjsGN/xWfy vQk93tGDGxWuMUNzcGv6ly5dX85xc0mxlcY1FfD7f76p7kFTGcnzwSiEDj3Hm3JgTPWo KY+qAKB03GhAujDVGj3lPviyAbsyb33a0f1JBLiyUlGsjzNNn6paynv3N8ZfKznjwSX4 n9PSuYvRDm6s4+aSyv8QRtRLVnM1rRah2sVvQ5BrbpTk9EKSr8yAkEoCnSSt9OLrm5Iz SqibIJZOuDuzG4VM83lM0RAlbVOcTktw7S9LZTz8+xtKrg6g9y7AbuHQ0jT3t2xaRuYU 7Izg== X-Gm-Message-State: AO0yUKXkYToJ267/DhDKhe38CAMlQaANF8kijo1Wa8NMpNTZoswkJCjV UKKs0xyZNWisLAct+l+Xmlh5MgMz+ia8Eg== X-Google-Smtp-Source: AK7set//5Qr0Lc5AI+2zmu06BcbXpP8yB3rGDcsFAmVgSfUq2brFOROpmcNDfMRbzNVeJQ5FmN3vmQ== X-Received: by 2002:adf:a202:0:b0:2bf:b6bb:25d5 with SMTP id p2-20020adfa202000000b002bfb6bb25d5mr2612310wra.24.1675262270635; Wed, 01 Feb 2023 06:37:50 -0800 (PST) Received: from ?IPv6:2001:8a0:f92b:9e00::1fe? ([2001:8a0:f92b:9e00::1fe]) by smtp.gmail.com with ESMTPSA id p8-20020adff208000000b002423edd7e50sm17684691wro.32.2023.02.01.06.37.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Feb 2023 06:37:50 -0800 (PST) Subject: Re: Reverse-next bug test case To: Carl Love , Bruno Larsen , Tom de Vries , Ulrich Weigand , 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> <6785a1c038d5956d43892f8a7f27106d9001de76.camel@us.ibm.com> From: Pedro Alves Message-ID: <2f4db108-8c37-8464-1e2d-77b22413ff98@palves.net> Date: Wed, 1 Feb 2023 14:37:49 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <6785a1c038d5956d43892f8a7f27106d9001de76.camel@us.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,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 2023-01-31 12:17 a.m., Carl Love wrote: > +# The second reverse step should take us call of func2 (). > +gdb_test "reverse-step" ".*func1 \\(\\); func2 \\(\\);.*" \ > + "reverse-step to line func1(); func2(), at call for func2 " > + >From : "Like the step command, reverse-step will only stop at the beginning of a source line. " So when reverse-stepping is ongoing and execution internally stops at the call to func2, gdb should realize it is not really at the beginning of a source line, and continue stepping. That should take it inside func1, and stop there (at the beginning of a line), as it will have reached a different line. I would start by looking at making either of these pass: $ make check TESTS="*/pedro_test.exp" RUNTESTFLAGS="CC_FOR_TARGET='gcc -gno-column-info'" $ make check TESTS="*/pedro_test.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang" ... as the misbehavior happens due to GDB misinterpreting multiple lines entries for the same line when column info is emitted by current gcc. If you disable the column info, then gdb should not stop in the middle of a line, and that's how gdb should always behave. (Making use of column info is certainly interesting to support statement stepping, but that's orthogonal.)