--split-dwarf silently fails on non-Linux platforms

In r175814 -gsplit-dwarf was made into a no-op on non-Linux platforms,
but there's no explanation in the comment explaining what lead to the
change. -gsplit-dwarf requires a newer binutils, but that is also true
on Linux.

I'm looking into this for FreeBSD, and wonder if I should change the
three or so isOSLinux() conditions for split-dwarf to (isOSLinux() ||
isOSFreeBSD()), just remove them, or something else. I'm not fully
aware of the situation on Windows or Darwin, but it seems we could
handle it the same way on all ELF targets, at least.

Mostly that the only platform we knew it worked on was Linux and didn’t want to make it error out. We can make it not error for all elf targets for sure if you’d like to give it a go. Needs a relatively recent binutils and GDB (currently no lldb support).

-eric

Mostly that the only platform we knew it worked on was Linux and didn't
want to make it error out.

Hmm - why did we not want it to error on unsupported platforms?

Personally I'd rather have an error than silently ignoring the option.

However, a comment on the related topic of enabling functionality on
only Linux because it's known to work there. For FreeBSD at least I'd
much rather we take the opposite approach in general. Allow new
functionality globally, and let other maintainers disable it if
necessary. (If the functionality is known to fail on not-Linux that's
a different matter, of course. It's the cases where it's not known
either way that I'm thinking of.)

For cases like this -gsplit-dwarf where the functionality is opt-in
under an option, it seems that we should just do what the user asks.
We can expect them to provide the dependencies required.

In FreeBSD we've been putting a lot of effort into the toolchain
recently. We've had Clang/LLVM as the system compiler since FreeBSD
10.0 in January 2014, and we've started migrating to tools like strip,
strings, size, nm and such from the ELF Tool Chain project. For the
upcoming FreeBSD 11.x release our base system toolchain should also
consist of LLDB and LLD. I'd rather find out about new functionality
that's missing in one of those tools as early as possible and have to
explicitly disable it, than find out after the fact that it wasn't
even tried.

I'd be interested in hearing what the maintainers of other ELF targets think.

Mostly that the only platform we knew it worked on was Linux and didn’t
want to make it error out.

Hmm - why did we not want it to error on unsupported platforms?

Personally I’d rather have an error than silently ignoring the option.

However, a comment on the related topic of enabling functionality on
only Linux because it’s known to work there. For FreeBSD at least I’d
much rather we take the opposite approach in general. Allow new
functionality globally, and let other maintainers disable it if
necessary. (If the functionality is known to fail on not-Linux that’s
a different matter, of course. It’s the cases where it’s not known
either way that I’m thinking of.)

For cases like this -gsplit-dwarf where the functionality is opt-in
under an option, it seems that we should just do what the user asks.
We can expect them to provide the dependencies required.

shrug I don’t think it’s worth the amount of effort of this discussion to be honest. I know I didn’t think this hard about it when I added it :slight_smile:

I don’t mind having it always try to do the various things. At the time it was added it wasn’t reasonable to try to do so given that none of the dependencies had even seen a release, much yet been finalized. Motivation at the time was mostly to impact people as little as possible and still be able to develop the feature.

In FreeBSD we’ve been putting a lot of effort into the toolchain
recently. We’ve had Clang/LLVM as the system compiler since FreeBSD
10.0 in January 2014, and we’ve started migrating to tools like strip,
strings, size, nm and such from the ELF Tool Chain project. For the
upcoming FreeBSD 11.x release our base system toolchain should also
consist of LLDB and LLD. I’d rather find out about new functionality
that’s missing in one of those tools as early as possible and have to
explicitly disable it, than find out after the fact that it wasn’t
even tried.

lld and lldb don’t support split dwarf for the record. I fully doubt that the rest of the elf toolchain project does either.

I’d be interested in hearing what the maintainers of other ELF targets think.

Do you mean the other BSDs or linux or…? Anyhow, I don’t really think it’s necessary. OSes that want to support it will need to add toolchain support for it (Toolchains.cpp and friends). I’ll happily take a look at any patches.

-eric

*shrug* I don't think it's worth the amount of effort of this discussion to
be honest. I know I didn't think this hard about it when I added it :slight_smile:

I wasn't trying to call out the change or turn this into a drawn-out
thread; I just wanted to raise awareness that there is also some
downside to enabling functionality on only one platform. A similar
case was the DWARF TLS reference issue (DTPOFF) - I found it was
failing on FreeBSD, and it took a bit of debugging to find out that it
was explicitly disabled on non-Linux, rather than being broken for
other reasons. Anyway, it's not really a big deal.

lld and lldb don't support split dwarf for the record.

No, but I expect that support to develop over time, and we have gold
and gdb packages available in the interim.

I fully doubt that
the rest of the elf toolchain project does either.

I'm thinking specifically of the requirement for objcopy (elfcopy) to
support --extract-dwo and --strip-dwo for clang's use, and that's
trivial to implement. It's true that actual consumers of debug data
don't yet support it, and that will take more effort.

I'd be interested in hearing what the maintainers of other ELF targets

think.

=> Do you mean the other BSDs or linux or...? Anyhow, I don't really think it's

necessary. OSes that want to support it will need to add toolchain support
for it (Toolchains.cpp and friends). I'll happily take a look at any
patches.

I mean other BSDs, or ELF platforms other than Linux. With the patch
in D8484 on FreeBSD clang -gsplit-dwarf -o foo.o -c foo.c generates
the .o and .dwo with expected content.