From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id F13D63858D26 for ; Thu, 23 May 2024 01:43:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F13D63858D26 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F13D63858D26 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::42b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716428616; cv=none; b=SKjY88WWlkepyqwTIidYhZ1aTuos4D7K/VwDafYm2wZ1Lr3d2P1b1cxRaJjX5kF5tobM3oG8Jp4bWyiJfdvmAMotdFg6zQNtXlDJd098pnj4wEJTXPcD4nDLSqtZqM7ExUdqFhuYhkVR0nmgYeiQhW+q6F2RWU4cqb1laG3i2t0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716428616; c=relaxed/simple; bh=YeQcv8rec/goHLHr9KBewqGK8QhM4JwXLvx5K6HhBwk=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=OCUADJvcL/p/eVkWjcnV9wLmtV0QvQ1jusNhqJ5Qjk/sp8t1mW34ez+Id9jewU1n/YU+4v1byaoYwkbwb3/h2bxF2zolvChschkY+frfTqiJElbzKXVo3X8wOZjZzEg3+LiCIXU9JNuEhdug3hckOY3QycsoEQbwxdM/58Xyg98= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-6f44ed6e82fso1999904b3a.3 for ; Wed, 22 May 2024 18:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1716428614; x=1717033414; darn=sourceware.org; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=9WmLMPsx3LoI7wNeL4fyDACet4rEgzO5mvXq1NCZSAE=; b=XB9NJKgyZSl5ifiiZZCGYoyCiP7N7xby15k8Bgfjmx0N4VuManMVS4I8LLHZfngFKc 372CmDwfeZj1VQgCNgoT4hQK+luRuL+AabpulIbMVNFRZsleLTUmB21H3Ocfh/CKY7HP bTfe1gP0a6ppJpOWue0B6akQEdSkupwwwzQIEP142vMnxZ3jWhJcgqaz507xQBpqT5mA Jb1RzthiTvYHckOwEmAurwARRmKiro36M4h9Gy2Ae90eKWPlkTSBKP/gMTnZIjUtAULV AbYm5r3VDASsUUDgHrQiXLdDJ3xZPJMU3gXWjVVN54aYn4bBcXe/7y67td8mpo52NANF TaAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716428614; x=1717033414; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9WmLMPsx3LoI7wNeL4fyDACet4rEgzO5mvXq1NCZSAE=; b=WlFPDPxlATQIvFIWTIhhgBcWPjlEcfxYQcih1zPfjjU8gxB2TZj51kJQBcKKnkdMZ9 dZgTwgkgR33K8kXB4BfbPwIsmcjjKVM0mjy/Ixj1D+r60YJLSca/SZMnRKgC6hFwpgxX +JK12xCekLON2nUnZb41ujbsNuXKI/mWb/9xEJUqfysDHJkt8hQR898u5ekYuDHsjaHp G23c0s1zIX6T3l/t/QHQM3Ld8EFXDXOQQ3b6q6fTiCzEbQiDt+zpk2W1KUSt6rYhKfUb 1Xc0eV7Dl08L9XsyoPz4HqWoYrHlES/zC6Y2SakZl31NZABKnSJkx8Y9KUCT+l3Q2GO7 8WHA== X-Forwarded-Encrypted: i=1; AJvYcCWXqKhY2z85QLTzKrF4URN5fCeL2uZvCv/7p7MN+LNVs1mjAI0J+0O5znl+gUtnZeONUOtmcv+JsIg1kJbRk5cRCTPNO15uAUBM1A== X-Gm-Message-State: AOJu0Yy/gClljO8rvHeQ8f1vEW/qO0fnpgb4WfHlagdAlx45yYEI7bBq 7cByA5mYgc13CTp9UolzmSnqJZP1iZuXE4dRNMD3SFM+6GtwjlJQRmmHNC/bzug= X-Google-Smtp-Source: AGHT+IE9caX8GIvYCbw/R2x2rnitNESYA4mPZjgJkZ1ZKIw50tth225GbmnUMhgfv9DTUAyO1lgT1w== X-Received: by 2002:a05:6a00:4b0b:b0:6ea:d114:5ea1 with SMTP id d2e1a72fcca58-6f6d614e8b3mr3851995b3a.17.1716428613524; Wed, 22 May 2024 18:43:33 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8470:f149:d562:aa25:4733]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-6f4d2a6669dsm23056716b3a.31.2024.05.22.18.43.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 May 2024 18:43:33 -0700 (PDT) From: Thiago Jung Bauermann To: Guinevere Larsen Cc: Luis Machado , gdb-patches@sourceware.org, Christophe Lyon Subject: Re: [PATCH v2 0/5] Add support for AArch64 MOPS instructions In-Reply-To: <81d038d9-a822-49a3-9ae8-8a3f26b68181@redhat.com> (Guinevere Larsen's message of "Fri, 10 May 2024 12:07:35 -0300") References: <20240507022249.554831-1-thiago.bauermann@linaro.org> <06a22177-9f3b-41c0-a896-5f8d894c7218@arm.com> <87msozfz0h.fsf@linaro.org> <81d038d9-a822-49a3-9ae8-8a3f26b68181@redhat.com> User-Agent: mu4e 1.12.4; emacs 29.3 Date: Wed, 22 May 2024 22:43:30 -0300 Message-ID: <8734q9ti9p.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: Hello Guinevere, Guinevere Larsen writes: > On 5/9/24 00:24, Thiago Jung Bauermann wrote: > >>> One last point, doesn't record/replay require single-stepping each instruction >>> individually? Does that go against the atomic block approach? >> >> That's a good question. I'm not sure how the record and replay backend >> deals with that, to be honest. But it does work, and I added a testcase >> specifically to test reversing the MOPS sequences, and it passes both on >> QEMU and FVP. > > On x86 we require it. That's because we record the current value of all registers of interest, > including PC, which means if you tried to disassemble many instructions and record them all, you'd > be recording only the PC of the first instruction many times. I haven't looked at the Arm tdep > stuff for record but I can't imagine it would be too different. If I'm right, the test works because > you don't try to reverse-stepi to the middle of the asm statement, you just look at the full state > before and after. Thank you for the explanation! > If GDB will treat the block as always atomic, then I guess we don't need to save the PCs of every > instruction, so this approach is fine, but if people are expected to be able to stepi in between the > blocks, reverse should be able to do the same. If things are atomic, should we try to warn users > who try to stepi/reverse-stepi through those blocks? For MOPS instructions specifically in later versions of the patch series we're not treating them as atomic so this issue doesn't apply anymore. But for other atomic instructions (e.g., acquire/release) if the user stepi's (steps-i?) on the first instruction in the atomic sequence, GDB sets a breakpoint at the end of the sequence and continues the inferior until there. It doesn't show any warning or notice, though perhaps that would be friendlier. > Sidenote, I haven't had time to look at the code yet, but personally, I'd like to see the test > introduced at the same commit where support was added, because that would make it easier to > bisect in the future, if necessary :) Makes sense. Done for v4. -- Thiago