From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14488 invoked by alias); 17 Apr 2014 18:19:07 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 14405 invoked by uid 89); 17 Apr 2014 18:19:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f172.google.com Received: from mail-vc0-f172.google.com (HELO mail-vc0-f172.google.com) (209.85.220.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 17 Apr 2014 18:19:06 +0000 Received: by mail-vc0-f172.google.com with SMTP id la4so906041vcb.17 for ; Thu, 17 Apr 2014 11:19:03 -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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K3RKsF1M2dyXbOemkewapAbmajKF9Ga0JhpdhlFxgiw=; b=TB4F6+Y5OziwUi0k+dZr7Bt683bV6yFaGMQk9GGbLjYu9u8nxwXuHseGIULsPu3Jv6 DST2wxX7I+7NYXMPrXLMg2P3EULMI2r6MEFtcZrTJRFPZy/zTxERx2RlAeuoJNcBMykP RmUrTXCBVuD47Gb0eUVej54uO+Jh4WMPUDeC3zStJWFBElFI8AUdO3wyZR4iymQ9Cwx0 q3U1I7dMRoIoOViOwvff1WpSQ6rBx4z78IhMK1TIOe8mODAB2Se5Zs0pLsa+yTG/1r5X Zf/3vREZ/1QD3p1nuwM3rT5wwzHZ0b7biqRjzBO7nyX/3fjzyPqWcSGcYqTXYM/BECfZ jJmg== X-Gm-Message-State: ALoCoQlIny7hoBGHecuOOfXpTpgRLl2h+3iMUUumZ3NbnToiAH2MHmJ/kqJI579Q1oBQMVtxSHzZytKEf0ZJRCObZrBeF8CqvqK7AMTTnzSDwMzi6950YenluKUu5B7imm54tnBlIqGAsdCGOWEMcpioJYqWd3nC7bAo/zTgjvYU4PjrYqQKLA4g3K+o5V/wdikX794b+7pVN340wtEKvVVbjbOQ5p14GA== MIME-Version: 1.0 X-Received: by 10.58.134.101 with SMTP id pj5mr64723veb.38.1397758743693; Thu, 17 Apr 2014 11:19:03 -0700 (PDT) Received: by 10.52.13.101 with HTTP; Thu, 17 Apr 2014 11:19:03 -0700 (PDT) In-Reply-To: References: <534F294D.4050907@codesourcery.com> Date: Thu, 17 Apr 2014 18:19:00 -0000 Message-ID: Subject: Re: [PATCH] Fix alignment of disassemble /r From: Doug Evans To: Daniel Gutson Cc: Yao Qi , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00373.txt.bz2 On Thu, Apr 17, 2014 at 10:27 AM, Daniel Gutson wrote: > On Thu, Apr 17, 2014 at 1:27 PM, Doug Evans wrote: >> On Thu, Apr 17, 2014 at 7:37 AM, Daniel Gutson >> 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.