Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Yao Qi <yao@codesourcery.com>
To: Daniel Gutson <daniel.gutson@tallertechnologies.com>,
	gdb-patches	<gdb-patches@sourceware.org>
Subject: Re: [PATCH] Fix alignment of disassemble /r
Date: Thu, 17 Apr 2014 01:09:00 -0000	[thread overview]
Message-ID: <534F294D.4050907@codesourcery.com> (raw)
In-Reply-To: <CAF5HaEUBbK4d2reSxUpUQwp7Zt_KjcpNC_nbUrMHRb0yNo9wtw@mail.gmail.com>

On 04/12/2014 06:24 AM, Daniel Gutson wrote:
>    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.

The /r output is messed, but not completely :).

> 
> 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.

Hard-coded opcode length will affect other targets.  For example, without
your patch, the disassembly for c6x is like,
(gdb) disassemble /r main
Dump of assembler code for function main:                                                                                                                     
   0x00000860 <+0>:     c2 1b be 07     subah .D2 b15,16,b15
   0x00000864 <+4>:     f6 02 3d 07     stw .D2T2 b14,*+b15(32)

with your patch applied, it becomes

(gdb) disassemble /r main                                                                                                 
Dump of assembler code for function main:                                                                                                                     
   0x00000860 <+0>:     c2 1b be 07             subah .D2 b15,16,b15
   0x00000864 <+4>:     f6 02 3d 07             stw .D2T2 b14,*+b15(32)

gdbarch_max_insn_length can tell us the max instruction length, but if we
align the instruction to the max length (it is 16 on x86), the text
instruction will be far behind the hex code, which is a little ugly.

-- 
Yao (齐尧)


  parent reply	other threads:[~2014-04-17  1:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-11 22:24 Daniel Gutson
2014-04-16 12:20 ` Daniel Gutson
2014-04-17  1:09 ` Yao Qi [this message]
2014-04-17 14:37   ` Daniel Gutson
2014-04-17 16:27     ` Doug Evans
2014-04-17 17:27       ` Daniel Gutson
2014-04-17 18:19         ` Doug Evans
2014-04-21  0:56         ` Yao Qi
2014-04-21 16:00           ` Daniel Gutson
2014-04-22 12:14             ` Daniel Gutson
2016-03-04 20:41               ` Daniel Gutson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=534F294D.4050907@codesourcery.com \
    --to=yao@codesourcery.com \
    --cc=daniel.gutson@tallertechnologies.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox