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.
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
