From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30829 invoked by alias); 15 Oct 2013 00:44:26 -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 30820 invoked by uid 89); 15 Oct 2013 00:44:26 -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; Tue, 15 Oct 2013 00:44:25 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1VVskH-0006R0-DS from Yao_Qi@mentor.com ; Mon, 14 Oct 2013 17:44:21 -0700 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Oct 2013 17:44:21 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.2.247.3; Mon, 14 Oct 2013 17:44:20 -0700 Message-ID: <525C8F92.8080307@codesourcery.com> Date: Tue, 15 Oct 2013 00:44: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: Mark Kettenis , Subject: Re: [PATCH 0/7 V2] Trust readonly sections if target has memory protection References: <1378432920-7731-1-git-send-email-yao@codesourcery.com> <1378641807-24256-1-git-send-email-yao@codesourcery.com> <201309091916.r89JGbpf009986@glazunov.sibelius.xs4all.nl> <522E9A8A.7040509@codesourcery.com> <52317B66.3020602@codesourcery.com> <201309120949.r8C9nFsJ016506@glazunov.sibelius.xs4all.nl> <5232C9EC.2040707@codesourcery.com> <5249B9F9.4030901@redhat.com> In-Reply-To: <5249B9F9.4030901@redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00450.txt.bz2 On 10/01/2013 01:50 AM, Pedro Alves wrote: > I've been background-thinking about taking a step back and understand > why each use case that is sped up with this patch is slow to begin with. > That is, the series jumps to a solution, but we haven't done our due diligence > with analyzing the problem thoroughly, IMO. E.g., for the disassembly use Due diligence was done, but in a different way :). Option "trust-readonly-sections" was mentioned to improve the performance of remote debugging and "turning it on in default" was discussed when this option was added. We didn't turn it on in default because of bad code on non-memory protection systems. V1 follows this idea to let GDB to know which targets are memory protection systems. > case, presented in the v1 series, I'd think that the problem is that GDB is > fetching data off the target instruction by instruction, instead of requesting > a block of memory and working with that. More aggressive over fetching > could be a better/safer approach. I agree. > > We have similar infrastructure already, in dcache.c -- we use > it for stack memory nowadays, and if the memory region is marked as > cacheable. We used to support caching more than just stack, but > that was never enabled by default because it may not be safe to > read memory outside of the range the caller is specifying, because of > things like memory mapped registers, etc. (In the case of stack, we assume > stack is allocated in page chunks, so that dcache never steps on memory is > should not). But in cases like disassembly, we're being driven by debug > info or user input. As GDB knows upfront the whole range of memory it'll > be fetching, accessing a bigger chunk upfront, as long as it doesn't > step out of the range we read piecemeal anyway, should have no effect > on correctness. We have to improve dcache.c at first. Nowadays, dcache requests one cache line from the target in one time, regardless the actual size of memory requested. -- Yao (齐尧)