Re: [PATCH 0/7 V2] Trust readonly sections if target has memory protection

[Yao Qi <yao@codesourcery.com>]

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 (齐尧)