Aprilis LLDB/NetBSD

-- Subject: Re: Aprilis LLDB/NetBSD

> Currently there is nothing planned on the base system side. All the
> enhancements are to be done on the LLDB side.
>
> Our core-dump files contain notes like: "NetBSD-CORE@1". This "1" is LWP
> and it must be properly handled in LLDB to define a thread. Currently
> LLDB just recognizes NetBSD-CORE files and "NetBSD-CORE" notes. It needs
> now to instantiate appropriate threads.
>
> On the other hand I've studied inspiring articles like:
> "FreeBSD Userspace Coredumps"
> https://backtrace.io/blog/blog/2015/10/03/whats-a-coredump/index.html
>
> Presenting a list of improvements for the NetBSD system is currently
> premature for me as I need to study up more on the topic. It appears
> also beyond the tasks related to LLDB.
>
> In other words we seem to be good enough to get all the needed things done.=

Ok, so nothing so far to do.

Well, we might want to build some interfaces like one to pass
siginfo_t.. however I don't think this is that important for core(5)
files as of now to get them just functional. There is already
infrastructure in the kernel for this (as far as I remember we pass it
in p_sigctx) that could be reused in future.

There is certainly room for improvement, but nothing stops us.

> > Sounds good, do you have the PT_{G,S}ETSTEP functional description somewh=
> ere?
> >=20
>
> PT_SETSTEP This request will turn on single stepping of the specified
> process.
>
> PT_CLEARSTEP This request will turn off single stepping of the specified
> process.
>
> In NetBSD case:
> ptrace(PT_SETSTEP, pid, NULL, lwp);
> ptrace(PT_CLEARSTEP, pid, NULL, lwp);
>
> I'm going to cleanup it and send for review.

Yes, but as PT_STEP is things going to be an MD thing? How will it be
implemented?

Yes, I planned to add it as MD.

In the source code protect it with
#ifdef PT_STEP
PT_STEP:
PT_SETSTEP:
PT_CLEARSTEP:
#endif

I will show a patch tomorrow.