From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22893 invoked by alias); 12 Sep 2013 08:30:23 -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 22883 invoked by uid 89); 12 Sep 2013 08:30:22 -0000 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; Thu, 12 Sep 2013 08:30:22 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00,GARBLED_BODY,KHOP_THREADED,RDNS_NONE,SPF_HELO_FAIL autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1VK2I5-0005zf-I5 from Yao_Qi@mentor.com ; Thu, 12 Sep 2013 01:30:17 -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); Thu, 12 Sep 2013 01:30:17 -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; Thu, 12 Sep 2013 01:30:15 -0700 Message-ID: <52317B66.3020602@codesourcery.com> Date: Thu, 12 Sep 2013 08:30: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: Mark Kettenis CC: 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> In-Reply-To: <522E9A8A.7040509@codesourcery.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00375.txt.bz2 On 09/10/2013 12:05 PM, Yao Qi wrote: >> Even on systems that have an MMU that can mark pages read-only, system >> >calls like mprotect(2) can be used to make read-only pages >> >(temporarily) writable. This is done by the OpenBSD dynamic linker >> >during relocation processing. I expect other systems implementing >> >strict W^X to do the same. Enabling trust-readonly-sections on such >> >systems would be a bad idea. > If GDB can monitor mprotect syscall, it can still trust readonly > sections if their pages are not changed to writable by mprotect. > > GDB is able to 'catch syscall mprotect', only on linux-nat > unfortunately. It doesn't work on remote target > > "catch syscall" support in the remote protocol > https://sourceware.org/bugzilla/show_bug.cgi?id=13585 > > Similarly, GDB can monitor function VirtualProtect on Windows target > too. Do we have a concrete criteria to reject or accept this patch series? I need this to plan for my next step. Here are some possibilities in my brain, 1. This series is rejected because GDB is incorrect when program uses mprotect and change some readonly pages, unless.... 2. ... GDB is able to monitor syscall mprotect, and trust readonly sections if they are still readonly in the process's space. 3. This series can be accepted. I am wondering how popular that user program modifies readonly sections in process space by mprotect. Do we really sacrifice the performance of GDB in some common cases, like remote debugging, for this corner case? I'd like to add doc for the case using mprotect and remind user to turn trust-readonly-sections off by him/her self. -- Yao (齐尧)