Fznamznon wrote:
Reduced linkage failure reproducer (can be reduced further, I'm sure), it
consists of 4 files
t.h:
```
#include <new>
struct Base {
Base() {}
virtual ~Base() {}
};
struct ClassA : public Base {
inline ClassA();
virtual ~ClassA(){} ;
};
inline
ClassA::ClassA() {}
void foo();
```
t.cpp
```
#include "t.h"
int main()
{ ClassA* objs = new ClassA[5]; delete[] objs;
foo(); return 0; }
```
t1.cpp
```
#include "t.h"
void foo()
{ ClassA* objs = new ClassA[5]; delete[] objs; }
```
t3.cpp
```
#include "t.h"
void foobar()
{ ClassA* objs = new ClassA; delete objs; }
```
Then
```
clang-cl -c t.cpp /Zi -fsanitize=address,fuzzer-no-link
clang-cl -c t1.cpp /Zi -fsanitize=address,fuzzer-no-link
clang-cl -c t3.cpp /Zi -fsanitize=address,fuzzer-no-link
lld-link.exe t.obj t1.obj t1.obj t3.obj
"-libpath:path_to_llvm\lib\clang\21\lib\windows"
"path_to_llvm\lib\clang\21\lib\windows\clang_rt.asan_dynamic-x86_64.lib"
"-wholearchive:path_to_llvm\lib\clang\21\lib\windows\clang_rt.asan_static_runtime_thunk-x86_64.lib"\
lld-link: error: relocation against symbol in discarded section: .text
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
lld-link: error: relocation against symbol in discarded section: .text
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
lld-link: error: relocation against symbol in discarded section: .text
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
lld-link: error: relocation against symbol in discarded section: .text
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
lld-link: error: relocation against symbol in discarded section: .text
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
>>> referenced by t1.obj:(.SCOVP$M)
```
t.obj and t1.cpp will trigger vector deleting destructor, t3.cpp will trigger
scalar deleting destructor and a weak alias. What I've noticed is that LINK.exe
(Microsoft linker) is fine with these 3 object files. I don't know what is
going on during linkage when one object file has a definition of vector
deleting destructor, but another object file has only an alias. vector deleting
destructors are generated by this patch with weak linkage. Perhaps support is
needed in lld-link for that case?
The reason why it is triggered by sanitizer build, adding
-fsanitize=fuzzer-no-link option causes adding a bunch of global variables to
IR that reference the destructors and marked with SCOVP$M section:
```
@__sancov_gen_.3 = private constant [10 x ptr] [ptr @"??_EClassA@@UEAAPEAXI@Z",
ptr inttoptr (i64 1 to ptr), ptr blockaddress(@"??_EClassA@@UEAAPEAXI@Z",
%dtor.vector.dtor.continue_crit_edge), ptr null, ptr
blockaddress(@"??_EClassA@@UEAAPEAXI@Z",
%dtor.call_delete_after_array_destroy), ptr null, ptr
blockaddress(@"??_EClassA@@UEAAPEAXI@Z",
%dtor.scalar.dtor.continue.sink.split_crit_edge), ptr null, ptr
blockaddress(@"??_EClassA@@UEAAPEAXI@Z", %dtor.scalar.dtor.continue_crit_edge),
ptr null], section ".SCOVP$M", align 8
```
I'm now heading to the weekend, but I'll look a bit more before claiming
problems in lld-link
@zmodem , thanks for the findings
> So maybe there is something wrong with the vector deleting destructor for
> ICU's UnicodeString or how it's being used.
but, that is still not a great reproducer for a reverted patch. Especially if
the link issue is due to a missing support in linker. I would appreciate if you
could maybe point to how exactly `UnicodeString` is used in failing scenario.
https://github.com/llvm/llvm-project/pull/126240
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
