<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Mar 20, 2015 at 12:31 PM Ed Maste <<a href="mailto:emaste@freebsd.org">emaste@freebsd.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 20 March 2015 at 12:07, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
><br>
><br>
> On Fri, Mar 20, 2015 at 7:54 AM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Mostly that the only platform we knew it worked on was Linux and didn't<br>
>> want to make it error out.<br>
><br>
> Hmm - why did we not want it to error on unsupported platforms?<br>
<br>
Personally I'd rather have an error than silently ignoring the option.<br>
<br>
However, a comment on the related topic of enabling functionality on<br>
only Linux because it's known to work there. For FreeBSD at least I'd<br>
much rather we take the opposite approach in general. Allow new<br>
functionality globally, and let other maintainers disable it if<br>
necessary. (If the functionality is known to fail on not-Linux that's<br>
a different matter, of course. It's the cases where it's not known<br>
either way that I'm thinking of.)<br>
<br>
For cases like this -gsplit-dwarf where the functionality is opt-in<br>
under an option, it seems that we should just do what the user asks.<br>
We can expect them to provide the dependencies required.<br>
<br></blockquote><div><br></div><div>*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 :)</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In FreeBSD we've been putting a lot of effort into the toolchain<br>
recently. We've had Clang/LLVM as the system compiler since FreeBSD<br>
10.0 in January 2014, and we've started migrating to tools like strip,<br>
strings, size, nm and such from the ELF Tool Chain project. For the<br>
upcoming FreeBSD 11.x release our base system toolchain should also<br>
consist of LLDB and LLD. I'd rather find out about new functionality<br>
that's missing in one of those tools as early as possible and have to<br>
explicitly disable it, than find out after the fact that it wasn't<br>
even tried.<br>
<br></blockquote><div><br></div><div>lld and lldb don't support split dwarf for the record. I fully doubt that the rest of the elf toolchain project does either.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd be interested in hearing what the maintainers of other ELF targets think.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>-eric </div></div></div>