From patchwork Fri Apr 11 22:24:50 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Gutson X-Patchwork-Id: 517 Return-Path: X-Original-To: siddhesh@wilcox.dreamhost.com Delivered-To: siddhesh@wilcox.dreamhost.com Received: from homiemail-mx21.g.dreamhost.com (peon2454.g.dreamhost.com [208.113.200.127]) by wilcox.dreamhost.com (Postfix) with ESMTP id 6797536007D for ; Fri, 11 Apr 2014 15:25:00 -0700 (PDT) Received: by homiemail-mx21.g.dreamhost.com (Postfix, from userid 14314964) id 0477B1283F36; Fri, 11 Apr 2014 15:24:59 -0700 (PDT) X-Original-To: gdb@patchwork.siddhesh.in Delivered-To: x14314964@homiemail-mx21.g.dreamhost.com Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by homiemail-mx21.g.dreamhost.com (Postfix) with ESMTPS id CE1AB1283F2E for ; Fri, 11 Apr 2014 15:24:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:date:message-id:subject:from:to :content-type; q=dns; s=default; b=HwLbkGQKnBy1a9XFnEM3fvL1ggF5y BdXhuFqSMXx3D4LJ+xW5dFpIx1DArWCxTzoMImftviPLYPlKR60EIH50xKwK0P2a jjH6eQgjIDnZav96P07AjUm2NYDeMJdKXqInyjVHlzpfFTFUVu2TX8Gxg9CppFcF 0xHrjwHc/0k5e4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:date:message-id:subject:from:to :content-type; s=default; bh=aaR0QpYIYGWmsNXSp+HljvRvs/I=; b=Jjp X+HqX0FdApjpUULWCtk6Sp0egEpR/DyQRwl9kbhA59ovGWTk4iKoqRJg7tbFBKZB 0Bb/PaPJtKuLnU6QjLtyY6ot4Bjjgi1EPpF7Wnkzzv2q0O56dPa8YFaFpMDBHU4U yunOGpNBh6JxUOtJ/ha/sRdDvZu4WpJbX/2G3H0s= Received: (qmail 14068 invoked by alias); 11 Apr 2014 22:24:57 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 14058 invoked by uid 89); 11 Apr 2014 22:24:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mail-la0-f42.google.com Received: from mail-la0-f42.google.com (HELO mail-la0-f42.google.com) (209.85.215.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 11 Apr 2014 22:24:56 +0000 Received: by mail-la0-f42.google.com with SMTP id ec20so4060855lab.1 for ; Fri, 11 Apr 2014 15:24:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=6QE/Ll3Cd77cGdOJFDDKuZww3pp/3Wplt4xpp7E3wKc=; b=EiXvKL1Zkf/9yX6D+bRca0WhW9PXPuV5FL3YhKa/YX98v4PfluKD2l2XUj5X/2ZkCZ RDjsM8R4lFHvNrt5oQtKzxXrpYdN899vZlWnKsC1MoN0fg9Ydh5bdXBoX7qPyzlkBDpy zrkksLhb6UhUTzRvm4e19S/y+Qqu/uH9pLnVuUx5XUPo4SYOnmXpamwdIV1z+u5pfN6Y W4DDfnWZ+7CiYfx3KPGu0a37bACFPdxunf5DQfdO1QVC795G5p+fwVwg7MOCIITL61+s mFYaNVRhtog963600bbb0kXBGs8IdR/LX/lxubtazGEQKDHmMA5EfWJRbzCCGlVBy8Fc GXYQ== X-Gm-Message-State: ALoCoQmNyg1WxqJB/x+pOFYLK77bVasa3OShF9lOpBuvaoDNU65Qjz8f/U2Xs/d8/PH57R5AE5ph MIME-Version: 1.0 X-Received: by 10.112.142.68 with SMTP id ru4mr2918308lbb.49.1397255090974; Fri, 11 Apr 2014 15:24:50 -0700 (PDT) Received: by 10.112.9.40 with HTTP; Fri, 11 Apr 2014 15:24:50 -0700 (PDT) Date: Fri, 11 Apr 2014 19:24:50 -0300 Message-ID: Subject: [PATCH] Fix alignment of disassemble /r From: Daniel Gutson To: gdb-patches X-IsSubscribed: yes X-DH-Original-To: gdb@patchwork.siddhesh.in Hi, when disassembling in raw mode (/r) in a variable-length insn architecture (i.e. x86), the output can be completely messed since no alignment takes place. I am aware of the uiout->table stuff, but it seems an overkill since I should change the current_uiout when disassembling in this mode (and I didn't find any actual use of this machinery at least for x86). Therefore, I added a hack in the dump_insns when the /r flag is specified. This clearly isn't the cutiest thing in the world, and I specified a hardcoded maximum number of opcode bytes to align (currently 8) though it is easily changeable. Please let me know if this approach is OK or I should do something else. Maybe consider whether current arch is insn-len variable? If this happens to be OK, please commit it for me since I don't have write access. Thanks, Daniel. 2014-04-11 Daniel Gutson * disasm.c (dump_insns): Added right alignment when showing opcodes. diff --git a/gdb/disasm.c b/gdb/disasm.c index d94225b..0fd5aa1 100644 --- a/gdb/disasm.c +++ b/gdb/disasm.c @@ -107,6 +107,13 @@ dump_insns (struct gdbarch *gdbarch, struct ui_out *uiout, int offset; int line; struct cleanup *ui_out_chain; + /* This array holds enough space for 8 bytes of opcodes; + since the format is 02x plus the space, the length + the array is (2chars + 1space) * 8 bytes + 1zero = 25 chars. */ + char right_align[8 * 3 + 1]; + + memset(right_align, ' ', sizeof(right_align) - 2); + right_align[sizeof(right_align) - 1] = 0; for (pc = low; pc < high;) { @@ -154,6 +161,7 @@ dump_insns (struct gdbarch *gdbarch, struct ui_out *uiout, bfd_byte data; int status; const char *spacer = ""; + unsigned int alignment_pos = 0; /* Build the opcodes using a temporary stream so we can write them out in a single go for the MI. */ @@ -170,8 +178,11 @@ dump_insns (struct gdbarch *gdbarch, struct ui_out *uiout, fprintf_filtered (opcode_stream, "%s%02x", spacer, (unsigned) data); spacer = " "; + alignment_pos += 3; } ui_out_field_stream (uiout, "opcodes", opcode_stream); + if (alignment_pos < sizeof(right_align)) + ui_out_text (uiout, &right_align[alignment_pos]); ui_out_text (uiout, "\t"); do_cleanups (cleanups);