Assignee: unassigned at sourceware dot org
Reporter: konstantin.s.serebryany at gmail dot com
CC: nickc at redhat dot com
Target Milestone: ---
OSS-Fuzz is a continuous automated fuzzing service, available for open-source
software for free.
https://github.com
https://sourceware.org/bugzilla/show_bug.cgi?id=17498
Kostya Serebryany changed:
What|Removed |Added
CC||konstantin.s.serebryany@gma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517
--- Comment #5 from Konstantin Serebryany 2012-11-28 12:56:53 UTC ---
We try to minimize the number of syscalls we make in asan run-time.
One reason for that is that asan may run in a sanbox which disallows some of
them. (Another is just t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517
--- Comment #3 from Konstantin Serebryany 2012-11-28 12:50:09 UTC ---
[The component for such bugs should be 'sanitizer' but for some reason I can't
change it]
at
||gmail dot com
--- Comment #1 from Konstantin Serebryany 2012-11-28 12:43:32 UTC ---
I am quite sure that asan should not mess with the limits itself.
It gets too messy too soon. (e.g. in tsan we try to reexec if the stack is
unlimited, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55485
--- Comment #4 from Konstantin Serebryany 2012-11-27 17:52:02 UTC ---
For what purpose would any one avoid longjmp call, other than for performance?
Under asan, performance already drops by 2x, so using calls will not hurt much.
Of course
at
||gmail dot com
--- Comment #2 from Konstantin Serebryany 2012-11-27 16:48:48 UTC ---
>> So, does AddressSanitizer support __builtin_setjmp/__builtin_longjmp?
We've never seen those, so I guess not.
Can they be lowered to reg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55488
Bug #: 55488
Summary: Implement cold calls in tsan run-time
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376
Konstantin Serebryany changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolut
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376
--- Comment #10 from Konstantin Serebryany 2012-11-23 12:44:14 UTC ---
libsanitizer/README.gcc was updated, and libsanitizer/merge.sh was create to
help with merges.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #28 from Konstantin Serebryany 2012-11-23 11:14:58 UTC ---
Note that today's upstream tsan sources don't link with -fPIC at all
because our assembly blobs are not PIC-friendly.
/usr/bin/ld: .libs/tsan_rtl_thread.o: relocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376
--- Comment #9 from Konstantin Serebryany 2012-11-23 10:56:44 UTC ---
Not that today's upstream tsan sources don't link with -fPIC at all
because our assembly blobs are not PIC-friendly.
/usr/bin/ld: .libs/tsan_rtl_thread.o: relocation R
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #27 from Konstantin Serebryany 2012-11-23 10:47:14 UTC ---
>> is it really so crucial that you'd want to make another libtsan_pie.a for it?
I would actually prefer to have *only* libtsan_pie.a, and not bother with .so
version at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55435
Bug #: 55435
Summary: [asan] implement an attribute to disable asan
instrumentation for a particular function
Classification: Unclassified
Product: gcc
Version: unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376
--- Comment #8 from Konstantin Serebryany 2012-11-21 04:23:21 UTC ---
>> Why do you want to bother with a ChangeLog?
I don't.
I would prefer to simply mention the upstream revision to which was the last
sync.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55410
Bug #: 55410
Summary: [asan] bit field accesses are not instrumented
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55397
--- Comment #5 from Konstantin Serebryany 2012-11-20 05:46:06 UTC ---
Then it should probably *not* be named _ADDRESS_SANITIZER
(imagine a user trying to understand why ADDRESS_SANITIZER works for him
with clang, where he added -DADDRESS_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376
--- Comment #5 from Konstantin Serebryany 2012-11-20 05:40:34 UTC ---
Merging in both directions is possible, but painful, so I'd prefer to limit it.
How about this phrasing?
===
All changes in this directory should be pre-approved by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55397
Konstantin Serebryany changed:
What|Removed |Added
CC||dnovillo at google dot com
at
||gmail dot com
--- Comment #1 from Konstantin Serebryany 2012-11-20 05:13:27 UTC ---
Note that this will be incompatible with what clang uses
(http://clang.llvm.org/docs/AddressSanitizer.html#has_feature)
Clang will never use a CPP macro
at
||gmail dot com
--- Comment #4 from Konstantin Serebryany 2012-11-19 13:59:31 UTC ---
upstream: http://llvm.org/viewvc/llvm-project?rev=168306&view=rev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #16 from Konstantin Serebryany 2012-11-19 09:06:26 UTC ---
So, using "-fPIC -ftls-model=initial-exec" is a great idea, it will allow
to build the files once and have both static and dynamic library.
But we need to agree that th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #15 from Konstantin Serebryany 2012-11-19 09:03:35 UTC ---
You are right that "-fPIC -ftls-model=initial-exec" does not affect performance
if we link libtsan statically (I checked).
As you say, the linker nukes one of the load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55353
Konstantin Serebryany changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #13 from Konstantin Serebryany 2012-11-19 04:13:23 UTC ---
>> of course everything would need to be done only given appropriate benchmarks
>> of real-world programs.
We have a synthetic benchmark which perfectly reflects the o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #11 from Konstantin Serebryany 2012-11-18 19:59:42 UTC ---
The above comment is correct.
-fPIE is only applicable if we build libtsan.a and link it statically to the
pie executable.
This mode however, works pretty well and mo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #9 from Konstantin Serebryany 2012-11-18 19:35:43 UTC ---
As dvyuokv@ pointed out,
-ftls-model=initial-exec improves the situation, but does not fully help.
Experiment:
% cat x.c
__thread int a;
int foo() {
return
at
||gmail dot com
--- Comment #3 from Konstantin Serebryany 2012-11-18 18:58:00 UTC ---
Note: fully static linking is not supported by libsanitizer at all and I don't
think it will.
Reason: on linux asan uses "dlsym(RTLD_NEXT, ...)&q
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376
--- Comment #3 from Konstantin Serebryany 2012-11-18 18:47:19 UTC ---
>> Are all upstream changes considered reviewed and automatically approved for
>> gcc repo?
all upstream changes are pre- or post- reviewed, so my answer here is "yes"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376
Bug #: 55376
Summary: [asan] libsanitizer/README.gcc must contain the exact
steps to do code changes and to port code from
upstream
Classification: Unclassified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #6 from Konstantin Serebryany 2012-11-16 20:54:40 UTC ---
Answering my own question: we can get static linking with
-Wl,-Bstatic -lasan -Wl,-Bdynamic -ldl -lpthread
>> For TLS, you can just use -ftls-model=initial-exec
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #4 from Konstantin Serebryany 2012-11-16 20:28:34 UTC ---
You have been warned (especially about tsan performance. tsan run-time heavily
depends on TLS, and TLS is much slower with -fPIC than with -fPIE).
Do we have a flag tod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
Bug #: 55354
Summary: [asan] by default, the asan run-time should be linked
statically, not dynamically
Classification: Unclassified
Product: gcc
Version: unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55353
Bug #: 55353
Summary: [asan] the flag for asan should match the one used in
clang
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289
--- Comment #35 from Konstantin Serebryany 2012-11-14 23:10:00 UTC ---
>> Is that certain to be soon enough
Not 100%. I am just warning you.
>> Will the replacement of mach_override also depend on the Core Foundation
>> framework?
Th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289
--- Comment #32 from Konstantin Serebryany 2012-11-14 20:21:19 UTC ---
Just want to repeat, that any work on mach_override may end up being wasted
time
because we plan to get rid of mach_override *really* soon.
at
||gmail dot com
--- Comment #15 from Konstantin Serebryany 2012-11-13 21:27:08 UTC ---
Please not that upstream asan is in the process of getting rid of mach_override
in favor of Mac's function interposition.
at
||gmail dot com
--- Comment #1 from Konstantin Serebryany 2012-11-13 21:10:23 UTC ---
While this is an interesting comparison, I should note that
the typical use of asan is with -O1 or -O2,
so it might make more sense to compare the asan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52629
Bug #: 52629
Summary: global buffer overflow in gcc/reload1.c
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority:
39 matches
Mail list logo
