[llvm] r273019 - Change RelaxELFRelocations for llc.

[James Y Knight via llvm-commits]

On Tue, Jun 21, 2016 at 1:07 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> .
> >
> > I wouldn't mind if the default simply stayed "false", like it was in the
> past for everything but those tools that can know it's safe. But, if
> there's going to be any a default of using the new relocs in other
> circumstances, I think that must be guarded behind the off-by-default cmake
> flag, for now. Even for the developer tools. Probably in a couple years
> from now it'll be safe to change the global default without breaking
> anything, but it's really not, now...
>
> If we don't change the default in the library, tool writers are not likely
> to find out that there are new relocations out there and we will be having
> exactly the same discussion a couple of years from now.
>
> If we change the library default each tool will find out about it when
> they upgrade, trivially disable  it and in the future we will be able to
> check if anyone is still depending on it.
>
> There are a number of tools that use llvm's MC layer to produce object
files. Almost all such tools that produce object files are completely
unrelated to linkers, and don't care what the produced object file looks
like -- except that it works. They don't themselves depend on having, or
not having, the new relocation types. The ONLY thing that matters is that
the linker that will be used (typically the system linker) will be able to
consume it.

We should not be forcing every such tool to individually discover that we
chose a broken-for-many-users default and work around it. These people
cannot fix the problem -- there is no action that needs to be taken, other
than waiting.

If we wait for two years before enabling this by default, the situation
will quite certainly be quite different: the number of users who have
system linkers that don't support the new relocation types will be much
lower, as they will have upgraded to a new version which does support it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160621/3c3f86af/attachment.html>