Pre-processor definition confusion

A couple of pre-processor definitions I’m wondering about:

NetBSD: What is this used for, and how is it different than FreeBSD?

FreeBSD_kernel: Same as previous question, why is this different than just FreeBSD?
GLIBC: Isn’t this the same as linux || APPLE?

I understand that in the general case (i.e. ignoring LLDB) there are some differences. But just in terms of what platforms LLDB runs on and compiles on, is there any way we can simplify our conditionals here? Does anyone build LLDB with NetBSD? Most of our conditionals only check for FreeBSD, so wouldn’t all these paths be broken with NetBSD? Should we just have a BSD define that captures all of these?

Does LLDB care about supporting both FreeBSD and FreeBSD_kernel?

Who uses GLIBC that is neither linux nor apple?

A couple of pre-processor definitions I'm wondering about:

__NetBSD__: What is this used for, and how is it different than __FreeBSD__?

NetBSD is another OS altogether, although has a lot in common with
FreeBSD. It's well supported in Clang/LLVM. The few cases in LLDB
represent the beginning of support, but I'm not aware of anyone
building or testing it on a regular basis.

__FreeBSD_kernel__: Same as previous question, why is this different than
just __FreeBSD__?

This indicates that the FreeBSD kernel is being used, without
reference to the userland / libc. It's mainly driven by the Debian
GNU/kFreeBSD project, which runs a GNU userland and GLIBC on the
FreeBSD kernel. (It's sort of the opposite of Android in that
respect.) I know they at least build-test LLDB regularly.

__FreeBSD__ implies __FreeBSD_kernel__

__GLIBC__: Isn't this the same as __linux__ || __APPLE__?

It indicates GNU libc, so not true on Apple.

Thanks. In some places we check GLIBC explicitly. I guess what I’m wondering is: is there some reason this isn’t equivalent to some combination of OS define checks?

You can use alternative libcs on Linux, like musl:
http://www.musl-libc.org/

Android, for example, uses a Linux kernel with the Bionic libc
implementation, so it's complicated. =/

It doesn't build out of the box and I haven't had time recently to catch
up with the changes to keep it building with hacks. I plan to resume
that of course.

Joerg

What are the differences between FreeBSD and NetBSD? Every time we check for one, should we also be checking for the other?

The important thing seems to be whether glibc implies linux, not the other way around. If glibc implies linux, then

#if defined(linux) || defined(GLIBC)

can be reduced to

#if defined(linux)

The issue is that all of our CMake decisions are based on OS platform. If I want to conditionally compile an entire file based on one of these conditions, I need to translate it into something that fits well into the CMake build.

What does a cygwin or minwing environment look like? I would guess cygwin would have GLIBC defined? (I’m not sure if we even pretend to build there, but that’s the glibc case that is not Linux that comes to mind).

Not a Cygwin person, but Reid might be able to answer that one.

MinGW doesn’t use glibc though.

I’m personally ok saying we don’t support Cygwin. The point of my work is to make it work on actual Windows, not fake Windows anyway :slight_smile: And I think also that like you said it probably doesn’t even work right now.

Even if we did want to support Cygwin though, then we already have LLDB_DISABLE_POSIX which could be used for the same purpose. Each additional pre-processor conditional adds to the complexity and maintenance cost of the code (this thread is a good example :P) so I’d like to remove the GLIBC checks if possible and convert them into something more easily understandable.

The important thing seems to be whether glibc implies linux, not the other
way around.

It doesn't -- Debian k/FreeBSD has __GLIBC__ and __FreeBSD_kernel__,
and not __linux__.

The issue is that all of our CMake decisions are based on OS platform. If I
want to conditionally compile an entire file based on one of these
conditions, I need to translate it into something that fits well into the
CMake build.

That should be fine, although in some cases there won't be a mapping
to a single OS if multiple macros are used.

An OS to macro map would include, for example:

FreeBSD: __FreeBSD__, __FreeBSD_kernel__
Linux distros: __linux__, __GLIBC__
kFreeBSD: __GLIBC__, __FreeBSD_kernel__

The kFreeBSD project needs to use the FreeBSD kernel's debugging
interface (e.g., the ptrace syscall and constants) and glibc's
userland interfaces (e.g., setting thread names).

Is there any value in having an LLDB_HOST_XXX set of macros such as the following:

LLDB_HOST_APPLE
LLDB_HOST_WIN32
LLDB_HOST_MINGW
LLDB_HOST_LINUX
LLDB_HOST_BSD

The last one would translate to FreeBSD || FreeBSD_kernel || OpenBSD || NetBSD

In lldb/Host/Config.h, we use the presence of any of these 4 things to include lldb/Host/freebsd/Config.h. But then in most other places, we either only check for FreeBSD or only check for FreeBSD_kernel. Since the platforms are similar, it seems like most of the time you just want to check for all 4, and checking for some subset of those would be the exception.

For example, in my previous HostThread refactoring changelist, I created this HostThreadFreeBSD class. That class isn’t going to be compiled on OpenBSD or NetBSD though (at least on the CMake build, which I know you don’t use, but still). So that seems like a bug. Do you agree that more often than not, when we check for FreeBSD we want to check for all of the BSD variants? Or am I wrong there?

I suspect though that where __FreeBSD__ is used in combination with
another OS (e.g. __FreeBSD__ || __linux__, or __FreeBSD__ ||
__APPLE__), we likely need __NetBSD__ there too.

Keep in mind though that the NetBSD support so far is really just
basics to get the debugger to build and run, but AFAIK there's none of
the kernel debugging interface side at all yet. I expect there will
be a reasonable amount shared between FreeBSD and NetBSD there, but a
lot that's OS-specific too.

Right, that’s exactly my thinking too. Hence my suggestion in the previous post (which I suspect we just crossed paths on the email, so you didn’t see it yet) to make jsut an LLDB_HOST_BSD that covers all of them. Because we probably need OpenBSD too in most cases, and exceptions should be rare.

Except that __FreeBSD_kernel__ wouldn't be included; I'd be surprised
to find LLDB_HOST_BSD true on Debian kFreeBSD. It's distinct enough
that it would need it's own.

We'll also still need to test for more than one of these in some cases
though -- for example, for socket behaviour that is shared between OS
X and the BSDs.

I think cleaning up these macro tests is a laudable goal, but it's
inherently not possible to cleanly cover all cases.