From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2020 invoked by alias); 18 Oct 2013 10:24:09 -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 2011 invoked by uid 89); 18 Oct 2013 10:24:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.2 required=5.0 tests=AWL,BAYES_00,GARBLED_BODY autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 18 Oct 2013 10:24:08 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1VX7Dw-0007ZY-2S from Yao_Qi@mentor.com ; Fri, 18 Oct 2013 03:24:04 -0700 Received: from SVR-ORW-FEM-05.mgc.mentorg.com ([147.34.97.43]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Oct 2013 03:24:03 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.2.247.3; Fri, 18 Oct 2013 03:24:03 -0700 Message-ID: <52610BF7.8000605@codesourcery.com> Date: Fri, 18 Oct 2013 10:24:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Pedro Alves 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> In-Reply-To: <525E81B8.90003@redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00553.txt.bz2 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? -- Yao (齐尧)