[Bug other/55517] [ASAN] ASAN doesn't work with (soft) ulimit on virtual memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC||konstantin.s.serebryany at ||gmail dot com --- Comment #1 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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 it's not reliable). I agree, the messages could be less cryptic.
[Bug other/55517] [ASAN] ASAN doesn't work with (soft) ulimit on virtual memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517 --- Comment #3 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-28 12:50:09 UTC --- [The component for such bugs should be 'sanitizer' but for some reason I can't change it]
[Bug sanitizer/55517] [ASAN] ASAN doesn't work with (soft) ulimit on virtual memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517 --- Comment #5 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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 the code bloat) Why simply removing all the limits before running asan doesn't work? Better warning messages will make it move obvious.
[Bug sanitizer/55488] New: Implement cold calls in tsan run-time
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 Priority: P3 Component: sanitizer AssignedTo: unassig...@gcc.gnu.org ReportedBy: konstantin.s.serebry...@gmail.com CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org, ja...@gcc.gnu.org, k...@gcc.gnu.org, w...@gcc.gnu.org The hottest functions in tsan run-time make two cold calls: __tsan_report_race and __tsan_trace_switch If these calls are implemented via regular calling convention, they ruin the performance since the compiler creates too many spills. So, we've manually implemented a cold-call calling convention using a separate assembly file, libsanitizer/tsan/tsan_rtl_amd64.S Currently, this hack is disabled in GCC causing the tsan run-time to be slower than it could be: libsanitizer/tsan/tsan_rtl.h: #if 0 TSAN_DEBUG == 0 ... #define HACKY_CALL(f) \ We need to enable building/linking the file libsanitizer/tsan/tsan_rtl_amd64.S and enable the HACKY_CALL in libsanitizer/tsan/tsan_rtl.h. This will eliminate the only difference left between the gcc version and upstream. Or maybe gcc has another way to implement a cold call?
[Bug sanitizer/55485] probable false positive on __builtin_setjmp/__builtin_longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55485 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC||konstantin.s.serebryany at ||gmail dot com --- Comment #2 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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 regular setjmp/longjmp calls? If yes, then the run-time library interceptor should take care of them.
[Bug sanitizer/55485] probable false positive on __builtin_setjmp/__builtin_longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55485 --- Comment #4 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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, we could instrument __builtin_longjmp call in the compiler module, but is it worth it? If yes, all we need is to call __asan_handle_no_return before __builtin_longjmp
[Bug sanitizer/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #27 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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 all. This is what we have in clang land.
[Bug sanitizer/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 --- Comment #9 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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_X86_64_PC32 against undefined symbol `__tsan_trace_switch_thunk' can not be used when making a shared objec Apparently, Wei hacked this around by enabling pure-C++ code, which is slower.
[Bug sanitizer/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #28 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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 R_X86_64_PC32 against undefined symbol `__tsan_trace_switch_thunk' can not be used when making a shared objec Apparently, Wei hacked this around by enabling pure-C++ code, which is slower.
[Bug sanitizer/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 --- Comment #10 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-23 12:44:14 UTC --- libsanitizer/README.gcc was updated, and libsanitizer/merge.sh was create to help with merges.
[Bug sanitizer/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-23 12:56:57 UTC --- fixed
[Bug other/55435] New: [asan] implement an attribute to disable asan instrumentation for a particular function
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 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: konstantin.s.serebry...@gmail.com CC: dnovi...@google.com, dseke...@redhat.com, dvyu...@google.com, hjl.to...@gmail.com, ja...@redhat.com, w...@gcc.gnu.org The clang implementation of asan has __attribute__((no_address_safety_analysis)): (http://clang.llvm.org/docs/AddressSanitizer.html#no_address_safety_analysis) Some code should not be instrumented by AddressSanitizer. One may use the function attribute no_address_safety_analysis to disable instrumentation of a particular function. This attribute may not be supported by other compilers, so we suggest to use it together with __has_feature(address_sanitizer). Note: currently, this attribute will be lost if the function is inlined. The gcc implementation needs a similar attribute (preferably, with the same syntax and semantics) One example where this attribute is used: V8 stack profiler which touches random bytes on the stack.
[Bug other/55410] New: [asan] bit field accesses are not instrumented
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
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: konstantin.s.serebry...@gmail.com
CC: dseke...@redhat.com, dvyu...@google.com,
ja...@gcc.gnu.org, w...@gcc.gnu.org
[There is no rush with this, I just want this issue to be recorded]
% cat bitf.c
typedef struct {
int a:12;
int b:20;
} foo;
int geta(foo *f) {
return f-a;
}
% clang -fsanitize=address -O2 -S -o - bitf.c 21 | grep __asan_report
callq __asan_report_load4
% gcc -faddress-sanitizer -O2 -S -o - bitf.c 21 | grep __asan_report
%
[Bug other/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 --- Comment #8 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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.
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #15 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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 loads. But if we link libtsan.so dynamically, we still get both sources of overhead.
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #16 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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 the dynamic library is noticeably slower.
[Bug other/55333] libsanitizer StackTrace::FastUnwindStack wrong x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55333 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC||konstantin.s.serebryany at ||gmail dot com --- Comment #4 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-19 13:59:31 UTC --- upstream: http://llvm.org/viewvc/llvm-project?rev=168306view=rev
[Bug c/55397] [asan] -faddress-sanitizer should define a CPP macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55397 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC||konstantin.s.serebryany at ||gmail dot com --- Comment #1 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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 (I've lost this battle a year ago). Just FYI. I don't know how much compatibility we want and can achieve.
[Bug c/55397] [asan] -faddress-sanitizer should define a CPP macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55397 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC||dnovillo at google dot com --- Comment #3 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-20 05:30:59 UTC --- FTR: my conversation with clang on this topic. http://comments.gmane.org/gmane.comp.compilers.clang.scm/42610 From Diego: I don't know of any current effort in this area for GCC. If __has_feature() is desirable, patches documenting and implementing it would be welcome. The GCC pre-processor is jointly maintained by all the FE maintainers. I would start there. If we end up implementing a macro, may I ask it to be named ADDRESS_SANITIZER? This name is already used in a few places (Chromium, WebKit, etc).
[Bug other/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 --- Comment #5 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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 one of the maintainers. Trivial and urgent fixes (portability, build fixes, etc) may go directly to the gcc tree. All non-trivial changes, functionality improvements, etc should go through the upstream tree first and then be merged back to the gcc tree. === I also want to have a semi-automated way to pull the updates from upstream. What is the preferred scripting language? Is bash (python, perl) ok? When pulling a new update, what text do we expect in the ChangeLog? Is the upstream SVN revision enough, or we want to copy all commit messages?
[Bug c/55397] [asan] -faddress-sanitizer should define a CPP macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55397 --- Comment #5 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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_SANITIZER=1 manually, and dpoes not work with gcc where he saw the documentation saying about _ADDRESS_SANITIZER) Maybe something with GCC in the name? _GCC_ADDRESS_SANITIZER?
[Bug other/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 --- Comment #3 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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. That's not acceptable. We don't want to have to go through LLVM to fix issues in GCC, especially for the platforms that LLVM doesn't support, i.e. most of them. I've got your point, but please understand mine: if the trees go too much out of sync we (the asan team) will lose control over one of the copies (gcc). It will mean that some one else (not us) will have to work on asan in gcc. Maybe that's not bad, but I don't want it. Syncing the trees in the presence of difference in the comment headers make the syncing task a tiny bit more challenging. I hope that at some point when we get enough contributions to libsanitizer from the GCC community, we will be able to unify the headers by saying This is part of LLVM and GCC projects. WDYT? As I understood from previous e-mails, there are libraries with similar problems in the gcc tree. What are the solutions there? Introducing such regressions is acceptable, provided that they can be quickly fixed by the target maintainers. It's great that such regressions is acceptable, but if there is an infrastructure that allows us to know about possible regressions before the commit (aka try bots), I'd like to know.
[Bug driver/55379] -static -static-libasan pass -Bdynamic to linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55379 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC||konstantin.s.serebryany at ||gmail dot com --- Comment #3 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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, ...) and on Mac it uses (will soon use) function inerposition. Neither works for fully static binaries, afaict.
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #9 from Konstantin Serebryany konstantin.s.serebryany at gmail dot
com 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 a;
}
HORRIBLE: -fPIC -shared
% gcc x.c -O2 -fPIC -shared -o x.so ; objdump -d x.so | grep foo.: -A 5
06e0 foo:
6e0: 66 48 8d 3d f0 08 20lea0x2008f0(%rip),%rdi# 200fd8
_DYNAMIC+0x1b8
6e7: 00
6e8: 66 66 48 e8 10 ff ffcallq 600 __tls_get_addr@plt
6ef: ff
6f0: 8b 00 mov(%rax),%eax
NOT-SO-BAD: -fPIC -shared -ftls-model=initial-exec
% gcc x.c -O2 -fPIC -shared -o x.so -ftls-model=initial-exec ; objdump -d x.so
| grep foo.: -A 5
0630 foo:
630: 48 8b 05 a9 09 20 00mov0x2009a9(%rip),%rax# 200fe0
_DYNAMIC+0x1b8
637: 64 8b 00mov%fs:(%rax),%eax
63a: c3 retq
GOOD: -fPIE
% gcc -c x.c -O2 -fPIE -o x.o ; objdump -d x.o | grep foo.: -A 5
foo:
0: 64 8b 04 25 00 00 00mov%fs:0x0,%eax
7: 00
8: c3 retq
So, while -ftls-model=initial-exec improves the TLS performance, it is still
2x slower than -fPIE.
For tsan, which does this for *every* memory access in the original program,
this will cost 5%-10% slowdown.
For our users this is a big deal, so they will link the static library whenever
possible. Which default is used in gcc -- I don't care that much.
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #11 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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 most our users pay this price for performance. On every memory access tsan touches a few (two or three) extra cache lines. Not using -fPIE makes it touch one extra cache line. Even if that line is in L1, it still has a non-zero cost. We will try to provide benchmark numbers next week.
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #13 from Konstantin Serebryany konstantin.s.serebryany at gmail
dot com 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 only major hot spot
in tsan: the set of functions __tsan_{read,write}{1,2,4,8} that are called on
every memory access.
When building libtsan as a shared library (for which I had to hack our assembly
blobs a bit) we get two sources of slowdown:
1. __tsan_read8 and friends are called through PLT
2. __tsan_read8 and friends use one extra load to get to TLS
The result is 10% slowdown.
[Bug other/55353] [asan] the flag for asan should match the one used in clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55353 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||wmi at gcc dot gnu.org --- Comment #1 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-19 05:20:24 UTC --- Wei, this needs to happen ASAP, otherwise there will be too many places with the old flag.
[Bug other/55376] New: [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream
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 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: konstantin.s.serebry...@gmail.com CC: dseke...@redhat.com, dvyu...@google.com, ja...@redhat.com, w...@gcc.gnu.org We need to document the libsanitizer update process in libsanitizer/README.gcc Few things to cover: - The changes need to be approved by one of the maintainers (or is it obvious)? - Except for *really* trivial changes all patches should go through the upstream tree first. - When updating from upstream, the comment header should be tampered with (oh, my) - Ideally, we need to have a fully automated script to grab the upstream changes (including new/deleted/moved files, etc). Suggestions here? - What is the testing procedure when updating from upstream? (e.g. how do we avoid regressions on the platforms to which the maintainers have no access?)
[Bug other/55353] New: [asan] the flag for asan should match the one used in clang
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: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: konstantin.s.serebry...@gmail.com CC: dseke...@redhat.com, dvyu...@google.com, ja...@redhat.com Currently, gcc trunk uses -faddress-sanitizer Clang has recently changed the flag to -fsanitize=address (there was a data race between clang change and gcc review-commit cycle :) We need to match the flags. Same applies to tsan (seems like it is not committed to gcc yet)
[Bug other/55354] New: [asan] by default, the asan run-time should be linked statically, not dynamically
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 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: konstantin.s.serebry...@gmail.com CC: dseke...@redhat.com, dvyu...@google.com, ja...@redhat.com Today, -faddress-sanitizer (to be changed to -fsanitize=address) causes the asan run-time library to be linked dynamically. It needs to be changed to static linkage because - it matches clang behavior - causes less confusion for users (where is my libasan.so???) - better for tsan performance (we'll need to link tsan statically too) Note that on MacOS we probably want to keep using dynamic linkage since the future library-interposition-based run-time will require it.
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #4 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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 today which will cause libasan.a to be linked statically, while not forcing anything else to link statically?
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #6 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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 did not know, thanks. Sounds like this could be a good solution for tsan. Will check.
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 --- Comment #32 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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.
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 --- Comment #35 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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? That's the question to Alex.
[Bug other/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC||konstantin.s.serebryany at ||gmail dot com --- Comment #1 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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 implementations at -O1/-O2
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC||konstantin.s.serebryany at ||gmail dot com --- Comment #15 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 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.
[Bug rtl-optimization/52629] New: global buffer overflow in gcc/reload1.c
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: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: konstantin.s.serebry...@gmail.com
Building gcc trunk (r185531, linux, x86_64) with AddressSanitizer (a memory
error detector)
shows a global buffer overflow in gcc/reload1.c while compiling
libgcc/libgcc2.c with ./gcc/xgcc
==21687== ERROR: AddressSanitizer global-buffer-overflow on address
0x02ddc551 at pc 0xf98a5f bp 0x7fffdcbe1050 sp 0x7fffdcbe1048
READ of size 1 at 0x02ddc551 thread T0
#0 0xf98a5f in count_spilled_pseudo gcc/reload1.c:1830
#1 0xf715a6 in bmp_iter_set_init gcc/bitmap.h:385
#2 0xd55dc2 in do_reload gcc/ira.c:3733
#3 0xea9e0d in execute_one_pass gcc/passes.c:2084
#4 0xeaaf4d in execute_pass_list gcc/passes.c:2139
#5 0xeaaf71 in execute_pass_list gcc/passes.c:2141
#6 0x1200802 in invoke_plugin_callbacks gcc/plugin.h:57
#7 0x81917d in cgraph_expand_function gcc/cgraphunit.c:1840
#8 0x820425 in cgraph_expand_all_functions gcc/cgraphunit.c:1904
#9 0x81c655 in timevar_pop gcc/timevar.h:110
#10 0x4ebc2e in c_write_global_declarations gcc/c-decl.c:10053
#11 0x10b82c5 in compile_file gcc/toplev.c:575
#12 0x2b1cbf568c4d in __libc_start_main
/build/buildd/eglibc-2.11.1/csu/libc-start.c:258
0x02ddc551 is located 17 bytes to the right of global variable
'default_target_hard_regs (../../gcc_trunk/gcc/reginfo.c)' (0x2dd9d80) of size
10176
The buggy lines:
static void
count_spilled_pseudo (int spilled, int spilled_nregs, int reg)
{
int freq = REG_FREQ (reg);
int r = reg_renumber[reg];
int nregs = hard_regno_nregs[r][PSEUDO_REGNO_MODE (reg)];
the value of 'r' can be -1, thus the buffer overflow.
One can confirm this bug by changing the code like this and performing full gcc
build:
count_spilled_pseudo (int spilled, int spilled_nregs, int reg)
{
int freq = REG_FREQ (reg);
int r = reg_renumber[reg];
int nregs;
gcc_assert(r = 0); /**/
nregs = hard_regno_nregs[r][PSEUDO_REGNO_MODE (reg)];
