On 01.03.2017 10:13, Kamil Rytarowski wrote: > Hello, > > The contract for the LLDB port on NetBSD has been prolonged by The > NetBSD Foundation. The additional time will cover the features that were > delayed in order to address blockers that were unveiled during the work > that has been done. > > I've summarized the newly finished task segment in this blog entry: > > http://blog.netbsd.org/tnf/entry/ptrace_2_tasks_segment_finished > > My current plan is to return to LLDB and finish the following tasks: > I. Register context and breakpoints support on NetBSD/amd64. Halfway point status. (LLDB developers please check the second part.) Proper support for breakpoints is all-or-nothing, it's difficult to draw firmly the line between "fully functional" and "implemented with bugs". Functional software breakpoints are also the next milestone and the goal is get tracing a simple 1-threaded program from spawning to its termination; correctly and with all the features - as per GDB Remote Protocol messages - in line with Linux. Among the implemented/improved features: - Tracee's .text section disassembling works, - Backtracing (unwinding stack) of the tracee works, - Listing General Purpose and Special Registers works, - Reading General Purpose Registers works, - Setting software breakpoint (placing it into tracee's .text segment) works, - Triggering software breakpoint (previously set with a debugger) works, - Rewinding Program Counter and hiding breakpoint from disassembled .text section code works, - Scanning tracee's virtual address map works, - Reading Elf Auxiliary Vector (AUXV) works. What clearly doesn't work is unsetting software breakpoint as the debuggee session is crashing afterwards without proper unsetting a trap (and the child is killed by the kernel with SIGSEGV). Software breakpoints are all-or-nothing, enabling them keeps unveiling bugs in code fragments which already appear to work. TODO: - Fixing software breakpoints support, - Special Registers (Floating Point..) reading/writing, - Unless it will be too closely related to develop threads - Hardware watchpoints support in line with the Linux amd64 code, As of today the number of passing tests has been degraded. This has been caused due the fact that LLDB endeavors to set breakpoints in every process (on the "_start" symbol) - this blocks tracing or simulating tracing of any process. Not planned for this segment: - Fixing single step trap - it may automatically get fixed with the above features, but it's not the goal for now. This will be part of the threads segment. - Everything related to threads and x86 32-bit (i386) support. - Fixing other non-blocker bugs, not related to software breakpoints, FPR, debug registers. My plan for April+ (+ means that it might consume some of May..) is as follows: - Alter the design of Resume actions to handle the whole process tasks (next to per-thread-ones), - Disable emitting stop reason of all stopped threads in multithreaded software on NetBSD as it's not applicable in our thread model (as in contrary to Linux), - Alter stopped reason retrieving to ask process (NativeProcess), not thread (NativeThread). - Alter watchpoints API to call the process (NativeProcess), not thread (NativeThread). - Alter thread type container in process (nativeProcess) to allow to use std::set-like containing tid (integers/lwpid_t) to store the current image of threads. - Support in the current thread function "0" (or "-1" according to the GDB Remote protocol) to mark that the whole process was interrupted/no primary thread (from a tracer point of view) The general goal is to eliminate NetiveThreadNetBSD, because my current feeling is that the whole purpose of keeping this class on par with Linux is duplicating the work already done by the NetBSD kernel. The current result is that I need to call process-global events from NativeThreadNetBSD and I'm enforced by the generic framework to keep this dummy struct around. My local copy of the NativeRegisterContext class is partly affected as well.. as ptrace(2) calls are called for the process, not for singular threads out of the process context. This task needs proper designing and collaboration. I think I will start with adding basic and possible support for threads in the existing framework and once done, move on to refactoring the generic code. Of course any help - prior April - helping (Net)BSD threads support landing is appreciated! > II. NetBSD Threads support > III. NetBSD/i386 (32-bit x86) support. > > To finalize the first goal I use LLVM/Clang/LLDB SVN rev. 296360 as the > base for my local patches. I work in pkgsrc-wip/lldb-netbsd and I > develop there local patches. > > The current Test Suite status reports 267/1235 tests passed > successfully. This number of passing tests is expected to start growing > once the goals will be achieved and LLDB will be rendered into a > functional debugger on NetBSD. > > =================== > Test Result Summary > =================== > Test Methods: 1235 > Reruns: 1 > Success: 267 > Expected Failure: 21 > Failure: 332 > Error: 167 > Exceptional Exit: 0 > Unexpected Success: 1 > Skip: 444 > Timeout: 3 > Expected Timeout: 0 > > http://netbsd.org/~kamil/lldb/check-lldb-r296360-2017-02-28.txt > > > <This work is sponsored by The NetBSD Foundation.> >
Attachment:
signature.asc
Description: OpenPGP digital signature