The underlying issue is that GLibc's dlsym(RTLD_NEXT, ...) appears to always return the oldest versioned symbol instead of the default. This means it does not match the behaviour of dlsym(RTLD_DEFAULT, ...) or the behaviour documented in the manpage.

Looks great!

LGTM. @paulkirth can you whether this helps your build?

Thanks for looking into the performance:)

The convention is to use err_drv_unsupported_option_argument instead of adding a new diagnostic kind.

gcc has renamed indirect-branch to indirect-jmp.

[X86] Add support for -mharden-sls=all

In D126424#3539245, @loladiro wrote:

In D126424#3539242, @MaskRay wrote:

In D126424#3539240, @loladiro wrote:

In D126424#3539200, @MaskRay wrote:

#if __has_attribute(constructor) is unneeded. All supported GCC/Clang supports #if __has_attribute(constructor).

Ok, the comment seemed to indicate that this was being done for MSVC compatibility. Is building compiler-rt with MSVC no longer supported?

There is #define __has_attribute(attr) 0

I'm sorry, I'm confused what change you'd like me to make here. The __has_attribute was there before. Could you elaborate?

In D126424#3539240, @loladiro wrote:

In D126424#3539200, @MaskRay wrote:

#if __has_attribute(constructor) is unneeded. All supported GCC/Clang supports #if __has_attribute(constructor).

Ok, the comment seemed to indicate that this was being done for MSVC compatibility. Is building compiler-rt with MSVC no longer supported?

#if __has_attribute(constructor) is unneeded. All supported GCC/Clang supports #if __has_attribute(constructor).

constructor(90) is more common.

LGTM.

docs/ClangCommandLineReference.rst is generated from HelpText. Use UsersManual.rst if you want to provide additional information. Please ensure --help has sufficient information about the allowed values.

The target platform instead of the host platform should be tested. We may need something like COMPILER_RT_DEFAULT_TARGET_ARCH.

In D123902#3537437, @argentite wrote:

This is my first patch. I don't have push access. Can you push it for me if nobody has any other comments?

LGTM, but hope @rprichard can verify this.

but you need some from #libc_abi

In D118490#3534202, @thakis wrote:

(there was similar feedback on the corresponding mold bug: https://github.com/rui314/mold/issues/505)

LGTM.

Because of TargetTriple.getOS() == llvm::Triple::Linux, you need to guard the unittest under a similar check.

In D126226#3532423, @tra wrote:

In D126226#3532257, @MaskRay wrote:

It's better to avoid JoinedAndSeparate for new options. It is for --xxx val and --xxxval but not intended for the option this patch will add.

I'm not sure I understand your argument. The two cases where I see JoinedAndSeparate are used right now (-Xarch_ and -plugin-arg) both are using it for the purposes similar to this patch.
I also do not quite see how JoinedAndSeparate is applicable to --xxxval/--xxx val.
Could you elaborate, please?

In D126226#3532301, @MaskRay wrote:

Consider something like -Xoffload-linker-triple <triple>=<arg>

That could work.

We keep running into the same old underlying issue that we do not have a good way to name/reference specific parts of the compilation pipeline. -Xfoo used to work OK for the linear 'standard' compilation pipeline, but these days when compilation grew from a simple linear pipe it's no longer adequate and we need to extend it.

Speaking of triples. I think using triple as the selector is insufficient for general offloading use. We may have offload variants that would use the same triple, but would be compiled using their own pipeline. E.g. the GPU binaries for sm_60 and sm_80 GPUs will use the same nvptx64 triple, but would presumably be lined with different linker instances and may need different options. My understanding is that AMDGPU has even more detailed offload variants (same triple, same GPU arch, different features). I don't know whether it's applicable to OpenMP, though. I think it is. IIRC OpenMP has a way to specialize offload to particular GPU variant and that would probably give you multiple offload targets, all with the same triple.

Perhaps wait a day or so in case others have opinions.

IIRC there is no built-in way supporting multiple (but fixed number of) values for an option (e.g. -Xoffload-linker-<triple> <arg>). In D105330 (llvm-nm option refactoring) I used a hack to support -s __DATA __data.
The multiple-value support for OptTable does not allow positional arguments after the option.

It's better to avoid JoinedAndSeparate for new options. It is for --xxx val and --xxxval but not intended for the option this patch will add.

LGTM. Thanks for pinging the relevant folks on individual tests. You can push the fixes yourself before landing this patch.

In D124751#3513513, @python3kgae wrote:

In D124751#3513283, @MaskRay wrote:

Is there a specification or reference implementation stating that -E is used?

Option<["--", "/", "-"], "E",

Do you need the prefix --? You may define something like CLFlag. I have missed previous patches, but if / options are not necessary, removing them will be the best to avoid collision with filenames starting with /.

Unfortunately, '/' is necessary. dxc allow both '-' and '/' like 'CLFlag'.
Remove '/' means existing customers may need to change their command line to compile hlsl.
And add '--' feels not hurt anyone, that's why I choose to add '--' to work-around the conflict.

FP_XSTATE_MAGIC1 is only available on glibc 2.27 and upwards

The name is not descriptive. It misses the important words about "hash map". ConcurrentHashMap may be a better name.

Where is the undefined behavior? size_t is unsigned long long on 32-bit ELF platforms. You need %zu.

Fix MCSymbolizer::tryAddingSymbolicOperand() interface

However, for proper symbolic disassembly on X86 we need to know both sizes.

Overloaded virtual functions seem more difficult to read and are more error-prone. Having distinct function names can be useful as people searching code can find the relevant one easily.

In D125979#3528140, @rnk wrote:

@MaskRay, can you review this? I think you have been thinking the most about how to parallelize linkers, and what fundamental data structures are most important.

While I think there are still significant problems needing to address, it may work with quite a few application. It'd be nice if folks can check how this patch works without -mno-relax.

On lld/ELF/Relocations.cpp:1439, R_RELAX_HINT should not trigger sym.hasDirectReloc = true;, otherwise an ifunc may unnecessarily be converted to a canonical PLT. You may read *-ifunc-nonpreemptible*.s tests for what they do. I have some notes on https://maskray.me/blog/2021-01-18-gnu-indirect-function#address-significance

Thanks!

I think placing the OS before && is more common.

Seems fine to me for libunwind, but I don't know the build bot setup enough. I will give a LGTM if you still lack an approval to make #libunwind green :)