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 call it
with a _multiple_ of 512 byte reads so we can do large memory reads all at
once, yet still maintain the caching. The biggest issue is some process
subclasses, like ProcessGDBRemote, are often communicating with remote GDB
servers that can't read that much at a time. Sometimes the remote GDB servers
have fixed size buffers that allow for packets to be up to a fix size in the
responses, so any change we do would need to probably ask the
lldb_private::Process subclass what its max memory read size is with a new pure
virtual lldb_private::Process function:
class Process {
virtual uint64_t GetMaxMemoryReadByteSize() = 0;
};
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 user, you might run into permissions
problems. We know ptrace always works, so I would say "don't fix what isn't
broken" unless you find some serious performance issues with ptrace vs the file
mapped proc/<pid>/mem approach. Another issue you might run into is threading
issues with the file position on the "fd" returned from
'open("/proc/<pid>/mem", O_RDONLY);' If one thread tries to read from address
0x1000, and another reads from 0x2000, you can run into issues. Of course you
can use pread, but again, why switch from ptace()?
Greg
On Feb 25, 2014, at 1:31 AM, Matthew Gardiner <[email protected]> wrote:
> 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
