On Jul 21, 2010, at 11:39 AM, Stephen Wilson wrote:
>
> Hi all!
>
> This is a quick update on some work I have been doing on the linux
> front, specifically a Process plugin for that platform.
>
> The current effort is still at an early stage. In short, we can launch
> an inferior process and set/step-over breakpoints.
>
> However, I am thinking about merging this initial work into the tree
> sooner rather than later to avoid dumping a huge patch on everyone at a
> later time. Although *not quite ready*, you can see the current plugin
> code here:
>
> http://github.com/ice799/lldb/tree/swilson-process/source/Plugins/Process/Linux
>
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
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
