[llvm] [compiler-rt] [clang] [Profile] Refactor profile correlation. (PR #70856)
Fangrui Song via llvm-commits
llvm-commits at lists.llvm.org
Fri Nov 10 10:59:02 PST 2023
MaskRay wrote:
I am nervous with new `if (hasCorrelation())` conditions as well.
If you use the same name for a non-SHF_ALLOC section and a SHF_ALLOC section, the linked output has the SHF_ALLOC flag and you cannot tell what components were non-SHF_ALLOC.
```
.section aa,"", at progbits,unique,1
.quad 0
.section aa,"a", at progbits,unique,2
.quad 0
```
Usually, the better idea is to use different section names. It may require some trial and error to see how much complexity this scheme will bring.
> I feel like this is a bug in lld as _start/_stop symbols for non allocated sections should be null.
It isn't. This is "undefined behavior, no diagnostic required".
For
```
extern char __start___llvm_covfun __attribute__((weak));
extern char __stop___llvm_covfun __attribute__((weak));
int main() {
printf("%p, %p\n", &__start___llvm_covfun, &__stop___llvm_covfun);
return 0;
}
```
The program is ill-formed when `__llvm_covfun` does not have the SHF_ALLOC flag.
`__start_`/`__stop_` symbols were not designed to be used with non-SHF_ALLOC output sections.
It's invalid to reference a non-SHF_ALLOC section from SHF_ALLOC code. The regular undefined weak rule (handwavy "Unresolved weak symbols have a zero value." in the specification) does not necessarily apply.
I noticed that GNU ld defines `__start_`/`__stop_` as well and its linked a.out prints non-zero addresses, just like lld.
https://github.com/llvm/llvm-project/pull/70856
More information about the llvm-commits
mailing list