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/<pid>/mem. 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.
Cheers, /Piotr 2014-02-25 10:31 GMT+01:00 Matthew Gardiner <[email protected]>: > 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 file > > /proc/<pid>/mem > > 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, > Matt > > > > 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 > www.twitter.com/CSR_plc. > New for 2014, you can now access the wide range of products powered by > aptX at www.aptx.com. > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
