<div><blockquote>On Mon, Mar 14, 2011 at 11:11 PM, Stephen Wilson <<a href="mailto:wilsons@start.ca">wilsons@start.ca</a>> wrote:<br>Well, in a nutshell you would need to implement something similar to<br>what ProcessLinux::DoLaunch does, but in this case you want things to<br>
boil down to a ptrace(ATTACH) instead of a fork() + ptrace(TRACEME).<br>The basic sketch would be:<br> - Define a new ProcessMonitor ctor that takes a pid as argument.<br> - Define ProcessMonitor::Attach which does the actual ptrace magic.<br>
- Write a another StartOperationThread method that takes a (new)<br> AttachArgs struct as argument (could just contain the pid for now)<br> and sets up the monitoring business in essentially the same way as<br> the current launch-based code does. Probably rename<br>
OperationThread to LaunchOpThread or similar and write your own<br> AttachOpThread analog.<br>It would certainly be nice to have that implemented. I do not see<br>anything that would cause any complications off hand, and it should<br>
remain fairly isolated from all the other work that needs to happen wrt<br>linux support.</blockquote></div><div><br></div><div><br></div><div>Thanks Steve! I scoped out the work a little bit, mostly by stepping through in the debuggers both the Xcode version and the current Linux version. Btw it looks like the current version of lldb has been incremented (now r127600), which is very good news.</div>
<div><br></div><div>I note that the main contrast is this: the darwin built lldb uses the ProcessGDBRemote class, implemented in the "llvm/tools/lldb/source/Plugins/Process/gdb-remote" directory, rather than ProcessLinux.</div>
<div><br></div><div>The curious thing is: when I look through the gdb-remote code, there are only two lines that are #ifdef APPLE. It seems fairly reusable.</div><div><br></div><div>My naive question then is, why not just reuse the ProcessGDBRemote code for Linux as well? There's probably higher level design issues that I'm not familiar with, so anyone on lldb-dev should feel free to chime in here. The second lazy inclination is to just port that code to linux if it must go in it's own directory.</div>
<div><br></div><div>Let me know what you think. I'm probably asking silly questions, but I'm just trying to get my bearings. Please bear with me! :-)</div><div><br></div><div>Thanks,</div><div>Jason</div><div><br>
</div><div>p.s. the one thing that kept me from trying this directly was figuring out where in the Makefile system this got chosen, because by default on linux, the gdb-remote directory isn't built. If anyone knows where this controlled, please point it out. Thank you!</div>
<br>