Hello, Now that PaX MPROTECT is the default on 3 platforms (amd64, i386, and evbarm) the problem of software breakpoints and gdb has surfaced. Namely if MPROTECT is on, and you try to set a breakpoint you get:
(gdb) break main Breakpoint 1 at 0x107e0: file aslr.c, line 8. (gdb) r Starting program: /u/christos/a.out Warning: Cannot insert breakpoint 1. Cannot access memory at address 0x107e0 Cannot insert breakpoint -1. Temporarily disabling shared library breakpoints: breakpoint #-1 Gdb tries to write the breakpoint instruction in the text segment, uvm_io() calls uvm_map_extract(... | UVM_EXTRACT_FIXPROT), but the max protection for the text segment does not allow writes anymore. There are three solutions I can think of (maybe you can think of a better one): 1. Leave it as it is and document that people will have to paxctl +m the executables that they need to mprotect before they can debug it. 2. create a uvm_io1() and a new UVM_EXTRACT that breaks MPROTECT and fetches with the right mappings. I don't like that, it breaks MPROTECT and uvm contracts. But it has the advantage of working on already started process we PT_ATTACH to. 3. when process is execed and is already traced (PT_TRACE_ME), disable MPROTECT. This should work with processes started from gdb, but not attached ones. We will still need to explain that to attach and insert breakpoints you need to set MPROTECT off. Opinions? christos