From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4345 invoked by alias); 18 Oct 2013 18:25:40 -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 4331 invoked by uid 89); 18 Oct 2013 18:25:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 18 Oct 2013 18:25:39 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9IIPXk2028831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Oct 2013 14:25:33 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r9IIPUpK000341; Fri, 18 Oct 2013 14:25:31 -0400 Message-ID: <52617D1A.6010600@redhat.com> Date: Fri, 18 Oct 2013 18:25:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yao Qi CC: Doug Evans , "Abid, Hafiz" , "gdb-patches@sourceware.org" , "Mirza, Taimoor" Subject: Re: [patch] Disassembly improvements References: <525C02E5.2060601@redhat.com> <21085.59640.697075.435874@ruffy.mtv.corp.google.com> <525E4596.70503@codesourcery.com> <525E81B8.90003@redhat.com> <52610BF7.8000605@codesourcery.com> In-Reply-To: <52610BF7.8000605@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-10/txt/msg00579.txt.bz2 On 10/18/2013 11:22 AM, Yao Qi wrote: > On 10/16/2013 08:08 PM, Pedro Alves wrote: >> Yeah, adding the new target object part is straightforward. What >> may not be, is either adjusting the dcache.c to the specifics of >> disassembly, and range limiting, and making sure the cache is bounded >> correctly, and flushed at the appropriate times. It's one of those >> "must try it to tell" things, I think. > > Pedro, > I start to think about it today. I don't see we have to adjust dcache.c > for disassembly and worry about the range. From GDB's point of view, > the process of reading a piece of stack memory should be identical to > reading a piece of code memory. We are using ' > target_dcache' to cache stack memory, so we can also reuse it to cache > code memory. Am I missing something? Hmm, the idea was that having "disassemble $foo, $bar" read outside [$foo,$bar) might not be safe (particularly so if the line size is set large), as it might trip on memory mapped registers, which might have side effects when read. I guess I could be convinced that this is overzealous? BTW, how will your "Read memory in multiple lines in dcache_xfer_memory" series help disassembly if the disassembler, today, without that other patch that caches things in disasm.c, fetches memory from the target instruction by instruction? Seems to me it'll end up always fetching a single line at a time. -- Pedro Alves