In D32149#763008, @labath wrote:

What was your decision on the core files? I was under the impression you were gonna add the zip files as well. If so, then they should go in at the same time.

Can we go with this change?

Rebase to HEAD.
Apply "Error" -> "Status" rename.

If we end up with hard links I think we should change them to symbolic ones. This is a common policy in some open source distributions.

From the NetBSD point of view looks good.

@phosek ping for Fuchsia, perhaps needed as well.

The __linux__ check makes __ANDROID__ redundant.

__GNU__ is for GNU/Hurd not, GNU compiler, please revert

__GNU__ is not for GCC but for GNU/Hurd.

I think this should check for GNU platforms, not GNU compatible compilers. As far as I understand we don't want this on NetBSD in both cases libunwind, llvm.

It's not that perfectly clear to me that SetStatus() returns Succeeded(), however I don't have a proposal for a better name. SetStatusReturnSucceeded() or similar are long.

In D32930#753916, @labath wrote:

next batch of comments from me (I expect to have more on monday). :)

In D32930#752843, @krytarowski wrote:

I can build locally with make thread_inferior, how to run it?

run the check-lldb-unit target.

Personally I would rely on LLDB feature to set software/hardware breakpoint in tracee, and never simulate debugtrap with some predefined value.

If I'm not mistaken LLVM __builtin_debugtrap is defined only for X86. It will also fail on GCC as there is no support for it.

I can build locally with make thread_inferior, how to run it?

Some headers are UNIX-specific like <unistd.h>, is it possible to make these tests compatible with Windows?

In D33035#751280, @clayborg wrote:

In D33035#751264, @krytarowski wrote:

Can we please use the generic process plugin code, not the specific Linux one? If the generic code is insufficient - we should adjust it and alter instances of it (Linux and BSD).

There should be no need to ever #include something from a plug-in in code the gets loaded externally. We should rely on the error strings themselves, not be comparing them to some value. SBError has an error type (generic, posix, mach-kernel, expression results, windows). It we are going to do anything we can make up a new set of them, but the code in this patch is relying on the values, when it should just be using the string value. If the string value wasn't set correctly, fix that is the code that creates the errors.

Can we please use a generic process plugin code, not the specific Linux one? If the generic code is insufficient - we should adjust it and alter instances of it (Linux and BSD).

GoogleTest is an already a part of LLVM. It is stripped down version of this software with patches for LLVM - at least with included NetBSD support that is still pending upstream.

FYI, NetBSD has its distinct libpanel in its base system, API compatible with ncurses.

NetBSD change looks fine.

Remove another unrelated style improvement.

Strip non-functional style improvements in unrelated code-parts.

Standalone build has been broken?

In D32149#739727, @labath wrote:

In D32149#738250, @krytarowski wrote:

ping?

Sorry, I wasn't responding partially because I was waiting to see how the discussion on https://reviews.llvm.org/D32434 settles, as I think it may have effect on the test strategy. I'll write more tomorrow. :)

ping?

I cannot reproduce it locally.

In D32271#735354, @emaste wrote:

In D32271#735098, @krytarowski wrote:

I have plan to revisit corresponding files in NetBSD and switch from kvm(3) to sysctl(3). But this is lower priority than Process Plugin right now.

Thanks for the note. I wasn't aware that you had that planned, but I incorporated the improvements you made in NetBSD's Host.cpp (early returns etc.) in order to reduce diffs and facilitate shared effort on these bits at some point.

I have plan to revisit corresponding files in NetBSD and switch from kvm(3) to sysctl(3). But this is lower priority than Process Plugin right now.

In D32120#734634, @emaste wrote:

In D32120#734603, @krytarowski wrote:

I don't agree. It would mean that it's supposed to work on BSD4.4 and derivate systems like BSD/OS.

I think it would be useful to have a #define for modern BSDs though, as presumably DragonFly, bitrig, EdgeBSD etc. will need it set as well (although some/all may still include the #define inherited from their parent).

In D32120#734601, @dim wrote:

Also add NetBSD. At some point, we might want to have a global
LLVM_ON_BSD define to make these easier. :)

This is valid for NetBSD as well.

Fix handling executable and shared library triple detection.

In D32149#731887, @labath wrote:

A test would infinitely times more valuable then a demo script. What is the tiniest core file you can produce on NetBSD? (on linux we've gotten them down to about 20K) Then we could check that in and write a test for it...

BSD script(1) is incompatible with the GNU one, so I prepared a quick port to Linux:

Fix from pkgsrc-wip to resurrect LLDB Standalone build in SVN r. 300654.

Is this just GNU specific? BSD moved to 64-bit off_t on 32-bit platforms 20+ years ago.

I will fix the original problem differently. Thanks for help!

Add FPR support.

While there there are candidates like pipe2(2) in source/Host/posix/PipePosix.cpp.

I might need some guidance to address the asserts appropriately in finite time.

Thank you for working on it!

Other BSDs work.

For the reference, I uploaded FreeBSD/amd64 and OpenBSD/i386 core(5) files:

Hmm still wrong.

Example core(5) file:
http://netbsd.org/~kamil/lldb/top.core

Thanks! I noted that I introduced some bugs.. but I will fix them in future revisions. I will move on to threads now. FPR/watchpoints will be done later, on the cost on adding some code for cores and helping out with base system work.

Thanks!

Apply changes from review. No visible regressions in "check-lldb".

Build for me:

Thanks, I'm going to test it.

https://github.com/Kitware/CMake/blob/master/Modules/FindBacktrace.cmake

Right, it's no LLDB....

Does NetBSD need it too?

I think I will start the threading segment with proper handling of core(5) files. It looks like the simplest start point.