[PATCH] D70468: [ELF] Error if -Ttext-segment is specified

Tue Feb 4 12:33:07 PST 2020

MaskRay added a comment.

In D70468#1857643 <https://reviews.llvm.org/D70468#1857643>, @troyj wrote:

> > For this -Ttext-segment we faced a decision whether we should silently interpret an option incorrectly or leave it as an hard error.
>
> Understood, but since the incorrect interpretation was silently "working," it is necessary for us to remove this change until the option is no longer used anywhere.

It was "working" for your use case but "incorrect" in some others (qemu -Ttext-segment (Richard Henderson did more refactoring to qemu's configure and this kind of stuff is completed deleted now), an internal ld.so like program I debugged).

>> I know the documentation says lld aims to be a drop-in placement of GNU linkers, but in my opinion in some cases we really need downstream users to do some necessary refactorings to adopt lld. This is like adopting clang.
> 
> It's not quite the same.  We have adopted Clang, but Clang (and GNU) provide a -fuse-ld option, which means that the choice of linker is actually exposed to the user.  We prefer to use lld as our default because we can more easily modify its source as necessary (such as in this case), but in practice the reason that our users sometimes need to select a specific linker is to workaround bugs in bfd/gold/lld.  Normally the bugs present themselves as relocation errors that appear with only one of the three linkers.  Therefore, the users need to be able to swap between the different linkers and any option that is not supported by all linkers requires additional effort -- either educating the user to be aware and change their options, or having scripts that automatically detect the active linker and hide the differences.  Either takes time to implement and needs to be implemented before we leave the hard error in place.

For your amusement, I filed a feature request/bug report regarding GNU ld's less rigid behavior about R_PPC_REL16_LO https://sourceware.org/bugzilla/show_bug.cgi?id=25500
There is a possibility that it will be closed as a wontfix. I am glad that lld has been rigid since its early days. If we receive feature requests about special casing R_PPC_REL16_LO and silencing such reasonable diagnostics, honestly I will consider them unreasonable.

It looks like you already modify lld source, so I agree this change is a bit inconvenient to you but it is not insurmountable. Many builds also enable -Wl,--fatal-warnings. Even linker warnings will not make them happy.

>> I remember that Peter Smith once said we probably need to consider a deprecation mechanism
> 
> Yes, that would have been appreciated here.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70468/new/

https://reviews.llvm.org/D70468