https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
--- Comment #10 from Yury Gribov ---
> This happens because in LLVM case ASan changes symbols size
> ('f' in our case) and just breaks ABI for the library.
I've filed an upstream bug about this
https://github.com/google/sanitizers/issues/619
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
--- Comment #8 from Maxim Ostapenko ---
(In reply to Reid Kleckner from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > Because symbol size is part of the ABI, and LLVM emits different symbol size
> > between -fsanitize=address and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
--- Comment #9 from Jakub Jelinek ---
(In reply to Maxim Ostapenko from comment #8)
> Jakub is right, here an example, where I believe COPY relocations are not
> involved:
Yeah, that, semantic interposition is used heavily not just by libasan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
--- Comment #4 from Maxim Ostapenko ---
Actualy, LLVM is not better here (perhaps even worse). Consider the following
testcase (it's the same Jakub provided in PR63888):
max@max:/tmp$ cat libfoo.c
long f = 4;
long foo (long *p) {
return *p;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
--- Comment #7 from Reid Kleckner ---
(In reply to Jakub Jelinek from comment #6)
> Because symbol size is part of the ABI, and LLVM emits different symbol size
> between -fsanitize=address and -fno-sanitize=address.
> E.g. COPY relocations use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
Reid Kleckner changed:
What|Removed |Added
CC||rnk at google dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
--- Comment #6 from Jakub Jelinek ---
(In reply to Reid Kleckner from comment #5)
> (In reply to Maxim Ostapenko from comment #4)
> > This happens because in LLVM case ASan changes symbols size ('f' in our
> > case) and just breaks ABI for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
Maxim Ostapenko changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
--- Comment #2 from Maxim Ostapenko ---
Ok, I guess won't fix here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
--- Comment #1 from Jakub Jelinek ---
Yeah, this is intentional design decision, trying to register something for an
object that might be living in completely different library and where the gap
might not be supplied is just wrong.
As the copy
10 matches
Mail list logo
