From: Doug Evans <dje@google.com>
To: Daniel Gutson <daniel.gutson@tallertechnologies.com>
Cc: Yao Qi <yao@codesourcery.com>, gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Fix alignment of disassemble /r
Date: Thu, 17 Apr 2014 18:19:00 -0000 [thread overview]
Message-ID: <CADPb22SX8M=Rw4-hzxzm6BBbLss8N57pD4XCJGLKrSQjw1RHXg@mail.gmail.com> (raw)
In-Reply-To: <CAF5HaEUjLYqQdgvrwEdUKBJFFeCaaZ8BQQQTSJz1RMo_VEJdUA@mail.gmail.com>
On Thu, Apr 17, 2014 at 10:27 AM, Daniel Gutson
<daniel.gutson@tallertechnologies.com> wrote:
> On Thu, Apr 17, 2014 at 1:27 PM, Doug Evans <dje@google.com> wrote:
>> On Thu, Apr 17, 2014 at 7:37 AM, Daniel Gutson
>> <daniel.gutson@tallertechnologies.com> wrote:
>>> So what if I add a new configuration variable, such as
>>> set disassemble-raw-alignment
>>> with "off" as default, and if set to on, pad to gdbarch_max_insn_length ?
>>
>> Presumably some frontends will do their own alignment.
>>
>> If we went with disassemble-raw-alignment, a boolean value won't help
>> x86 much, it's either no alignment or (in general) too much
>> whitespace.
>> An improvement would be a value from min-insn-length to
>> max-insn-length, but that would be problematic in a multi-arch
>> debugging scenario.
>>
>> If we could agree on some minimum alignment for each variable-length
>> ISA (5 would be fine for me for x86) then maybe a boolean value could
>> be useful ("off" = no alignment, "on" = employ arch-specific minimum).
>>
>> OTOH, what if we made two passes over the instructions, with the first
>> pass computing the maximum instruction length that is present?
>
> I already considered this, but thought that it would be going to be
> rejected due to be too much non-performant. Wouldn't each pass
> translate in a lot of MI messaging in a case of a remote server?
[nit: If by "remote server" you mean things like gdbserver, then MI
isn't involved.]
Yes, it *could* involve extra traffic between gdb and gdbserver (or
whatever stub is being used) but we have caching now that should
mitigate that.
Still, it's a valid concern.
> And,
> what about screen paginig? I shouldn't iterate over all the range, but
> the screen height range only.
I guess one could go that route but IMO it's not necessary.
OTOH, One *could* also do the max-length computation in bunches that
took advantage of the cache size thus guaranteeing no additional
gdb/gdbserver traffic.
Not my first choice, just a possibility.
[gdb has a lot of knobs, just want to make sure no stone is left
unturned before we add this one :-)]
> I can go for any of the proposed solutions. 5 insn-length was fine for
> me. On a side note, I did this since I was debugging some
> self-modifying-code where the mis-alignment was driving me crazy.
> The two-passes solution is the one I dislike more IMVHO.
>
> Yet another option is to set the disassembly raw alignment width, something like
> set disassemble-raw-width 5
> (5 is the amount of insn; 0 means no padding equal to the current
> behavior and that would be the default value).
The problem with this is that the setting is arch-specific.
Not that one can do this today (or maybe one can in certain
situations, e.g. Cell), but if I'm debugging two different programs
from two different architectures it's possible any one value of
disassemble-raw-width is going to be painful.
One *could* have prefix commands for each architecture, and then one could have
set arch-$arch disassemble-raw-width N
or
set arch $arch disassemble-raw-width N
[again, just a possibility, not sure I prefer it]
Sorry for not having a definitive suggestion.
Maybe others will express an opinion and we can go from there.
next prev parent reply other threads:[~2014-04-17 18:19 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
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 [this message]
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='CADPb22SX8M=Rw4-hzxzm6BBbLss8N57pD4XCJGLKrSQjw1RHXg@mail.gmail.com' \
--to=dje@google.com \
--cc=daniel.gutson@tallertechnologies.com \
--cc=gdb-patches@sourceware.org \
--cc=yao@codesourcery.com \
/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