Re: LLDB/NetBSD extended set of tasks

[Pavel Labath <labath%google.com@localhost>]

On 16 March 2017 at 00:43, Kamil Rytarowski <n54%gmx.com@localhost> wrote:
> 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.
This is necessary so that we can read the list shared libraries loaded
by the process and set any breakpoints in them. Note that currently
(at least on Linux) we are doing it actually too late -- at this point
the constructors in the shared libraries have already executed, so we
cannot set breakpoints or debug the initialization code. I haven't yet
investigated how to fix this.

>
>
> 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.
We will need to discuss this in detail. I am not sure removing the
NativeThreadNetBSD class completely will is a worthwhile goal, but we
can certainly work towards making it's parent class dumber, and remove
operations that don't make sense for all users. If e.g. your
watchpoints are per-process, then we can pipe watchpoint setting code
through NativeProcessProtocol, and NativeProcessNetBSD will implement
that directly, while the linux version will delegate to the thread.
However, even in your process model each thread has a separate set of
registers, so I think it makes sense to keep the register manipulation
code there.

>  - 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)
Teaching all parts of the debugger (server is not enough, I think you
would have to make a lot of client changes as well) about
whole-process events might be a big task. I wondering whether you
wouldn't make more progress if you just fudged this and always
attributed these events to the primary thread. I think we would be in
a better position to design this properly once most of the debugger
functionality was operational for you. What kind of per-process events
are we talking about here? Is there anything more here than a signal
directed at the whole process? 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".

cheers,
pl