On 17.03.2017 10:48, Pavel Labath wrote: > On 16 March 2017 at 21:43, Kamil Rytarowski <n54%gmx.com@localhost >> >> 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> <mailto:n54%gmx.com@localhost>> 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 Jim pointed out, would be very hard for users to > comprehend anyway. > Acknowledged. > 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. > > I focused on massively threaded applications since the beginning of my work on ptrace(2). While I expressed my motivations, I don't set this as my current goal. The FreeBSD platform is substantially the same as NetBSD except this nuisance with the whole-process signal. There are mostly accidents with diverged API. I would like to upstream all of my local code by the end of this month, once I will finish FPR accessors and watchpoints. I need to rebase my local branch to the current trunk and polish for upstream quality. In this iteration of the Native Process Plugin/Thread/Register NetBSD I will skip the concept of more than 1 thread and x86 32-bit support. As of today LLDB/NetBSD is close to be useful as a debugger for a real job. Breakpoints, single-stepping, backtracing etc work fine. I keep locally (in pkgsrc-wip[1]) a patchset altering or adding 27 files. Their total length is 3284 lines. I wish I emptied it before moving on to threads. [1] https://github.com/NetBSD/pkgsrc-wip/tree/master/lldb-netbsd/patches
Attachment:
signature.asc
Description: OpenPGP digital signature