From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 34E2A3858D39 for ; Mon, 23 Oct 2023 18:46:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 34E2A3858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 34E2A3858D39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698086781; cv=none; b=Qno+IoCXiUQKqhE1USMJd26iWaxwYpnPDYZXp4+S3XhJzaRIFxisY6gBUKh4Z5OgFQD3Za5pjCPyJqj5FYcIrsWnU0wx6bKOu2nryfjqYJ9zrSJgDn9XwHGgWW+jWLJzieLoNc/Gy4ApaX/upeSRZMQLiFRt+lh5+9XA//q5QJU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698086781; c=relaxed/simple; bh=fr+elHVji6vMC6F3rfLByE1f34+ji3zjcuOI9x+l+lA=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=OQkNSoK4QeKWQtl1JkSQ7hDjRbOnq5HoMnDAS5bGHk0e8wBfatxYmTsMbkZlOe/Wr3yqQD4Ui6/bS1Yl/+l7YVLBtLNL5v/0naB5Ocpz1gs0CH26XjAjSDVs7hpzT9GGkYF4+VavbFQwu5bO/XF/Nt3/Brquf76TusIoPqDZEVY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1quzwR-00067O-Ec; Mon, 23 Oct 2023 14:46:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=E28HH1XHzgS/tQ8aIhUCQCLaT+yTA7nlqE5xt48tgxc=; b=foWbYWhVYgIE YjtTdEOE7IvAqkraL2kZy2+MFJFAjpDFXM3Gg3iMQfAK6t+3+VvyLoMBOjPMWBIQy5f/OGGc7BbW5 S7FFrc7e72/Wgjm9YafLEyAinHy7CpvmNaQfquqtnGSd8Y1Xh8xyt1o1j5NeGVgDTzg35rAlf6nid EpeRZUyMYu4SSbmF5tHLbV4MH4ob9pueBczG9X1ChkAmBYxLs0o1fX4Tshj21Pb+3qkWt8tG064/Y gJ9FX8D2F/xyfayj/so4ivXvbWL06J1UJ2JhliXPyKGCSr06M7L+uDQVNq3+3ID5emh/O/YwH4Pss hEMdxJv986FlBhtO5B7IPQ==; Date: Mon, 23 Oct 2023 21:46:19 +0300 Message-Id: <83r0llmb2c.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess Cc: gdb-patches@sourceware.org, tom@tromey.com In-Reply-To: <2584da63766489b4a98467942a916b2de3331fba.1698083522.git.aburgess@redhat.com> (message from Andrew Burgess on Mon, 23 Oct 2023 18:55:44 +0100) Subject: Re: [PATCHv2] gdb/python: Add new gdb.Value.bytes attribute References: <9cefc82f3c5d6619bca1f04a783e48ea5639a841.1697641024.git.aburgess@redhat.com> <2584da63766489b4a98467942a916b2de3331fba.1698083522.git.aburgess@redhat.com> X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 List-Id: > From: Andrew Burgess > Cc: Andrew Burgess , > Eli Zaretskii , > Tom Tromey > Date: Mon, 23 Oct 2023 18:55:44 +0100 > > Thanks for the feedback on V1. > > In V2: > > - Docs have been updated to be more explicit about the byte > ordering, but have also been extended to cover the new > functionality I've added in this update, > > - The cached value is now cleared correctly during Value.assign > calls as Tom pointed out, > > - The Value.bytes attribute can now be assigned too. This is > similar to how Value.assign works. > > --- > > Add a gdb.Value.bytes attribute. This attribute contains the bytes of > the value (assuming the complete bytes of the value are available). > > If the bytes of the gdb.Value are not available then accessing this > attribute raises an exception. > > The bytes object returned from gdb.Value.bytes is cached within GDB so > that the same bytes object is returned each time. The bytes object is > created on-demand though to reduce unnecessary work. > > For some values we can of course obtain the same information by > reading inferior memory based on gdb.Value.address and > gdb.Value.type.sizeof, however, not every value is in memory, so we > don't always have an address. > > The gdb.Value.bytes attribute will convert any value to a bytes > object, so long as the contents are available. The value can be one > created purely in Python code, the value could be in a register, > or (of course) the value could be in memory. > > The Value.bytes attribute can also be assigned too. Assigning to this > attribute is similar to calling Value.assign, the value of the > underlying value is updated within the inferior. The value assigned > to Value.bytes must be a buffer which contains exactly the correct > number of bytes (i.e. unlike value creation, we don't allow oversized > buffers). > > To support this assignment like behaviour I've factored out the core > of valpy_assign. I've also updated convert_buffer_and_type_to_value > so that it can (for my use case) check the exact buffer length. > > The restrictions for when the Value.bytes can or cannot be written too > are exactly the same as for Value.assign. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13267 > --- > gdb/NEWS | 3 + > gdb/doc/python.texi | 16 ++++ > gdb/python/py-value.c | 122 ++++++++++++++++++++++---- > gdb/testsuite/gdb.python/py-value.exp | 109 ++++++++++++++++++++++- > 4 files changed, 230 insertions(+), 20 deletions(-) OK for the documentation parts, thanks. Reviewed-By: Eli Zaretskii