From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 367 invoked by alias); 21 Apr 2014 16:00:19 -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 355 invoked by uid 89); 21 Apr 2014 16:00:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mail-lb0-f173.google.com Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 21 Apr 2014 16:00:18 +0000 Received: by mail-lb0-f173.google.com with SMTP id p9so3286523lbv.4 for ; Mon, 21 Apr 2014 09:00:14 -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 :content-transfer-encoding; bh=lX+HyIBuvN+k3Xg9SaNJLVJhzj+55jz4+DlBt7p2ldE=; b=KkM+xg3JwDNq/tufXxgJw50mKorHgU+1WtzC4ZOUIh2WbjWnBrOzgXw8L2/svPO0y3 /6N0K7l+FYSY+i5Q9xikJY3rnDt06bC8DRaRyULblRLpZshSgoD7Mug55D1GnQuAphYH R2sQHncuypG36Uug1bxX43U9dL6BiRgqS/CuYB8dvpuy+3BLC6DRXsPekB/4cSTKa5w/ GMwtOf4xK1IKpeKH6fyLRyCkMK37XrmhQBrVhEH3F+PE5sNiuQ8c+chqCLlJxVaqAOlb t7yz67qh3CWmwQbNIxkVmlGR3AmmMFW08V4bLXR3lVQWxl9pHwglrY7uzlkxyEPpEc+k CpGA== X-Gm-Message-State: ALoCoQnFgQfSMbI8VMpP9p+oVjXClPx49rpkYT/eEQsTWgN8WVWJXeagXo1tjaA9GLsmu12WmrWZ MIME-Version: 1.0 X-Received: by 10.152.4.201 with SMTP id m9mr590947lam.61.1398096014097; Mon, 21 Apr 2014 09:00:14 -0700 (PDT) Received: by 10.112.9.40 with HTTP; Mon, 21 Apr 2014 09:00:14 -0700 (PDT) In-Reply-To: <53546C38.2000901@codesourcery.com> References: <534F294D.4050907@codesourcery.com> <53546C38.2000901@codesourcery.com> Date: Mon, 21 Apr 2014 16:00:00 -0000 Message-ID: Subject: Re: [PATCH] Fix alignment of disassemble /r From: Daniel Gutson To: Yao Qi Cc: Doug Evans , gdb-patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00406.txt.bz2 On Sun, Apr 20, 2014 at 9:54 PM, Yao Qi wrote: > On 04/18/2014 01:27 AM, Daniel Gutson wrote: >> 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? And, > > If you meant "rsp packets" rather than "MI messaging", Yes, my bad, sorry. we don't worry > about the performance much here. disassemble uses code cache > (target_read_code) to read instructions from remote server and the > following read to the same area will hit the cache. > >> what about screen paginig? I shouldn't iterate over all the range, but >> the screen height range only. > > What is the reason do you think we shouldn't iterator over all the > range? IMO=EF=BC=8C screen height and alignment are orthogonal. Suppose your function takes two screens of disassembly. Then suppose that the instructions that fit in the first screen take N bytes at most, and those of the second takes N+k. If I ignore screen paging, I would be aligning the first screen to N+k too, whereas those k are just useless space. It's a minor and cosmetic concern, but I'd like to get it right and pretty in one shot :) Daniel. > > -- > Yao (=E9=BD=90=E5=B0=A7) --=20 Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 C=C3=B3rdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype: dgutson