[Lldb-commits] [lldb] r182153 - ProcessMonitor improvements for Linux.

[Greg Clayton]

On May 17, 2013, at 2:13 PM, "Kopec, Matt" <matt.kopec at intel.com> wrote:

> The trace exec option should tell us that an exec call occurred, so we can inform the user that it happened. It sounds like I can do the steps you mentioned on the linux side as well. Hopefully this won't be too bad in the case of only an exec. However, what should lldb do in the case of a fork/exec? I remember gdb has a setting specifying whether to follow the parent or the child.

If we can detect forks, then we would also need a setting to know if we are supposed to follow forks. If that is set to true and we detect a fork, we will need to create a new target for the forked process, and attach to it and allow the user to control both the first target and the forked targets.

In case you haven't see this feature, you can currently do:

(lldb) file /bin/ls
(lldb) b malloc
(lldb) run
(lldb) file /bin/cat
(lldb) b free
(lldb) run
(lldb) target list

and you will see you have two targets. You can then use "target select 0" and "target select 1" to select between the two targets.

What we don't currently have in LLDB proper management of the console. For instance, if you select target 1 and target 0 was running and it hits a breakpoint. What should happen? Should target 1 become the selected target? Should it stay quiet and only notify that it has stopped when the user selects it? All things we will need to work on.

> 
> Thanks,
> Matt
> 
> On 2013-05-17, at 4:33 PM, Greg Clayton <gclayton at apple.com>
> wrote:
> 
>> Matt: On macosx when a program execs itself into new program, we create a eStopReasonExec thread stop reason. This helps the debugger let the user know that this happened, and it also helps the dynamic loaders clear their shared library lists and do other cleanup that you need to do (throw away all step plans, unresolve all breakpoints/watchpoints, etc).
>> 
>> So you might want to still receive the legacy SIGTRAP signals on exec calls so you know an exec happened? Unless the ProcessMonitor already knows about this in some other way?
>> 
>> Greg Clayton
>> 
>> On May 17, 2013, at 12:27 PM, Matt Kopec <Matt.Kopec at intel.com> wrote:
>> 
>>> Author: mkopec
>>> Date: Fri May 17 14:27:47 2013
>>> New Revision: 182153
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=182153&view=rev
>>> Log:
>>> ProcessMonitor improvements for Linux.
>>> -Remove tracing of fork/vfork until we add support for tracing inferiors' children on Linux.
>>> -Add trace exec option for ptrace so that we don't receive legacy SIGTRAP signals on execve calls.
>>> -Add handling of SIGCHLD sent by kernel (for now, deliver the signal to the inferior).
>>> 
>>> Modified:
>>>  lldb/trunk/source/Plugins/Process/Linux/ProcessMonitor.cpp
>>> 
>>> Modified: lldb/trunk/source/Plugins/Process/Linux/ProcessMonitor.cpp
>>> URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Linux/ProcessMonitor.cpp?rev=182153&r1=182152&r2=182153&view=diff
>>> ==============================================================================
>>> --- lldb/trunk/source/Plugins/Process/Linux/ProcessMonitor.cpp (original)
>>> +++ lldb/trunk/source/Plugins/Process/Linux/ProcessMonitor.cpp Fri May 17 14:27:47 2013
>>> @@ -1208,7 +1208,13 @@ ProcessMonitor::Launch(LaunchArgs *args)
>>>   ptrace_opts |= PTRACE_O_TRACEEXIT;
>>> 
>>>   // Have the tracer trace threads which spawn in the inferior process.
>>> -    ptrace_opts |= PTRACE_O_TRACEFORK | PTRACE_O_TRACEVFORK | PTRACE_O_TRACECLONE;
>>> +    // TODO: if we want to support tracing the inferiors' child, add the
>>> +    // appropriate ptrace flags here (PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK)
>>> +    ptrace_opts |= PTRACE_O_TRACECLONE;
>>> +
>>> +    // Have the tracer notify us before execve returns
>>> +    // (needed to disable legacy SIGTRAP generation)
>>> +    ptrace_opts |= PTRACE_O_TRACEEXEC;
>>> 
>>>   if (PTRACE(PTRACE_SETOPTIONS, pid, NULL, (void*)ptrace_opts, 0) < 0)
>>>   {
>>> @@ -1390,8 +1396,11 @@ ProcessMonitor::MonitorSIGTRAP(ProcessMo
>>>       assert(false && "Unexpected SIGTRAP code!");
>>>       break;
>>> 
>>> -    case (SIGTRAP | (PTRACE_EVENT_FORK << 8)):
>>> -    case (SIGTRAP | (PTRACE_EVENT_VFORK << 8)):
>>> +    // TODO: these two cases are required if we want to support tracing
>>> +    // of the inferiors' children
>>> +    // case (SIGTRAP | (PTRACE_EVENT_FORK << 8)):
>>> +    // case (SIGTRAP | (PTRACE_EVENT_VFORK << 8)):
>>> +
>>>   case (SIGTRAP | (PTRACE_EVENT_CLONE << 8)):
>>>   {
>>>       unsigned long tid = 0;
>>> @@ -1401,6 +1410,11 @@ ProcessMonitor::MonitorSIGTRAP(ProcessMo
>>>       break;
>>>   }
>>> 
>>> +    case (SIGTRAP | (PTRACE_EVENT_EXEC << 8)):
>>> +        // Don't follow the child by default and resume
>>> +        monitor->Resume(pid, SIGCONT);
>>> +        break;
>>> +
>>>   case (SIGTRAP | (PTRACE_EVENT_EXIT << 8)):
>>>   {
>>>       // The inferior process is about to exit.  Maintain the process in a
>>> @@ -1478,6 +1492,17 @@ ProcessMonitor::MonitorSignal(ProcessMon
>>>       return ProcessMessage::Crash(pid, reason, signo, fault_addr);
>>>   }
>>> 
>>> +    if (signo == SIGCHLD) {
>>> +        assert(monitor);
>>> +        // TODO: Implement tracing of inferiors' children
>>> +        // If we fail to deliver the signal then create a message with the signal
>>> +        if (!monitor->Resume(pid, signo)) {
>>> +            assert(0 && "SIGCHLD delivery failed");
>>> +            message = ProcessMessage::Signal(pid, signo);
>>> +        }
>>> +        return message;
>>> +    }
>>> +
>>>   // Everything else is "normal" and does not require any special action on
>>>   // our part.
>>>   return ProcessMessage::Signal(pid, signo);
>>> 
>>> 
>>> _______________________________________________
>>> lldb-commits mailing list
>>> lldb-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
>> 
>