I got a chance to checkout the start of your Process plug-in.
A few things:
LinuxThread::BreakNotify()
You might want to call into your architecture specific register context and let it
know it hit a breakpoint so you can have it do what it needs to. That way
for i386 and x86_64 you can backup the PC, but for other architectures
you don't have to.
Are you reaping your process after you launch/attach to it with waitpid anywhere?
There is a lldb_private::Host abstraction call to do this if you need that service.
Checkout the Host.h:
Host::StartMonitoringChildProcess(...)
and search for its use in ProcessMacOSX for an example.
ProcessLinux.cpp:74
Is there a reason for the g_process global? You can have more than one process
at a time in LLDB, so it seems like a dangerous variable to keep around. If you
need a global way to locate your process by pid, you can use a static function
in lldb_private::Debugger:
static lldb::TargetSP FindTargetWithProcessID (lldb::pid_t pid);
If you need to lookup a target by any other means globally, let me know and
we can add the needed functionality to a static call in Debugger.
ProcessLinux.cpp:79
Your ProcessLinux constructor shouldn't need to call UpdateLoadedSections()
since when a process is created it isn't alive yet, nor does it have
any connection to a valid live process. DoLaunch will need to be called,
or DoAttach before you would need to call this function. Also there are
functions that get called prior to, and after DoLaunch and DoAttach:
When launching the follwing functions will be called:
virtual Error WillLaunch (...);
virtual Error DoLaunch (...);
virtual void DidLaunch (...);
Likewise with DoAttach:
virtual Error WillAttachToProcessWithID (lldb::pid_t pid);
virtual Error DoAttachToProcessWithID (lldb::pid_t pid);
virtual void DidAttach ();
virtual Error WillAttachToProcessWithName (const char *process_name, bool wait_for_launch)
virtual Error DoAttachToProcessWithName (const char *process_name, bool wait_for_launch)
virtual void DidAttach ();
If any of the Will* functions return an error, the process launch/attach
will stop. If they return succes, then the Do* functions will be called.
If the Do* functions return success, then the Did* functions will be called.
So a good place to do your call to "UpdateLoadedSections()" is in the
DidLaunch() or DidAttach() functions.
There are similar Will*/Do*/Did* functions for detaching, and a few
other things. Many of them have default implementations that do nothing,
but are designed to be overridden so you can do just this kind of stuff.
You will also want to make a DYLD plug-in at some point to take care of
this if you plan to re-use the code that can locate where shared libraries
are loaded in another linux process plug-in (like for remote debugging
using "debugserver"). This way you can just plug your Linux dynamic loader
plug-in into ProcessGDBRemote and all should work (after "debugserver" has
been modified to run on linux that is).
RegisterContextLinux_x86_64:
You will want to fill in a static RegisterInfo array and return valid
values for your registers (See how the other RegisterContext subclasses
in ProcessMacOSX do this).
Other than that, overall it looks pretty good. Feel free to commit your
"source/Plugins/Process/Linux" whenever you can!
Greg
