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 024803857358 for ; Thu, 23 Jun 2022 16:05:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 024803857358 Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-75-XHy4E4HbNpqGZW9EOKwb_A-1; Thu, 23 Jun 2022 12:05:25 -0400 X-MC-Unique: XHy4E4HbNpqGZW9EOKwb_A-1 Received: by mail-wr1-f70.google.com with SMTP id s1-20020a5d69c1000000b0021b9f3abfebso1150713wrw.2 for ; Thu, 23 Jun 2022 09:05:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=3JOW3mFl1DI36pTjyy1AQ8YDYMGtAotYP5wehYOYpVE=; b=bS3N/1GxnbffjXC6KJ933pjdkmqYZB901MGQaHKiHz3XqN1f1meG0Qn6NIvbZFsANk F7wtZJZYt4lDd7pt48krpPVTr5ntTfxAsPWUzStvOY0a5Zh6ODA9vfJ7gyMYNtbWrQPa Rawgt7d+sakajwXycXh1gFkM4QvZ2qRec/0hhbRNNFR839XkSt3nBeJ7Foq+/E8pSj02 CBhxBAMHLLj18jM24ydvL92RSp7tyvOn27chRfrEmO17s9XXM3MP2mPgdhft9iH1pVmY Fyt5V0ZPGwGJa29mvvzefMA9T/m8PzG58NVQ3spOMse7NUjoPM2i7pWkUP93pTvDsTF3 J0xQ== X-Gm-Message-State: AJIora+1Y7dEK3Xhe+RCPZPeU6GqjrqxYiQvanvBnpl20G84XK++SD7E PMc851mQPrFdiXhcrFucKmYnreoHVTnLOFX+9W7pT4Pj4+DVDRjDpSmLKD8CaN0m+Ej3CYNIHnP EaLdS77vyglyqDOiBza/eJN0bvrw+WhzSw2gExlfnF+KSvtg22nGSOhyWPX8KYpDSSP7zeahQHA == X-Received: by 2002:adf:e602:0:b0:21b:962f:4250 with SMTP id p2-20020adfe602000000b0021b962f4250mr9093239wrm.277.1656000324110; Thu, 23 Jun 2022 09:05:24 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tmhCBGPXMCdDeBEV5b7GZo6d+qiRlIYJ1bL3VXlnfsyeJq37ejI1wp8WmeWfgXj5QvAmoV0w== X-Received: by 2002:adf:e602:0:b0:21b:962f:4250 with SMTP id p2-20020adfe602000000b0021b962f4250mr9093163wrm.277.1656000323353; Thu, 23 Jun 2022 09:05:23 -0700 (PDT) Received: from localhost ([195.213.152.79]) by smtp.gmail.com with ESMTPSA id cl10-20020a5d5f0a000000b0021b92171d28sm13570865wrb.54.2022.06.23.09.05.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 09:05:23 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCH 0/9] Disassembler opcode display and text alignment Date: Thu, 23 Jun 2022 17:05:07 +0100 Message-Id: X-Mailer: git-send-email 2.25.4 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, 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 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2022 16:05:32 -0000 This series makes two related changes to GDB's disassembler. Both changes flow naturally from having GDB make use of libopcodes bytes_per_line and bytes_per_chunk presentation hints that are set on a per-architecure basis with each call into the disassembler. The end result of this change is that GDB will now display instruction opcodes in the same way that objdump does. For x86-64 there's no change in the way that opcode bytes are presented. Now due to some special case, it's just that how GDB lays out instruction opcodes just happens to match how libopcodes requests that the opcodes be laid out. For other architectures, risc-v, powerpc, arm, aarch64, etc, this is not the case, and I (personally) think objdump does a better job of presenting the information that GDB does; the instruction opcodes will be grouped together based on the instruction size, and potentially byte-swapped so they appear in the instruction's natural order. Making use of the display hints also allows for better alignment of the disassembly text when opcodes are being printed. I have proposed that this new behaviour become the default for 'disassemble /r', and I've added a new flag 'disassemble /b' which allows the user to access the old behaviour. But, if people feel strongly that the old 'disassemble /r' should not be changed, I can place the new behaviour under a new flag. Let me know your thoughts, Thanks, Andrew --- Andrew Burgess (9): gdb/doc: improve description of --data-disassemble opcodes output gdb/testsuite: new test for -data-disassemble opcodes format gdb/disasm: read opcodes bytes with a single read_code call gdb: disassembler opcode display formatting gdb: make gdb_disassembly_flag unsigned gdb/doc: fix column widths in MI compatibility table gdb/doc: update syntax of -data-disassemble command arguments gdb/mi: some int to bool conversion gdb/mi: new options for -data-disassemble command gdb/NEWS | 12 ++ gdb/cli/cli-cmds.c | 6 + gdb/disasm-flags.h | 3 +- gdb/disasm.c | 55 +++++++-- gdb/disasm.h | 3 + gdb/doc/gdb.texinfo | 137 ++++++++++++++++----- gdb/mi/mi-cmd-disas.c | 105 ++++++++++++---- gdb/record.c | 3 + gdb/testsuite/gdb.mi/mi-disassemble.exp | 153 ++++++++++++++++++++---- gdb/testsuite/lib/mi-support.exp | 27 +++++ 10 files changed, 417 insertions(+), 87 deletions(-) -- 2.25.4