[cfe-dev] --split-dwarf silently fails on non-Linux platforms
Ed Maste
emaste at freebsd.org
Fri Mar 20 12:30:56 PDT 2015
On 20 March 2015 at 12:07, David Blaikie <dblaikie at gmail.com> wrote:
>
>
> On Fri, Mar 20, 2015 at 7:54 AM, Eric Christopher <echristo at gmail.com>
> wrote:
>>
>> 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.
More information about the cfe-dev
mailing list