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,"",@progbits,unique,1
.quad 0
.section aa,"a",@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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
