From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id H211EW2R+2SpPxMAWB0awg (envelope-from ) for ; Fri, 08 Sep 2023 17:26:05 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=Yr89DVcO; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 399CD1E0C3; Fri, 8 Sep 2023 17:26:05 -0400 (EDT) Received: from server2.sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 257961E092 for ; Fri, 8 Sep 2023 17:26:03 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7F4FF3858025 for ; Fri, 8 Sep 2023 21:26:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7F4FF3858025 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1694208362; bh=Khd4Ooe2sqeLqN77ar+PkHC7UALLl4JJAgParqQw+uI=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=Yr89DVcOigqIkV9kdg/MKzmplhmq3hLo6SAEIKUiKjuScv8B71KHqOsPWsQmxrwI9 NLATcXdha+EAYaosgeL4Mg6RF3+s7wTMSylB6DOArzVEHSGqm16yRh9NwmcT3JljAy PaS+QfC0MILqlRvbdcunvBpKTblevmUFRul8H3EM= Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136]) by sourceware.org (Postfix) with ESMTPS id BCE783858D1E for ; Fri, 8 Sep 2023 21:25:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BCE783858D1E Date: Fri, 08 Sep 2023 21:25:16 +0000 To: Tom Tromey , Jan Vrany via Gdb Subject: Re: MI and modifying register value Message-ID: In-Reply-To: <87msxwli8a.fsf@tromey.com> References: <459b4b9d5f83a6b03b66486a45f5c4e4daa0b5e7.camel@vrany.io> <87msxwli8a.fsf@tromey.com> Feedback-ID: 40767693:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, 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 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Jan Vrany via Gdb Reply-To: Jan Vrany Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On Fri, 2023-09-08 at 10:53 -0600, Tom Tromey wrote: > > > > > > "Jan" =3D=3D Jan Vrany via Gdb writes: >=20 > Jan> 1) There's an MI command to set register value: -data-write-register= -values > Jan> This command is not documented and looking at the code, seems to = be somewhat > Jan> half-implemented - does not use parameter its comment me= ntions and > Jan> only works for frame 0 (but using --frame 1 does not result in an= error, > Jan> it just silently changes value in frame 0). >=20 > Jan> Is this command some leftover that should not be used (but kept f= or some > Jan> old clients)? Or is it something to fix? >=20 > It's very old and seems to have landed without tests or documentation. >=20 > I think the addition of 'format' here must be some kind of copy-paste > bug. I can't imagine how it would be useful. However, in the spirit of > API conservatism I think it should just be left untouched -- we can just > document that it's a mistake and clients can send whatever they like for > this argument. >=20 > Fixing the frame bug seems completely fine to me. Yes, seems like an old and largely abandoned command.=20 >=20 > Jan> 2) Another way to change register value is CLI command `set r4 =3D 0= x4`. There's > Jan> no mechanism the MI client gets notified about the change - there= 's no =3Dregister-changed > Jan> async event.=C2=A0 >=20 > Surely it must be "set $r4 =3D 0x4" -- the "$" should be needed I think. You're right, "$" is missing in my example. A "typo" on my side.=20 >=20 > Jan> Is this by purpose? I'd expect some kind of notification, just li= ke there's =3Dmemory-changed > Jan> event. Also, in Python API, there's memory_ckanged event which ge= t triggered when > Jan> using `set` to modify register. >=20 > There's the weird "-data-list-changed-registers" command. It doesn't > really documented "changed since what", but it seems to be "since last > time this was called". There's a static local variable in the > implementation :-( Yes, but besides the issue of "changed since what?" (which would be nice to= fix), it does not really address the problem - imagine a UI that shows a list of reg= isters and then user from CLI modifies it with `set` command. With -data-list-chan= ged-registers I'd have to resort to issue this command each time an UI is redrawn / each = time use enters=C2=A0 a command in CLI which seems excessive. >=20 > I do see there is a "register_changed" observable, so implementing the > notification seems relatively easy. This observable seems to only track > changes made by the user, though. Yes. Tracking changes made by user is fine (for my use case). Anyways, I ju= st submitted a patch that allows me to implement such notification in Python [= 1] without introducing new async event to all clients. The documentations says= clients should be prepared for responses having more data but says nothing about ha= ndling new async events so this seemes "safer" :-) Jan [1] https://inbox.sourceware.org/gdb-patches/20230908210504.89194-2-jan.vra= ny@labware.com/T/#u