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

Wed Mar 15 17:43:05 PDT 2017

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.>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170316/901beb9d/attachment-0001.sig>