[lldb-dev] GSoC 2017 Student Applications are Open

[Anton Korobeynikov via lldb-dev]

Dear Prospective GSoC Students,

The student applications website is currently open!

While you can submit your proposals directly there we strongly suggest
you to submit, refine and discuss your proposals via the corresponding
mailing lists.

The "Open Projects" page at http://llvm.org/OpenProjects.html has some
ideas for may-be projects. However, you could also submit your own
project provided that the proposal is strong enough.

Please do not forget to indicate your current familiarity with LLVM
and whether you already contributed to any of its subprojects.

Have luck!

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB/NetBSD extended set of tasks

[Pavel Labath via lldb-dev]

On 17 March 2017 at 16:23, Ted Woodward  wrote:

>
>
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of
> Pavel Labath via lldb-dev
> Sent: Friday, March 17, 2017 4:48 AM
>
> > On 16 March 2017 at 21:43, Kamil Rytarowski  wrote:
> >> I imagined a possible flow of ResumeAction calls like:
> >> [Generic/Native framework knows upfront the image of threads within
> >> debuggee]
> >>  - Resume Thread 2 (PT_RESUME)
> >>  - Suspend Thread 3 (PT_SUSPEND)
> >>  - Set single-step Thread 2 (PT_SETSTEP)
> >>  - Set single-step Thread 4 (PT_SETSTEP)
> >>  - Clear single-step Thread 5 (PT_CLEARSTEP)
> >>  - Resume & emit signal SIGIO (PT_CONTINUE)
> >>
> >> In other words: setting properties on threads and pushing the
> >> PT_CONTINUE button at the end.
>
> > None of this is really NetBSD-specific, except the whole-process signal
> at the end (which I am going to ignore for now). I mean, the implementation
> of it is different, but there is no reason why someone would not want to
> perform the same set of actions on Linux for instance. I think most of the
> work here should be done on the client. Then, when the user issues the
> final "continue", the client sends something like $vCont;s:2;s:4;c:5. Then
> it's up to the server to figure out how execute these actions. On NetBSD it
> would execute the operations you mention above, while on linux it would do
> something like ptrace(PTRACE_SINGLESTEP, 2); ptrace(PTRACE_SINGLESTEP, 4);
> ptrace(PTRACE_CONTINUE, 5); (linux lldb-server already supports this
> actually, although you may have a hard time convincing the client to send a
> packet like that).
>
> The big problem with this sequence is non-stop mode. To continue thread 5
> while threads 2 and 4 are stepping, and thread 3 is stopped is not legal
> using all-stop mode. lldb only supports non-stop mode in the gdb-remote
> communications layer; the guts of the debugger do not support it, and could
> get very confused when threads 2 and 4 stop, but thread 5 is still running.
>
>
I think these are actually two different concepts you are conflating here.
The non-stop mode is about "what happens when an event happens on one
thread" -- on all-stop we stop all threads (that happen to be running), in
non-stop we only stop the affected thread.  Lldb handles the first, but not
the second. However, this is different from deciding which threads will get
a chance to run in the first place. The sequence of commands we talked
about above is probably not possible, but you can certainly choose to run
only a subset of threads (e.g. with SBThread::Suspend), and this should
work fine in current lldb.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev