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

[Ted Woodward via lldb-dev]

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.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


___
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

[Kamil Rytarowski via lldb-dev]

On 17.03.2017 10:48, Pavel Labath wrote:
> On 16 March 2017 at 21:43, Kamil Rytarowski >
>> 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> > wrote:
>> On 16.03.2017 11:55, Pavel Labath wrote:
>>> What kind of per-process events
>>> are we talking about here?
>>
>> I'm mostly thinking about ResumeActions - to resume the whole process,
>> while being able single-stepping desired thread(s).
>>
>> (We also offer PT_SYSCALL feature, but it's not needed right now in LLDB).
>>
>>> Is there anything more here than a signal
>>> directed at the whole process?
>>
>> single-stepping
>> resume thread
>> suspend thread
>>
>> I'm evaluating FreeBSD-like API PT_SETSTEP/PT_CLEARSTEP for NetBSD. It
>> marks a thread for single-stepping. This code is needed to allow us to
>> combine PT_SYSCALL & PT_STEP and PT_STEP & emit signal.
>>
>> I was thinking about ResumeActions marking which thread to
>> resume/suspend/singlestep, whether to emit a signal (one per global
>> PT_CONTINUE[/PT_SYSCALL]) and whether to resume the whole thread.
>>
>> To some certain point it might be kludged with single-thread model for
>> basic debugging.
>>_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).
> 

Right. I also don't expect the LLDB client to export so fine-grained
commands for a user. I don't think that it would be appropriate in C-API
either. Something similar to "set scheduler-lock on" from GDB, with
single-step option sounds fine for my purposes.

I was thinking about a division between setting thread plan and resuming
the execution. We will be back to it once I will be working on threads.

> So I don't believe there will be any sweeping changes necessary to
> support this in the future. If I understand it correctly, you are
> working on the server now. All you need to do there is to make sure you
> translate the set of actions in the packet to the proper sequence of
> ptrace calls. You can even write lldb-server-style tests for that. Then,
> we can discuss what would be the best user-level interface to specify
> complex actions like this, and teach the client to send these packets.
> 

I see, makes sense.

>>
>>> AFAICT, most of the stop reasons
>>> (breakpoint, watchpoint, single step, ...) are still linked to a
>>> specific thread even in your process model. I think you could get to a
>>> point where lldb is very useful even without getting these events
>>> "correct".
>>>
>>
>> I was thinking for example about this change (it's not following the
>> real function name nor the prototype):
>>
>>   GetStoppedReason(Thread) -> GetStoppedReason(Process,Thread)
>>
>> The Linux code would easily route it to desired thread and (Net)BSD
>> return immediately the requested data. The need to have these functions
>> in NativeThread (enforced by the framework) is the only purpose I keep
>> them there, while there is global stopped reason on NetBSD (per-process).
> 
> Ok, I think we can talk about tweaks like that once you have something
> upstream. Right now it does not seem to me like that should pose a big
> development obstacle.
> 

It might be similar with hardware assisted watchpoints, but let's
discuss it later.

> 
> In my local code, I'm populating all threads within the tracee
> (NativeThread) with exactly the same stop reason - for the "whole
> process" case. I can see - on the client side - that it prints out the
> same message for each thread within the process as all of them captured
> a stop action.
> 
> 
> Indeed, that can be a nuissance. The whole-process events is probably
> the first thing we should look at after the port is operational. I think
> this can be handled independently of the fancy resume actions we talk
> about above, which as 

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

[Kamil Rytarowski via lldb-dev]

On 17.03.2017 01:37, Jim Ingham wrote:
> The main consumer of thread stop reasons is the execution control 
> (ThreadPlans - which handle stepping & function calling - and 
> StopInfo::PerformAction which handles breakpoint/watchpoint hits).  The only 
> bad effect of populating all the threads with the whole process signals is if 
> any of the plans did anything special with that signal.  Some of the thread 
> plans do care about a few signals, but those are mostly SIGSEGV and the like 
> (the function calling plans care about this.)  I can't see what it would mean 
> to send a whole process SIGSEGV, however, that seems like it is always going 
> to be a thread specific thing.  Ditto for however you see a breakpoint hit 
> (SIGTRAP?)  Those really have to be thread specific...
> 
> I can't think of anything else this would really affect, so going forward 
> with your "process => all threads" fiction is probably fine for a first pass.
> 
> Jim
> 

Thank you for your analysis.

I can check siginfo(2) of each signal and verify it. ptrace(2)
(PT_GET_SIGINFO) gives me destination of a signal:
specific-thread/all-threads. The siginfo(2) structures gives signal's
source/reason. For example si_code can contain SI_USER for kill(2),
SI_QUEUE for sigqueue(2) etc.

Hypothetically someone would pass SIGSEGV manually for the whole process
- eg. using the kill(1) command - but it's rather anomaly and I don't
expect a debugger to have a defined behavior for such events. I would
just pass that sort of signals to the child and ignore in the
MonitorCallback code.

The NetBSD version of raise(3) uses _lwp_kill(2) a LWP-specific kill(2)
to emit a signal to a specified thread within the same process. Just for
sake of curiosity - the FreeBSD LLDB code breaks (assert(3) fires) after
calling "raise(SIGTRAP)" from the child.



signature.asc
Description: OpenPGP digital signature
___
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 16 March 2017 at 21:43, Kamil Rytarowski  wrote:
> On 16.03.2017 11:55, Pavel Labath wrote:
>> What kind of per-process events
>> are we talking about here?
>
> I'm mostly thinking about ResumeActions - to resume the whole process,
> while being able single-stepping desired thread(s).
>
> (We also offer PT_SYSCALL feature, but it's not needed right now in LLDB).
>
>> Is there anything more here than a signal
>> directed at the whole process?
>
> single-stepping
> resume thread
> suspend thread
>
> I'm evaluating FreeBSD-like API PT_SETSTEP/PT_CLEARSTEP for NetBSD. It
> marks a thread for single-stepping. This code is needed to allow us to
> combine PT_SYSCALL & PT_STEP and PT_STEP & emit signal.
>
> I was thinking about ResumeActions marking which thread to
> resume/suspend/singlestep, whether to emit a signal (one per global
> PT_CONTINUE[/PT_SYSCALL]) and whether to resume the whole thread.
>
> To some certain point it might be kludged with single-thread model for
> basic debugging.
>
>
> 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).

So I don't believe there will be any sweeping changes necessary to support
this in the future. If I understand it correctly, you are working on the
server now. All you need to do there is to make sure you translate the set
of actions in the packet to the proper sequence of ptrace calls. You can
even write lldb-server-style tests for that. Then, we can discuss what
would be the best user-level interface to specify complex actions like
this, and teach the client to send these packets.

>
>> AFAICT, most of the stop reasons
>> (breakpoint, watchpoint, single step, ...) are still linked to a
>> specific thread even in your process model. I think you could get to a
>> point where lldb is very useful even without getting these events
>> "correct".
>>
>
> I was thinking for example about this change (it's not following the
> real function name nor the prototype):
>
>   GetStoppedReason(Thread) -> GetStoppedReason(Process,Thread)
>
> The Linux code would easily route it to desired thread and (Net)BSD
> return immediately the requested data. The need to have these functions
> in NativeThread (enforced by the framework) is the only purpose I keep
> them there, while there is global stopped reason on NetBSD (per-process).

Ok, I think we can talk about tweaks like that once you have something
upstream. Right now it does not seem to me like that should pose a big
development obstacle.


> In my local code, I'm populating all threads within the tracee
> (NativeThread) with exactly the same stop reason - for the "whole
> process" case. I can see - on the client side - that it prints out the
> same message for each thread within the process as all of them captured
> a stop action.


Indeed, that can be a nuissance. The whole-process events is probably the
first thing we should look at after the port is operational. I think this
can be handled independently of the fancy resume actions we talk about
above, which as Jim pointed out, would be very hard for users to comprehend
anyway.

I'm evaluating it from the point of view of a tracee with 10.000 threads
> and getting efficient debugging experience. This is why I would ideally
> reduce NativeThread to a container that is sorted, hashale box of
> integers (lwpid_t) and shut down stopped reason extension called for
> each stopped in debuggee.
>


I wouldn't worry too much about the performance of this part of the code.
If you get to the point where you debug a process with ten thousand
threads, I think you'll find that there are other things which are causing
performance problems.


On 16 March 2017 at 21:43, Kamil Rytarowski  wrote:

> On 16.03.2017 11:55, Pavel 

Re: [lldb-dev] LLVM social in Sweden?

[Diana Picus via lldb-dev]

Hi everyone,

We have started a meetup page for LLVM socials in Sweden [1]. Thanks
to those that have already joined!

We're going to keep most of the communication there from now on.
Hopefully towards the end of next week I'll post another Doodle for
scheduling the next event, which will take place somewhere in
Stockholm [2].

We'd like to have some talks this time around, so if you're interested
in giving one please let us know, either on the meetup page or by
email. It can be as formal or informal as you want, and lightning
talks are also welcome. Note that it doesn't have to be about your
work, it can also be a tutorial, or a presentation of a problem that
you've encountered while working with LLVM, or generally anything that
you'd like to share with other LLVM devs/users.

Even if you don't want to give a talk, you can feel free to suggest
topics that are interesting to you, and maybe someone else will pick
them up, or we can have some free-form discussions about them.

See you around,
Diana

PS: Sorry about cross-posting, just getting the word out.

[1] https://www.meetup.com/LLVM-Clang-Sweden-socials/
[2] If you're from another area, please feel free to start a
discussion on meetup and we'll see if we can manage to get a few of us
there.

On 13 March 2017 at 10:00, Roberto Castañeda Lozano  wrote:
> Hi all,
>
> You can find how to get to SICS Kista here:
> https://www.sics.se/contact/sics-stockholm . We are located at level 6,
> elevator B. Just mention at the reception that you are attending the LLVM
> social event held in the "Knuth" meeting room.
>
> See you on Wed!
>
> Roberto
>
>
> On 2017-03-06 14:41, Diana Picus via llvm-dev wrote:
>>
>> Hi all,
>>
>> Based on the answers in the poll, it looks like a good time to hold
>> the social is on Wednesday, March 15th, around 12 o'clock. Sorry to
>> those that can't make it.
>>
>> SICS have offered to host us at their office in Kista [1]. Roberto
>> (CC'ed) can give us more details on how to find the meeting room
>> (which is booked until 5 PM, so don't worry if you're going to be a
>> bit late). They are also providing pizzas and (non-alcoholic) drinks,
>> so please let us know if you have any preferences / special requests
>> regarding that.
>>
>> Thanks again to SICS!
>>
>> See you there,
>> Diana
>>
>> [1] https://www.sics.se/contact/sics-stockholm
>>
>> On 27 February 2017 at 11:22, Diana Picus  wrote:
>>>
>>> Hi all,
>>>
>>> Thanks for the answers! I've also received a couple of answers
>>> off-list, so there should be enough of us to get something rolling.
>>>
>>> I think we should start with something informal to get to know each
>>> other and see what our interests are etc. So, I've created a poll with
>>> a random slice of March here [1], so we can sync on the date / time.
>>> Please pick as many options as you can. The times are just ballpark
>>> estimates, I'm trying to cover different scenarios in case people have
>>> to take trains or have other constraints. Just pick whatever's closer
>>> to what you prefer, and we'll settle on something more specific later
>>> on. If you can't make it, please say so and we can try to do this in
>>> April instead, so we can have more time to plan.
>>>
>>> I'm thinking of leaving this up for a week or so before deciding
>>> something, but if you need to know sooner please say so.
>>>
>>> Also, any suggestions for venues are appreciated!
>>>
>>> Thanks,
>>> Diana
>>>
>>> [1] http://doodle.com/poll/cfp7i7x98ad82h88
>>>
>>> On 23 February 2017 at 11:58, Roberto Castañeda Lozano 
>>> wrote:

 On 2017-02-17 13:26, Diana Picus via llvm-dev wrote:
>
>
> Hey,
>
> Anyone interested in organizing a meetup in Sweden? I'm based in
> Stockholm, but I don't mind traveling around on a weekend if people
> prefer to gather elsewhere.
>
> Cheers,
> Diana
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



 Hi Diana,

 I and probably some others from SICS (Swedish Institute of Computer
 Science)
 would be interested, we are based in Kista.

 Cheers,

 Roberto

 --
 Roberto Castañeda Lozano
 Researcher @ SICS, PhD student @ KTH
 www.sics.se/~rcas
>>
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
> --
> Roberto Castañeda Lozano
> Researcher @ SICS, PhD student @ KTH
> www.sics.se/~rcas
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev