I’m interested in porting lldb to illumos (See illumos.org ; a derivative of OpenSolaris, and a relative of Solaris).
Most of the clang tools are already working.
As far as I can tell, it looks like I need to add a new:
lldb/source/Plugins/Platform/SunOS etc.
This OS provides a minimal ptrace(2) but the preferred and only full-featured process debugging interface is that delivered by the platform’s “libproc”.
Other than that, it should be similar to Linux, FreeBSD, etc.
I looked around on the getting started pages and didn’t see this topic covered.
I’d appreciated tips on:
What my new cmake stuff should look like.
How and where to run an “edit, compile, deal with failures” loop.
(Right now cmake seems to only work if I build clang+lldb, long job!)
What the new installed deliverables should be for running lldb.
(I’ve used gdb a lot, new to lldb.)
We have Windows support which doesn’t use ptrace of course, Mac OS is kinda ptrace but also other APIs and the QNX Pavel mentioned doesn’t use it. So using some other mechanism isn’t a problem.
There are a bunch of *Posix* classes that usually don’t use ptrace itself, so there shouldn’t be too much duplication. There’s several (maybe too many ) layers of classes and virtual methods to abstract all this away.
Should be a case of following the existing ports. Just note that the client side of lldb, that is, lldb as opposed to lldb-server, is a cross-debugger by default. So you may need to provide for example #defines that are normally found in illumos headers so that we can build on other OSs.
This allows us to debug illumos remotely or load core files on other OSs (which is also great because you get more test coverage).
If you mean for day to day development, all the usual building llvm tricks apply. That is, use lld as the linker, enable ccache, etc. lldb makes heavy use of clang as a library, so this part is unavoidable.
You can run tests individually - Testing - 🐛 LLDB and there is also info on the website about cross compilation and debugging of lldb itself.
The usual goal is:
An lldb-server that can run natively on the target.
An lldb that can be built on any platform, that can debug via that lldb-server. Or connect to a local lldb-server natively.
Then present those changes as an RFC on this forum with an overview of what you had to change and the maintenance plans going forward.
I’d pick one illumos supported architecture to work on first. The rest of them will be fairly tedious copy paste and ABI differences once you’ve got the system support in.
If for some reason you could not run lldb-server then making lldb work with an existing debug server is another way. This usually applies if you’re doing in kernel debug or some embedded system with only simulators and JTAG probes.
Starting your work by connecting lldb to an existing gdbserver is a way to get a head start, but gdbserver and lldb-server are not 100% compatible so you will still have some surprises when you start to test with lldb-server.
Ideally this platform would have a public build bot like Buildbot, but if that’s not possible then at least existing community builds or a ports system where it is checked regularly and there are folks we can ping if we have to make changes that impact illumos.
FreeBSD for example uses lldb and I know it gets tested at least per release, we have a maintainer or two active here and it has never caused us a problem in refactoring or fixing bugs.
Finally it is good to have to hand a simple guide to booting illumos in some simulation platform e.g. qemu. Often you’ll have to fix things yourself but if folks do take the time, anything to not waste that time is appreciated.
Ask as many questions as you need. Discourse (this forum) is best for text heavy posts, and you’ll get more visibility. We don’t all use Discord.
I have a work-in-progress (WiP) that builds but has some missing symbol problems I don’t understand. Here’s my WiP branch:
A few observations along the way:
1: I’m trying to compile LLDB “standalone”, using the LLVM that’s already installed under /usr/clang/18.1/{include,lib,…} but that has not gone 100% smoothly.
Should that generally work? or should I expect to just build everything?
2: The LLVM and LLDB code do not compile with the traditional (Unix) curses.h and curses library. On SunOS/illumos etc. both the traditional Unix curses and “ncurses” are provided, but things like autoconfigure need to be told to look in different places to find the right one. Particularly the curses libraries, which are in /usr/gnu/lib and the wrong one will be found if it looks only in /usr/lib …
Unfortunately, the already installed LLVM used Unix curses, and mixing the two
does not work (link time errors) so I just disabled curses in LLDB for now.
If I build everything, presumably I should figure out how to get all of LLVM
(and all sub-projects) to use ncurses on this OS. I’ll need help with that.
3: The illumos sys/types.h declares an offset_t that’s hard to avoid (I tried) and as a result, lots of C++ offset_t declarations become ambiguous. I went through and changed those to llvm::offset_t (which was a pain, touching about 170 places:)
Maybe that only benefits illumos, but I hope it’s an acceptable solution.
That change is a separate commit on my branch and could probably go in ahead of other work if people are OK with the fix.
4: I can compile LLDB with what’s shown on my illumos18 branch, but in the final link these symbols come up missing. I’m not sure why. Ideas?
(cd build-lldb ; gmake all)
...
[ 95%] Building CXX object source/API/CMakeFiles/liblldb.dir/SystemInitializerFull.cpp.o
[ 95%] Building CXX object source/API/CMakeFiles/liblldb.dir/__/__/bindings/python/LLDBWrapPython.cpp.o
[ 95%] Linking CXX shared library ../../lib/liblldb.so
ld: warning: file /lib/amd64/libm.so: linked to /usr/lib/64/libm.so: attempted multiple inclusion of file
Undefined first referenced
symbol in file
init_lld* /tank/ws/llvm/build-lldb/source/API/liblldb.exports
_ZN4lldb* /tank/ws/llvm/build-lldb/source/API/liblldb.exports
luaopen_lldb* /tank/ws/llvm/build-lldb/source/API/liblldb.exports
PyInit__lldb* /tank/ws/llvm/build-lldb/source/API/liblldb.exports
_ZNK4lldb* /tank/ws/llvm/build-lldb/source/API/liblldb.exports
ld: fatal: symbol referencing errors. No output written to ../../lib/liblldb.so.18.1.7
collect2: error: ld returned 1 exit status
gmake[2]: *** [source/API/CMakeFiles/liblldb.dir/build.make:1553: lib/liblldb.so.18.1.7] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:9036: source/API/CMakeFiles/liblldb.dir/all] Error 2
gmake: *** [Makefile:136: all] Error 2
$
I don’t see the references to the missing symbols. Where do they come from?
Yes, the standalone build should work. For macOS we have a bot that ensures this configuration keeps working. Of course it’s possible other configurations (i.e. that aren’t tested or used) are inadvertently broken.
That said, for development, I personally very much prefer the unified build. I think it’s more of a “first-class citizen” and allows you to easily make changes to other projects in the monorepo. It sounds that would also solve your second issue with curses.
If you can make an argument from a “type hygiene” point of view we would probably be fine with it regardless of the status of the illumos port. Especially if this happened to llvm/clang previously and was fixed there.
I see them listed in lldb/source/API/liblldb-private.exports but I don’t know why we do that.
lua and Py are scripting but you shouldn’t need those if you don’t have either enabled. They default to “auto” which will enable them if found, perhaps try setting their vars to “OFF”. Though we might generate stubs for them in that case.
) layers of classes and virtual methods to abstract all this away.