`error: relocation refers to a discarded section` when creating a shared library with `-fsanitize=fuzzer-no-link`

[malhotrag]

Environment

clang version 18.1.8
Target: x86_64-unknown-linux-gnu
OS: SUSE Linux Enterprise Server 15 SP2

Problem Description

I'm seeing the below linker error while trying to upgrade from clang 14.0.6 to clang 18.1.8. The error is seen when the -fsanitize=fuzzer-no-link option is specified to the compiler and linker. Removing the -fsanitize=fuzzer-no-link fixes the problem.

ld.lld: error: relocation refers to a discarded section: .rodata..str
>>> defined in b_fuzz.o
>>> section group signature: .str.4d6d471c262fa333656703edb5fd20e2
>>> prevailing definition is in a_fuzz.o
>>> referenced by b.c
>>>               b_fuzz.o:(funcb)

Minimal Reproduction Steps

Contents of file a.c

int global_var;

int funca()
{
	const char *who = "funca";
	return 0;
}

Contents of file b.c

int global_var;

int funcb()
{
	const char *who = "funcb";
	return 0;
}

Compilation and linking commands

clang -O0 -fPIC -m64 -fsanitize=address -fno-omit-frame-pointer -fsanitize-recover=address -fsanitize=fuzzer-no-link -o a_fuzz.o -c a.c
clang -O0 -fPIC -m64 -fsanitize=address -fno-omit-frame-pointer -fsanitize-recover=address -fsanitize=fuzzer-no-link -o b_fuzz.o -c b.c
clang -shared -O0 -fPIC -m64 -Xlinker --allow-multiple-definition -fsanitize=address -fno-omit-frame-pointer -fsanitize-recover=address -fuse-ld=lld -fsanitize=fuzzer-no-link -o lib_ab_fuzz.so a_fuzz.o b_fuzz.o

Observations

• If I remove -fsanitize=fuzzer-no-link from the commands listed above, the error disappears.
• I ran objdump -x -s a_fuzz.o and objdump -x -s b_fuzz.o and noticed that the same section group signature .str.4d6d471c262fa333656703edb5fd20e2 is present in both .o files when they are compiled with -fsanitize=fuzzer-no-link. If I compile without -fsanitize=fuzzer-no-link, the section group signature is different for both .o files and this linker error is not seen.
• A workaround is to add a new global variable to one of the files (or remove the int global_var from one of the .c files). This causes the signature for the two files to become different. For example, adding int dummy; at the top of file a.c fixes the problem.
• This error was not seen with clang 14.0.6. I have not tried other clang versions between 14 and 18 but I can try specific versions if you'd like me to.

[ccotter]

Ah, I can confirm I hit the same issue, and adding some arbitrary global variable to the 6 impacted object files in my build "fixed" the issue. Thanks @malhotrag for reporting this, as I don't know if I would have found this otherwise!