RFC: Surveying LLDB's supported platforms and architectures

Subprojects LLDB
1

I’m working on some guidelines for how to support a new platform in LLDB. First I needed to know what we support right now.

So I have come up with the table below listing everything I know of, whether there is an assigned maintainer, what bots it has and how often they run.

Note:

  • I have assumed that if there is a maintainer for the operating system, they will handle any architecture of that operating system.
  • “Stable” means “not changing a lot”. Which could mean it is less capable than others, but it has not changed in a while.
  • “Experimental” also means “in progress”.
  • “Other Public Community Bot” means a community that is downstream of LLVM. For example Debian’s package builds.
  • The purpose of this exercise is not comparison or ranking, the lack of something does not make a platform “bad”. If LLDB supports it, clearly it was doing something right, and this is not about changing anyone’s workflows.

The table is in-line here or you can view it on Google Sheets.

Operating System Architecture Status Maintainer Buildbot Other Public Community Bot Validation (per…) Notes
macOS i386 Stable TRUE TRUE TRUE commit Apple covers all of this in Green Dragon, there is also Homebew and MacPorts.
x86_64 Stable TRUE TRUE TRUE commit
AArch64 Stable TRUE TRUE TRUE commit
iOS/tvOS/watchOS (simulator) i386 Stable TRUE TRUE FALSE commit
x86_64 Stable TRUE TRUE FALSE commit
AArch64 Stable TRUE TRUE FALSE commit
iOS/tvOS/watchOS (device) Arm Stable TRUE TRUE FALSE commit
AArch64 Stable TRUE TRUE FALSE commit
visionOS (device) AArch64 Stable TRUE TRUE FALSE commit
Linux i386 Stable TRUE FALSE TRUE release Debian packages lldb for everything it supports - https://packages.debian.org/bookworm/lldb
x86_64 Stable TRUE TRUE TRUE commit Myself and Pavel cover Linux, in future we’d ask for an architecture maintainer too.
Arm Stable TRUE TRUE TRUE commit
AArch64 Stable TRUE TRUE TRUE commit
PPC64le Stable TRUE FALSE TRUE release
s390x Stable TRUE FALSE TRUE release
RISC-V Experimental FALSE FALSE FALSE ? I presume Qualcomm have testing downstream.
LoongArch Experimental FALSE FALSE FALSE ? I presume LoongSon have testing downstream.
Hexagon Stable TRUE FALSE FALSE ? Qualcomm may have downstream testing.
FreeBSD i386 Stable TRUE FALSE TRUE release Usually does not skip a release. Has lldb in base system and ports.
x86_64 Stable TRUE FALSE TRUE release
Arm Stable TRUE FALSE TRUE release
AArch64 Stable TRUE FALSE TRUE release
PPC64le Stable TRUE FALSE TRUE release
MIPS64 Stable TRUE FALSE FALSE N/A Unsupported as of FreeBSD 14.0 -https://www.freebsd.org/platforms/mips/
NetBSD i386 Stable FALSE FALSE TRUE release In 2017 there was a buildbot - The LLDB Debugger on NetBSD
Work was done in 2020 - https://blog.netbsd.org/tnf/entry/lldb_work_concluded - lldb integrated into source tree.
Package https://cdn.netbsd.org/pub/NetBSD/NetBSD-current/pkgsrc/devel/lldb/index.html but this may be different to one in base system.

I assume a release cadence like FreeBSD’s.
x86_64 Stable FALSE FALSE TRUE release
OpenBSD i386 Stable FALSE FALSE FALSE release (some skipped) Ships with the base system and has ports for other versions. System version may skip releases.
x86_64 Stable FALSE FALSE FALSE release (some skipped)
Windows i386 Stable TRUE FALSE TRUE commit Counting Omair as maintainer for all Windows architectures.

MinGW builds this, runs smoke tests.
x86_64 Stable TRUE FALSE TRUE commit MinGW builds this, runs smoke tests.
AArch64 Stable TRUE TRUE TRUE commit MinGW builds this.
Arm Stable TRUE FALSE FALSE ? Smoke tested by MinGW but has known issues.
Android Arm Stable TRUE FALSE TRUE NDK release Google checks per NDK release, quite likely uses their own intergration tests instead of the ones in tree.
AArch64 Stable TRUE FALSE TRUE NDK release
i386 Stable TRUE FALSE TRUE NDK release
x86_64 Stable TRUE FALSE TRUE NDK release
AIX PPC64 (BE) Experimental FALSE FALSE FALSE N/A https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
QNX AArch64 Proposed FALSE FALSE FALSE N/A https://discourse.llvm.org/t/remote-debug-of-aarch64-targets-running-qnx/83326
Bare Metal Any architecture listed above Stable FALSE FALSE FALSE N/A Exists as a consequence of the debug client/debug server model, “just works” or “just doesn’t”.
Bare Metal specific MSP430 Stable FALSE FALSE FALSE N/A LLDB contains fixes to handle the msp430 specific debug server.
Legacy Arm / Arm M Profile Stable FALSE FALSE FALSE N/A
Arc Stable FALSE FALSE FALSE N/A

