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 D24FA385773D for ; Tue, 16 May 2023 11:01:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D24FA385773D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684234899; 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: in-reply-to:in-reply-to:references:references; bh=lffyCTSvkNu12blqjyYkpQCyuPHD2z4ll1Sx1EhMPUw=; b=XgveACLF8TVP9kS/A2jDeFR34PrZ6vTe5nDvWw161MF1kyjBWbbe6g4ivvaQUtYGJJaPQ0 0fz5M0WoH32EX7qYb6OJpc5hCYH7nmt6r2jTInQ6xNjjgSK0OELx0WrI1AIhjHtgiOuaYe lVZ2vKA8A/DDwx+7BsPaznAinwJfm9k= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-323-nueASGR4MMOGZ5D5E8NNdA-1; Tue, 16 May 2023 07:01:38 -0400 X-MC-Unique: nueASGR4MMOGZ5D5E8NNdA-1 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-3f426d4944fso34777205e9.1 for ; Tue, 16 May 2023 04:01:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684234897; x=1686826897; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lffyCTSvkNu12blqjyYkpQCyuPHD2z4ll1Sx1EhMPUw=; b=b6hPxwA0eMK/t8K2qrjVpHOZXOknSvQf6By9jFFUVVHUqdbRZTPQyT0nMu2D/UetV+ gwA5aX/1GrLhTw8GIMy8dHjY+Eo89e3SAzx6/o/HPoZ7Fz4qykjB0w/QVwUxftxOyTTY NKD4LUFlN/74Z8mL6n457oCv247aVFbykdRaltYWdv03be5IAUjr9i0us7ajqUgjGwE9 U+30XeJJA6GPeSJcK9yAn6MAZjvyZh4mkgYIaAxpEaTNgJKZNqrJ1TlYRI405gs0AHfI NLvI6QY3ftjDR9ITVQR9MMBjx0vOP8522b+/K7AA0FdNiFaWCRALpYrBvUsUtK4sLEZF MleA== X-Gm-Message-State: AC+VfDz/n4YDp3jDLwi7HUERp+DmT4k2atqOpsqKijFpq0bVdbz2sGRz TbQTsXcvOSOey2ilC6Z1x2kKmA8lo8IOwGt6VrLpeaPKLAAqutYv8bVEUYVpBPh3KGpQOJQ9AqH uXp3NdmGzEUzmUVA6J9PNpvngQYGh43aIS+pyU8dE1GY+tBxFLs6uSsk96Mx8x+tRzEkMKHmHZc hu3OZeVA== X-Received: by 2002:a05:600c:3655:b0:3f4:2cc7:aac5 with SMTP id y21-20020a05600c365500b003f42cc7aac5mr16136561wmq.9.1684234897037; Tue, 16 May 2023 04:01:37 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7qbzyP/PytJqEuYsAf4HZ417XPm6IiXNEIlEFleVR6WQJgwWeYrdIgA+iiU84/avPyb+Iarg== X-Received: by 2002:a05:600c:3655:b0:3f4:2cc7:aac5 with SMTP id y21-20020a05600c365500b003f42cc7aac5mr16136533wmq.9.1684234896453; Tue, 16 May 2023 04:01:36 -0700 (PDT) Received: from localhost (11.72.115.87.dyn.plus.net. [87.115.72.11]) by smtp.gmail.com with ESMTPSA id z8-20020a1c4c08000000b003f42d8dd7d1sm1965122wmf.7.2023.05.16.04.01.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 May 2023 04:01:36 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Eli Zaretskii Subject: Re: [PATCHv3 2/2] gdb/python: extend the Python Disassembler API to allow for styling In-Reply-To: <7d8bfee6bf10b136f0d02e9a45ef47249fdcca0a.1683913563.git.aburgess@redhat.com> References: <7d8bfee6bf10b136f0d02e9a45ef47249fdcca0a.1683913563.git.aburgess@redhat.com> Date: Tue, 16 May 2023 12:01:35 +0100 Message-ID: <87wn18a6b4.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: Andrew Burgess writes: > This commit extends the Python Disassembler API to allow for styling > of the instructions. > > Before this commit the Python Disassembler API allowed the user to do > two things: > > - They could intercept instruction disassembly requests and return a > string of their choosing, this string then became the disassembled > instruction, or > > - They could call builtin_disassemble, which would call back into > libopcode to perform the disassembly. As libopcode printed the > instruction GDB would collect these print requests and build a > string. This string was then returned from the builtin_disassemble > call, and the user could modify or extend this string as needed. > > Neither of these approaches allowed for, or preserved, disassembler > styling, which is now available within libopcodes for many of the more > popular architectures GDB supports. > > This commit aims to fill this gap. After this commit a user will be > able to do the following things: > > - Implement a custom instruction disassembler entirely in Python > without calling back into libopcodes, the custom disassembler will > be able to return styling information such that GDB will display > the instruction fully styled. All of GDB's existing style > settings will affect how instructions coming from the Python > disassembler are displayed in the expected manner. > > - Call builtin_disassemble and receive a result that represents how > libopcode would like the instruction styled. The user can then > adjust or extend the disassembled instruction before returning the > result to GDB. Again, the instruction will be styled as expected. > > To achieve this I will add two new classes to GDB, > DisassemblerTextPart and DisassemblerAddressPart. > > Within builtin_disassemble, instead of capturing the print calls from > libopcodes and building a single string, we will now create either a > text part or address part and store these parts in a vector. > > The DisassemblerTextPart will capture a small piece of text along with > the associated style that should be used to display the text. This > corresponds to the disassembler calling > disassemble_info::fprintf_styled_func, or for disassemblers that don't > support styling disassemble_info::fprintf_func. > > The DisassemblerAddressPart is used when libopcodes requests that an > address be printed, and takes care of printing the address and > associated symbol, this corresponds to the disassembler calling > disassemble_info::print_address_func. > > These parts are then placed within the DisassemblerResult when > builtin_disassemble returns. > > Alternatively, the user can directly create parts by calling two new > methods on the DisassembleInfo class: DisassembleInfo.text_part and > DisassembleInfo.address_part. > > Having created these parts the user can then pass these parts when > initializing a new DisassemblerResult object. > > Finally, when we return from Python to gdbpy_print_insn, one way or > another, the result being returned will have a list of parts. Back in > GDB's C++ code we walk the list of parts and call back into GDB's core > to display the disassembled instruction with the correct styling. > > The new API lives in parallel with the old API. Any existing code > that creates a DisassemblerResult using a single string immediately > creates a single DisassemblerTextPart containing the entire > instruction and gives this part the default text style. This is also > what happens if the user calls builtin_disassemble for an architecture > that doesn't (yet) support libopcode styling. > > This matches up with what happens when the Python API is not involved, > an architecture without disassembler styling support uses the old > libopcodes printing API (the API that doesn't pass style info), and > GDB just prints everything using the default text style. > > The reason that parts are created by calling methods on > DisassembleInfo, rather than calling the class constructor directly, > is DisassemblerAddressPart. Ideally this part would only hold the > address which the part represents, but in order to support backwards > compatibility we need to be able to convert the > DisassemblerAddressPart into a string. To do that we need to call > GDB's internal print_address function, and to do that we need an > gdbarch. > > What this means is that the DisassemblerAddressPart needs to take a > gdb.Architecture object at creation time. The only valid place a user > can pull this from is from the DisassembleInfo object, so having the > DisassembleInfo act as a factory ensures that the correct gdbarch is > passed over each time. I implemented both solutions (the one > presented here, and an alternative where parts could be constructed > directly), and this felt like the cleanest solution. > > Reviewed-By: Eli Zaretskii Pushed the patch below to fix the formatting of a .py file. Sorry for the noise. Thanks, Andrew -- commit 66b8e6c7b8d3c137029f4f2ab8c5b798aa1cbdd7 Author: Andrew Burgess Date: Tue May 16 11:59:45 2023 +0100 gdb/testsuite: fix formatting of gdb.python/py-disasm.py Run black on gdb.python/py-disasm.py file and commit the changes. diff --git a/gdb/testsuite/gdb.python/py-disasm.py b/gdb/testsuite/gdb.python/py-disasm.py index ec6b0e8deca..67ba6756ea9 100644 --- a/gdb/testsuite/gdb.python/py-disasm.py +++ b/gdb/testsuite/gdb.python/py-disasm.py @@ -31,7 +31,7 @@ def builtin_disassemble_wrapper(info): assert len(result.parts) > 0 tmp_str = "" for p in result.parts: - assert(p.string == str(p)) + assert p.string == str(p) tmp_str += p.string assert tmp_str == result.string return result @@ -586,9 +586,9 @@ class All_Text_Part_Styles(TestDisassembler): result = builtin_disassemble_wrapper(info) result = DisassemblerResult(length=result.length, parts=parts) - tmp_str = ""; + tmp_str = "" for p in parts: - assert (p.string == str(p)) + assert p.string == str(p) tmp_str += str(p) assert tmp_str == result.string