Greg Clayton wrote:
As for using ptrace versus using file mapping, I would stick with ptrace unless you have a valid reason to do so. Using
seek + read on a file descriptor seems like a hack that is kinda cool, but as someone else already mentioned, when you
are debugging a process of another
Currently, because of memory caching, lldb_private::Process::ReadMemory() will
break up memory reads into 512 byte requests to the pure virtual
lldb_private::Process::DoReadMemory() function and cache each 512 byte block of
data that comes back. We should modify the caller of DoReadMemory to cal
Hi,
In any case ptrace(PTRACE_PEEKDATA, ) should be left as fallback, at least
for attaching.
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
/proc//mem.
It is also very popular for LSM's or hardening patch
Folks,
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 fil
