https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #41 from Maxim Ostapenko ---
Author: chefmax
Date: Wed Oct 21 07:47:54 2015
New Revision: 229114
URL: https://gcc.gnu.org/viewcvs?rev=229114=gcc=rev
Log:
libsanitizer/
PR bootstrap/63888
Reapply:
2015-02-20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
Maxim Ostapenko changed:
What|Removed |Added
CC||chefmax at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #39 from Yury Gribov y.gribov at samsung dot com ---
(In reply to Jakub Jelinek from comment #36)
(In reply to Yury Gribov from comment #35)
(In reply to Kostya Serebryany from comment #34)
Frankly, I am not at all motivated to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #36 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Yury Gribov from comment #35)
(In reply to Kostya Serebryany from comment #34)
Frankly, I am not at all motivated to do any significant surgery in the llvm
compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #37 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Mon Feb 23 21:01:57 2015
New Revision: 220919
URL: https://gcc.gnu.org/viewcvs?rev=220919root=gccview=rev
Log:
PR bootstrap/63888
* asan/asan_globals.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #31 from Jakub Jelinek jakub at gcc dot gnu.org ---
Any progress on this?
If not, I'm considering doing:
--- libsanitizer/asan/asan_globals.cc.jj2014-11-14 00:10:34.0 +0100
+++ libsanitizer/asan/asan_globals.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #32 from Yury Gribov y.gribov at samsung dot com ---
Or (probably less intrusive) add detect_odr_violation=0 to ASAN_OPTIONS
config/bootstrap-asan.mk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #33 from Jakub Jelinek jakub at gcc dot gnu.org ---
That is not sufficient. The bug affects all programs, not just gcc when
bootstrapping it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #35 from Yury Gribov y.gribov at samsung dot com ---
(In reply to Kostya Serebryany from comment #34)
Frankly, I am not at all motivated to do any significant surgery in the llvm
compiler instrumentation because for me everything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #34 from Kostya Serebryany kcc at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #31)
Any progress on this?
If not, I'm considering doing:
--- libsanitizer/asan/asan_globals.cc.jj 2014-11-14 00:10:34.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #30 from Eric Christopher echristo at gmail dot com ---
That might be reasonable. As far as I know ld64 doesn't do that yet, but I know
it's been thought about.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #29 from Jakub Jelinek jakub at gcc dot gnu.org ---
Perhaps you can emit another symbol covering the original size plus padding in
that case on targets where linker can do something so problematic.
So you'd end up having e.g. symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #25 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Eric Christopher from comment #24)
For the record btw, I don't believe there's a reason why the linker couldn't
split up the data section by knowing the size of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #26 from Eric Christopher echristo at gmail dot com ---
Sure. Not the general case for other targets though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #27 from Jakub Jelinek jakub at gcc dot gnu.org ---
And even without section anchors, there is no guarantee there aren't relative
relocations in between the symbols, that just have been applied already at
assembly time (say
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #28 from Eric Christopher echristo at gmail dot com ---
Ah, but not every platform is ELF :)
ld64 has the flexibility to do this with Mach-O. As I said, I don't have any
better ideas at the moment, but warning that it is possible to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #23 from Eric Christopher echristo at gmail dot com ---
So, I think Jakub's solution is strictly better here as it allows intermixing
of asan and non-asan code. It'll involve a bit of work in llvm's middle end to
keep track of symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #24 from Eric Christopher echristo at gmail dot com ---
For the record btw, I don't believe there's a reason why the linker couldn't
split up the data section by knowing the size of the variable so it's worth
being very careful here -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #14 from Kostya Serebryany kcc at gcc dot gnu.org ---
(In reply to Yury Gribov from comment #13)
(In reply to Kostya Serebryany from comment #12)
But for this example in C the globals will not get instrumented, unless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Kostya Serebryany from comment #14)
We should be careful when instrumenting something that can be redefined
because the
definition may be no-instrumented.
But that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #16 from Kostya Serebryany kcc at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #15)
(In reply to Kostya Serebryany from comment #14)
We should be careful when instrumenting something that can be redefined
because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Kostya Serebryany from comment #16)
Frankly, I realize that I don't understand the subtleties of this problem.
:(
First, if this is C++ we clearly have a bug (ODR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #18 from Kostya Serebryany kcc at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #17)
(In reply to Kostya Serebryany from comment #16)
Frankly, I realize that I don't understand the subtleties of this problem.
:(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Kostya Serebryany from comment #18)
I am disoriented.
Can you please give a full repro (with command lines, etc) where
we'll now produce a false positive (in clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #20 from Kostya Serebryany kcc at gcc dot gnu.org ---
Is this clear? This is on access of the b1 variable defined in main.c,
certainly not anything around f variable defined in libfoo.c.
Yea. Thanks. Pondering...
I am still not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Kostya Serebryany from comment #20)
Is this clear? This is on access of the b1 variable defined in main.c,
certainly not anything around f variable defined in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
Kostya Serebryany kcc at gcc dot gnu.org changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #13 from Yury Gribov y.gribov at samsung dot com ---
(In reply to Kostya Serebryany from comment #12)
But for this example in C the globals will not get instrumented, unless
-fno-common is given.
BTW I think everyone already pairs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Kostya Serebryany from comment #8)
You haven't responded about the language thing, there is no such thing as
ODR in C or Fortran, so you shouldn't report it.
In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #10 from Yury Gribov y.gribov at samsung dot com ---
(In reply to Kostya Serebryany from comment #8)
(sorry for delay, I missed the last comment)
Generally, we do want to instrument even artificial variables, and on many
of them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #11 from Yury Gribov y.gribov at samsung dot com ---
(In reply to Jakub Jelinek from comment #9)
An ODR violation is IMHO something different, it is the case where you have
the same symbol name (but, you'd need to distinguish
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #12 from Kostya Serebryany kcc at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #9)
(In reply to Kostya Serebryany from comment #8)
You haven't responded about the language thing, there is no such thing as
ODR in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #8 from Kostya Serebryany kcc at gcc dot gnu.org ---
(sorry for delay, I missed the last comment)
Generally, we do want to instrument even artificial variables, and on many
of them buffer overflow is possible.
Yea, agree.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Kostya Serebryany from comment #6)
(In reply to Yury Gribov from comment #5)
Perhaps ODR check should check that names of global variables match before
issuing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
Yury Gribov y.gribov at samsung dot com changed:
What|Removed |Added
CC||y.gribov at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #6 from Kostya Serebryany kcc at gcc dot gnu.org ---
(In reply to Yury Gribov from comment #5)
Perhaps ODR check should check that names of global variables match before
issuing warning?
The variables are generated by the compiler,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |5.0
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org ---
Author: hjl
Date: Mon Nov 17 22:12:55 2014
New Revision: 217678
URL: https://gcc.gnu.org/viewcvs?rev=217678root=gccview=rev
Log:
Export detect_leaks=0
PR bootstrap/63888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
41 matches
Mail list logo
