LLDB 6 package

Previous issue: TritonDataCenter/pkgsrc-wip#97

Either we need to patch usage of C++11 in LLDB code base, or select clang 6 or gcc 6 to compile it with c++11 flag. I would go with CC=$(which clang) CXX=$(which clang++) make ... option, as it is working out for other distros.

[jasonbking]

I don't recall needing to do that so far. If you want, all the patches I've created so far can be downloaded at https://us-east.manta.joyent.com/jbk/public/lldb.tar.gz if you'd like to mess with them -- this isn't complete, I would be shocked if it built anything, and it's still missing implementing the LLDB api in terms of the illumos proc(4) debugging interfaces (and probably a few other things yet to be discovered). Also the LLDB actions for the signals are probably wrong in some places (for signals that existed on other platforms, I put what they used, for other ones that don't exist on other platforms -- e.g. SIGJVM1, I guessed).

The biggest annoyance is an lldb::offset_t is defined, but half the time, the code forgets to include the namespace, which ends up conflicting with the C offset_t. A good chunk of those patches are fixing those to always be lldb::offset_t (probably should be upstreamed to LLDB at some point).

[jperkin]

You may be able to simplify those with a judicious using lldb::offset_t; somewhere.

[jasonbking]

It didn't look like LLDB uses 'using ..' much at all -- it's probably just a quirk of illumos's header files that offset_t is getting brought in and not on other platforms.

Clang6 and LLVM6 are prerequisites of LLDB6 wip package anyway, wouldn't it make sense to use Clang6 to build LLVM6? With GCC 4.9, there was some C++11 / C++14 implementation missing that LLDB code base was using. Perhaps it will reduce the amount of patches etc.? (I haven't gotten a chance to test with clang yet, I was messing with GCC 4.9 as well, just asking)

PS: wondering if GCC is the way forward for some other reasons I am missing; then why can't we use some recent revision like GCC 8, that is already in netbsd/pkgsrc .. lest say just because we can and we have it

[krytarowski]

I'm still porting LLDB to NetBSD.. but I'm busy with the surrounding like kernel fixes, sanitizers etc.

@jperkin, related to this, could we update Clang and LLVM v6 from RC3 to final in next q. ports? There weren't many functional changes between RC3 and final. Basically, https://github.com/joyent/pkgsrc-joyent/blob/master/llvm6/version.mk#L4 to point to http://releases.llvm.org/6.0.0.

[jperkin]

Yeh absolutely, this will be in 2018Q2.

Thank you for 9158db7 @jperkin 🎉

Just wondering if gcc is coming from upstream https://github.com/NetBSD/pkgsrc/tree/trunk/lang/gcc8, gcc7 etc., should this 6 years old directory be deleted: https://github.com/joyent/pkgsrc-joyent/tree/master/gcc?

[sjorge]

Has any progess been made on this? This is a prerequisite for corecrl right?

[krytarowski]

For Illumos? No.

[am11]

This is a prerequisite for corecrl right?

not anymore. lldb is neither required to build coreclr nor it a mandatory run time dependency; diagnostics component has been moved to a separate repository: https://github.com/dotnet/diagnostics, and then consumed via nuget package.
The native components in dotnet/runtime repo can built with LLVM and GNU tool chains:

git clone https://github.com/dotnet/runtime --single-branch --branch master --depth 1

./build.sh --gcc  # or --gcc9, --clang, --clang9 etc.

however, in order to debug the managed code with SOS on Unix, we need lldb.

For native component debugging, gdb can also be used. gdb debugging for managed is not yet supported, due to the lack of good plugin support in gdb like lldb offers: dotnet/diagnostics#272.

---

For SmartOS - in general - we would need to find a way to resolve TritonDataCenter/pkgsrc#224 for native stack unwinder to function, which is a required component. I made some progress on building dotnet/runtime on SmartOS, after the libunwind port last year. It is a still on going effort and requires a lot of work to make it production ready.

TL;DR help is required from folks who are interested in dotnet. :)

[krytarowski]

I got all PAL tests to work on NetBSD at some point and now we see almost complete LLDB support.. I would like to see SmartOS aboard, but my spare time is too restricted to improve Illumos support in the foreseeable support.

[sjorge]

Right so the first step would be to get libunwind to build and pass all tests on SmartOS.

[am11]

That's correct. At least if we can fix the bulk of those new test failures shown in libunwind/libunwind#158 on SmartOS, that would help. Someone experienced with unwind in Illumos community might able to spot the root-cause of the new failures in this delta since last year: https://github.com/libunwind/libunwind/compare/edc427a..094833a. edc427a state was way better than what we have in 094833a. I have still a lot to learn about stack unwinding and Illumos OS to figure it all out by myself. 😊