[cfe-dev] --split-dwarf silently fails on non-Linux platforms

[Eric Christopher]

On Fri, Mar 20, 2015 at 12:31 PM Ed Maste <emaste at freebsd.org> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150320/0dcc6632/attachment.html>