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.129.124]) by sourceware.org (Postfix) with ESMTPS id 643483858415 for ; Fri, 5 Apr 2024 12:53:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 643483858415 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 643483858415 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712321595; cv=none; b=XjP3gQz1xubAd9gF3kwZJgiI8F6PkkA8vI8XPqef+YmIsK7obD+XgeTmdelPtum9b3qmB5F1nYttdmEwSpuoZGvJgFd0pq9wqM//JmPxiInFvx3S2aq5ENnQKnmpR/q1EtlY5dwC64n1U0g7dchQeL6bFONwWSD9poEzB1smVQI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712321595; c=relaxed/simple; bh=rSKnL4Z7X2zEcrk9Rbl3eLysC+Zb4gMfN6TXR+O+N7g=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=R4zkAsq28sulxruSoUmLBLwcJEY8Dg1E7tko1oMq7136IxUifP7wroJ0zqN/cOcD0Ax3hjxwNHuqpk+KwDCaZCZN094qlM5ITgN8zHkTyO8WY+Ho685cb5VTpoLUXb0ihGU/90UMfp5aTliE3k9vYwiNHYVri4YHn9uEuPaXCtE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712321593; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Z0DTCTr/EVIOJ268i0cW53LP/YQKz3RDpIFW/uAujZM=; b=XR5kpiEk3Uj6Il/XbbQ9bfwA74+7TKSnKtnIquwRvnTR9JOBuJM9wyI4wdrxiav4F7RYpL mQKiECY9QFRUPQd2gipR1vZGJsesvN703KPyXRjSNvfcIoCW8nHGZFHSlx+75I4NDgwKIL y2c4EEzHIxueh4Z5Nn3q4U0no/QYLXk= Received: from mail-yb1-f197.google.com (mail-yb1-f197.google.com [209.85.219.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-595-jPy5XLrnOiKyephDuQOawQ-1; Fri, 05 Apr 2024 08:53:12 -0400 X-MC-Unique: jPy5XLrnOiKyephDuQOawQ-1 Received: by mail-yb1-f197.google.com with SMTP id 3f1490d57ef6-dbf216080f5so3424200276.1 for ; Fri, 05 Apr 2024 05:53:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712321591; x=1712926391; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Z0DTCTr/EVIOJ268i0cW53LP/YQKz3RDpIFW/uAujZM=; b=P0MejnJKkUGyX0DHe9M5Qf31CLm8ZE1l2KPc4gsA6S8hclHjd5Sqrqmf7u04QR+nPY H/UCgN6/mnviNvpqWdTkW6cfqnYIRXrDukw6euLI0gDiY4J/Ljc/Ze9RLwV6FNBG+MX0 SVtwCDftuIT3yUispil8yeuxk73F2t5MbxYlg+IlxhUqLg29/Gx61rmwWVkB+i/wHtc3 wbhuEfzhDiRO8X/BQBTYhH2+PtM26uHhnufkxMof9ruT1dt2MnzXWH2ak1oNi1nBNvoc G5n8RftEjm+SD3nNwC2kNWTfsxNtlvkR+eZ8kxPGox6I6s0LNfc6wQrPWn6jayCrHF4m CBjQ== X-Gm-Message-State: AOJu0YxFAD6izVVTMBUEBNr+Xy1tYchc9iMdyKMQB+MNBni3+qmoTGix YGWRwU9NyVyhg26rG6HWnbULqHl0ISlOgbG73Z0NheW1yfVCKhnWcQGFDCYawa/VupTJ/zeJ8FI b4e4HlnQngA+9sBFB/5HFjvUS+Zsiyf5L+jC6/cis9dUdW36y9vdWnToXiQPdeAlPXY5mmQ== X-Received: by 2002:a5b:9c1:0:b0:dd1:22f1:50e7 with SMTP id y1-20020a5b09c1000000b00dd122f150e7mr965898ybq.35.1712321591290; Fri, 05 Apr 2024 05:53:11 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE6gOk3pVZ62FoNTfr1jDjjdvxNVD+bbuNoJWNEymIHQSycuy39jxLiK0zsu8Vo2tzwJrrJ0Q== X-Received: by 2002:a5b:9c1:0:b0:dd1:22f1:50e7 with SMTP id y1-20020a5b09c1000000b00dd122f150e7mr965887ybq.35.1712321590957; Fri, 05 Apr 2024 05:53:10 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:92c5::1002? ([2804:14d:8084:92c5::1002]) by smtp.gmail.com with ESMTPSA id z16-20020a0ce990000000b0069795001041sm585952qvn.9.2024.04.05.05.53.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Apr 2024 05:53:10 -0700 (PDT) Message-ID: Date: Fri, 5 Apr 2024 09:53:08 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/4] gdb, infrun, btrace: fix reverse/replay stepping at end of execution history To: "Metzger, Markus T" Cc: "gdb-patches@sourceware.org" References: <20240312113423.3543956-1-markus.t.metzger@intel.com> <20240312113423.3543956-2-markus.t.metzger@intel.com> <93207d40-dfa0-49ad-a528-e08d1680e885@redhat.com> From: Guinevere Larsen In-Reply-To: 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: 7bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP 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 4/5/24 06:12, Metzger, Markus T wrote: >>> When trying to step over a breakpoint at the end of the trace, the >>> step-over will fail with no-history. This does not clear step_over_info >>> so a subsequent resume will cause GDB to not resume the thread and >> expect >>> a SIGTRAP to complete the step-over. This will never come causing GDB to >>> hang in the wait-for-event poll. >>> >>> That step-over failed after actually completing the step. This is wrong. >>> The step-over itself should have failed and the step should not have >>> completed. Fix it by moving the end of execution history check to before >>> we are stepping. >>> >>> This exposes another issue, however. When completing a step-over at the >>> end of the execution history, we implicitly stop replaying that thread. A >>> continue command would resume after the step-over and, since we're no >>> longer replaying, would continue recording. >>> >>> Fix that by recording the replay state in the thread's control state and >>> failing with no-history in keep_going if we're switching from replay to >>> recording. >> I am a little confused by your test case. From the commit message >> description, I expected the following GDB session to have been problematic: >> >> $ gdb record_goto >> (gdb) start >> 49 fun4 (); >> (gdb) record btrace >> (gdb) break fun1 >> (gdb) continue >> in frame fun1 () >> 23 } >> (gdb) reverse-next >> In frame fun4 () >> 41 fun1 (); >> (gdb) next >> No more reverse-execution history. >> 23 } >> (gdb) next >> # problems due to the SIGTRAP from the previous line >> >> (Pardon my hand written gdb session, my new system has an AMD cpu, so I >> seem to be locked out of btrace). >> >> My confusion comes from your test case never explicitly setting any >> breakpoints. I don't see why the inferior would have a sigtrap generated >> to test it. Am I misunderstanding the issue you described? > There are three tests contained in this patch. Two of them do My bad, I should have said that no test set the breakpoint to the furthest point that is executed. I didn't understand that the break should be in the previous instruction. Now that I'm rethinking my example, it doesn't really make sense, since as the testcase says, GDB wouldn't be replaying at that point. With this new understanding, this change LGTM. Reviewed-By: Guinevere Larsen -- Cheers, Guinevere Larsen She/Her/Hers > >>> +# We need to be replaying, otherwise, we'd just continue recording. >>> +gdb_test "reverse-stepi" >>> +gdb_test "break" >>> + >>> +# Continuing will step over the breakpoint and then run into the end of >>> +# the execution history. This ends replay, so we can continue recording. >>> +gdb_test "continue" "No more reverse-execution history.*" >>> +gdb_continue_to_end > The third test makes sure that 'step n' doesn't suddenly start recording. > > Regards, > Markus. > > Intel Deutschland GmbH > Registered Address: Am Campeon 10, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928