[lldb-dev] Critique of Linux DoReadMemory implementation
piotr.rak at gmail.com
Tue Feb 25 08:52:59 PST 2014
In any case ptrace(PTRACE_PEEKDATA, ) should be left as fallback, at least
Your debugger might CAP_SYS_PTRACE, that would allow it read memory of an
process running with different UID, and it won't be possible with
It is also very popular for LSM's or hardening patches floating around to
disable access to process memory via proc at all.
So I see that more as optimization rather than replacement.
2014-02-25 10:31 GMT+01:00 Matthew Gardiner <mg11 at csr.com>:
> Is there a good reason why the DoReadMemory function of
> Linux/ProcessMonitor.cpp is implemented using multiple calls of
> ptrace(PTRACE_PEEKDATA, ...) ?
> An easier, and less CPU-intensive way is to read the memory using the proc
> filesystem. The inferior's memory will be available in the file
> int fd = open("/proc/<pid>/mem", O_RDONLY);
> ssize_t bytes = read(fd, buf, count);
> The read-of-procfs just seems more succinct to me, so I wondered what the
> rationale was for not using this.
> Discussion welcomed,
> Member of the CSR plc group of companies. CSR plc registered in England
> and Wales, registered number 4187346, registered office Churchill House,
> Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
> More information can be found at www.csr.com. Keep up to date with CSR on
> our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people,
> YouTube, www.youtube.com/user/CSRplc, Facebook,
> www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
> New for 2014, you can now access the wide range of products powered by
> aptX at www.aptx.com.
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev