Linux process plugin

Subprojects LLDB
1

I think,I need some help getting the linux process plugin working. Getting it compiling was easy so far, but it won't work,
and for me its not easy too see how its supposed to work either.
First of all, why does it run the inferior in a pty? I don't see why we would need an entire terminal there.
Secondly, why is there one thread per fd afterwards?

Basicly it does pretty much nothing:
(lldb) r
Launching '/tmp/crashd/a.out' (x86_64)
(lldb)
it randomly works after a few times, but only results in a visible effect when the inferior crashes.
It then tries to send a message to the crashed process, which crashes lldb. There is a FIXME in there,
but why is this on a seperate thread in the first place?

2

I think,I need some help getting the linux process plugin working. Getting it compiling was easy so far, but it won't work,
and for me its not easy too see how its supposed to work either.
First of all, why does it run the inferior in a pty? I don't see why we would need an entire terminal there.

On MacOSX we hand a pty to our inferior using posix_spawn file attributes and we run a single read thread to watch for the input. We use a pty by default to stay as close to what would be run in a terminal. You can specify the file handles you want the inferior to use in process launch:

process launch --stdin /dev/null --stdout /dev/null --stderr /dev/null ....

Secondly, why is there one thread per fd afterwards?

Not sure why linux would be running three threads.

Basicly it does pretty much nothing:
(lldb) r
Launching '/tmp/crashd/a.out' (x86_64)
(lldb)
it randomly works after a few times, but only results in a visible effect when the inferior crashes.
It then tries to send a message to the crashed process, which crashes lldb. There is a FIXME in there,
but why is this on a seperate thread in the first place?

Eli Friedman was the person leading the linux port, so I will have to defer linux questions to him.

I believe the linux plug-in also needs to get a DynamicLoader plug-in created for it at some point so that shared library loads/unloads can be detected and breakpoints in shared libraries will work.

You can see all of the logging that you can enable:

(lldb) log list

Each plug-in that is installed can install named logged channels that can have multiple categories.

There is a lot of internal logging you can enable to see what might be going on:

(lldb) log enable lldb default

Then try and run and see if you see anything obvious. The linux plug-in should add its own logging channel so the details of the debug session can be logged when things go wrong.

Greg Clayton

3

<arvid.picciani@nokia.com> writes:

I think,I need some help getting the linux process plugin
working. Getting it compiling was easy so far, but it won't work, and
for me its not easy too see how its supposed to work either. First of
all, why does it run the inferior in a pty? I don't see why we would
need an entire terminal there.

As Greg mentioned, to have a complete environment for the debugged
process. A good example of how this can make a difference is with some
of the LLVM tools which do not like to emit binary data to stdout when
connected to a PTY.

Secondly, why is there one thread per fd afterwards?

Not per fd. The main issue under Linux is that ptrace() can only be
called from the thread which originally fork()'ed or attached to the
inferior process. In LLDB operations on the inferior (like setting a
breakpoint, say) can originate from an "arbitrary" thread.

The linux plugin handles this by establishing a ProcessMonitor -- a
thread which forks the inferior then "serves" operations on it in a
thread safe fashion.

The heart of this strategy is implemented in
ProcessMonitor::ServeOperation. This routine waits on a full duplex
pipe and reads pointers to instances of the Operation class. The
virtual method Operation::Execute implements a particular capability of
the ptrace() syscall -- when the server invokes this method the
corresponding ptrace() is executed in the correct thread context.

Basicly it does pretty much nothing:
(lldb) r
Launching '/tmp/crashd/a.out' (x86_64)
(lldb)
it randomly works after a few times, but only results in a visible effect when the inferior crashes.
It then tries to send a message to the crashed process, which crashes lldb. There is a FIXME in there,
but why is this on a seperate thread in the first place?

There never was much functionality even before the plugin bitrotted --
we could start an inferior, set and step over breakpoints. There was no
support for dynamic libraries.

Unfortunately I have been swamped with a work project for the last few
weeks and have not been keeping my builds of LLDB up to date. I will
try to find some time this weekend to get back up to speed on the state
of the plugin and see what I can do to get it back on its feet.

4

The heart of this strategy is implemented in
ProcessMonitor::ServeOperation. This routine waits on a full duplex
pipe and reads pointers to instances of the Operation class. The
virtual method Operation::Execute implements a particular capability of
the ptrace() syscall -- when the server invokes this method the
corresponding ptrace() is executed in the correct thread context.

I see, thanks for that explanation.

There never was much functionality even before the plugin bitrotted --
we could start an inferior, set and step over breakpoints. There was no
support for dynamic libraries.

That sounds trivial to implement from there. unloading/loading notification
seems to be all thats missing.

Unfortunately I have been swamped with a work project for the last few
weeks and have not been keeping my builds of LLDB up to date. I will
try to find some time this weekend to get back up to speed on the state
of the plugin and see what I can do to get it back on its feet.

Are you guys on irc somewhere? I found a few contributors on oftc, but
none really who sounded like picking up the lead of a linux port.

5

<arvid.picciani@nokia.com> writes:

Are you guys on irc somewhere? I found a few contributors on oftc, but
none really who sounded like picking up the lead of a linux port.

I have not been on there much lately -- will start hanging out again
mostly in the evenings (EDT) with nick swilson.