[lldb-dev] Critique of Linux DoReadMemory implementation

[Matthew Gardiner]

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 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()?
Fair enough. Totally agree with the engineering principle "if it ain't broke, don't fix".

I guess this debate is best reserved until the day comes when block reads are noticeably slow, and profiling points to a finger of suspicion towards ptrace.

FWIW I'd imagine file access from a tracer onto a tracee's proc file to be the same as ptracing, regarding permissions. But don't quote me on that!

thanks
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.