LGTM but you should probably a wait a day to see if sanitizer owners are fine with with this as well.

In D45639#1193112, @ldionne wrote:

@phosek I don't understand how you can expect code compiled with new headers to link against an old dylib, unless you're setting the target platform, in which case anything that would fail to link will instead be a compiler error. I mean, we're adding stuff to the dylib from one version to the next, so _of course_ it won't always work.

So after looking a bit more into the output of the reproducer, I realized this is not the correct solution because it leads to relocations being duplicated. Instead, relocations for the folded section shouldn't be emitted at all so this's a deeper rooted issue.

Now also includes a reproducer.

I haven't managed to come up with a minimal reproducer yet, but this addresses the issue when using the reproducer attached in https://bugs.llvm.org/show_bug.cgi?id=38918.

I tested this change with Fuchsia and it's working for us. Thank you for looking into this! I'd like to see this landed as soon as possible as it unblocks the toolchain roll for us.

In D51833#1229776, @ruiu wrote:

I think I don't understand the use case of the feature yet.

• If you hard-link two files, they have the identical contents (strictly speaking there is only one file with two filenames). If a debugger can find an executable having debug info in .build-id/xx/xxxxx directory, it should be able to find it in the executable that's being debugged. So, how does it work?

In D51833#1229002, @ruiu wrote:

This seems like a new feature proposal, and we haven't discussed this before. It's not clear to me why you have to do this inside the linker rather than a post-processing tool. Could you please elaborate about why you want to add a new option?

In D51835#1228387, @kristina wrote:

LGTM.

(Really nit-picky comment: I would have done it by keeping an offset aside to add for lower case A-F to a-f and kept the original table as is. Implications of removing static may cause an insignificant increase in code size with bad linkers, just speculating, feel free to ignore)

This change broke several LLVM builders as well as our downstream Linux and macOS toolchain builders, would it be possible to either quickly fix the issue or revert it?

In D51440#1218859, @mstorsjo wrote:

I'll see if I can get to looking at that sometime soon. I had this patch lying around as an attempt to work around the libtool issue in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27866 which doesn't seem to be going anywhere (and even if it did, it probably takes quite a bit of time before a new libtool release is made and it gets propagated to most places where I'd like to use this), and was curious if there was any specific reason for having this the way it was, or just the usual; historical reasons that it has started out like this and haven't had a need to change until now. If you otherwise would happen to be touching the same areas, feel free to pick it up ;-) otherwise I'll try to look at addressing your points in a few days.

What about other compiler-rt runtimes? Shouldn't we use the same approach for those?

I also need to create the following empty files for tests to pass (somehow those are not displayed by Phabricator):

clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/aarch64-fuchsia/lib/libclang_rt.asan-preinit.a
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/aarch64-fuchsia/lib/libclang_rt.asan.so
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/aarch64-fuchsia/lib/libclang_rt.builtins.a
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/aarch64-fuchsia/lib/libclang_rt.fuzzer.a
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/aarch64-fuchsia/lib/libclang_rt.scudo.so
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/i386-linux-gnu/lib/libclang_rt.builtins.a
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/x86_64-fuchsia/lib/libclang_rt.asan-preinit.a
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/x86_64-fuchsia/lib/libclang_rt.asan.so
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/x86_64-fuchsia/lib/libclang_rt.builtins.a
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/x86_64-fuchsia/lib/libclang_rt.fuzzer.a
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/x86_64-fuchsia/lib/libclang_rt.scudo.so
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/x86_64-linux-gnu/lib/libclang_rt.builtins.a

In D50547#1198218, @rnk wrote:

Would it be to much to check both the normalized and non-normalized?

LGTM