Does anyone know of any others?

At the moment I know that Arc may in fact be for Linux on Arc, and my details on the BSDs are fuzzy. However, it’s enough for my purposes.

I thought it would be interesting for folks to see this all laid out. Considering how much we support, the project is very stable.

So to be extra clear: this is not a prelude to a new one size fits all standard for validation. It will be more along the lines of a set of “have you thought about X?” questions, so that we get the best outcomes for the contributors and for LLDB itself, and we are fair in how we asses proposals.

1 Like
LLVM Weekly - #576, January 13th 2025
Remote Debug of AArch64 Targets Running QNX
[RFC] Incubating DS2
2

@BradSmith Could you help me with details for OpenBSD?

@tedwoodward Is Hexagon for Linux debug or just bare metal?

3

In the list of Apple platforms there is now also visionOS, which is also fully supported.

1 Like
4

It’s both. The Hexagon DYLD plugin is used for “standalone” (basically, bare metal on the Hexagon simulator or system QEMU). For Hexagon Linux (which we had working on several generations of hardware, but it never really went anywhere) we use the standard Linux/POSIX plugins.

We have a downstream Hexagon platform that we use for the Hexagon simulator, system QEMU and our RTOS, but it’s basically a gdb-remote passthrough. When @bulbazord finishes the platform refactoring, I plan on adding Hexagon bare metal support to it.

1 Like
5

Thanks David, this is an excellent writeup! A couple minor fixes/comments for the Windows bit:

  • There’s a couple typos “MingGW” that should be “MinGW” (or just “mingw” is fine as well, for less obnoxious spelling)
  • For both i386 and x86_64, I do run smoke tests nightly - so it is tested more often than once per release, but not fully validated. (Not sure if this is relevant to mention or not.)

There has also been talks from some people recently about getting some Windows/x86_64 test buildbot up somewhere again, so hopefully we’ll have that soon (again).

1 Like
6

Given that there isn’t an LLVM buildbot at the moment, it’s certainly encouraging.

7

@tedwoodward, if there’s any utility to having a buildbot for hexagon linux (with QEMU?) we’d be happy to help work with you to make it happen. And with QEMU system mode support I suppose you could even exercise ptrace on hexagon linux?

8

If you want to use qemu-system, Move first RISC-V builder over to cross-compiler + execute tests under qemu-system setup by asb · Pull Request #279 · llvm/llvm-zorg · GitHub is doing so for RISC-V (not for lldb yet, but it could be extended for that).

9

That sounds great! With the number of Hexagon users growing, I’d expect someone with some pull to ask for Linux on it, so it would be nice if our Linux wasn’t completely bitrotten. We’re not testing it on hardware internally anymore, but upstream system QEMU would be a good alternative. It’s a full Linux build, with a full LLVM build. lldb-server is a standard Linux version, with specifics for the Hexagon Linux ptrace block.

I’m not sure our lldb-server implementation has been upstreamed; I’ll look into that.

That looks a lot like our internal Hexagon Linux toolchain builders - run on x86 Linux, publish the cross tools. Thanks, David.

10

I believe there is support for Arm and AArch64. I would like to try and have support for PowerPC/PowerPC64, MIPS64 and RISC-V64.

I am not sure what is meant by validation. We have some developers interested in, using and contributing some local patches for support, but I don’t know how well it has been tested all around.

FreeBSD doesn’t usually skip LLVM releases, but OpenBSD does. .e.g. we went from 13 to 16 and we’re about to update to 19.

After the few patches I have pending the patches we have left are to add a Process plugin and kernel debugging support.

11

I see only:

Plugins/Process/Utility/RegisterContextOpenBSD_i386.h
Plugins/Process/Utility/RegisterContextOpenBSD_x86_64.h

But perhaps you mean you have local patches for others, or perhaps if you use a GDB server as the debug target?

I wasn’t either, that’s part of the reason to do this survey. “validation” means whether it’s built into the base system, into a package or port, how often that’s tested, is that done in LLVM or outside of it, how would upstream LLDB and/or this community find out if something was wrong, and so on.

No need for all the details, what you’ve stated is useful as it is.

12

I guess my misunderstanding.

Yes, we ship lldb as part of both the base OS (16 at the moment) as well as ports/packages for various releases 16, 17, 18, 19.

1 Like