https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210
Alexander Potapenko changed:
What|Removed |Added
CC||glider at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #6 from Alexander Potapenko ---
The problem is caused by _NSGetEnviron() being called before libSystem is
initialized. This happens because some initialization code calls __cxa_atexit()
before libSystem_initialize(), and __cxa_atexit()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #7 from Alexander Potapenko ---
If I compile stack-overflow-1.c with 'clang -fsanitize=address -c', the
resulting object file can be linked into an executable with either 'clang
-fsanitize=address' or 'gcc -fsanitize=address' (this req
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #8 from Alexander Potapenko ---
Clang's libclang_rt.asan_osx_dynamic.dylib depends on the Foundation framework.
When I remove that dependency, ASanified programs crash on the same env_ptr
assertion.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #10 from Alexander Potapenko ---
This might help, but we don't actually need that dependency.
Instead libsanitizer should be updated to r194573.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #12 from Alexander Potapenko ---
That was Foundation, not sure if CoreFoundation also works.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #14 from Alexander Potapenko ---
I think one of the frameworks depends on another one, please make sure to
pick the latter one if that's true.
Also add a comment denoting this is a dirty workaround.
On Nov 13, 2013 9:38 PM, "howarth at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #16 from Alexander Potapenko ---
I've actually removed the Foundation linkage from LLVM today.
On Nov 13, 2013 10:45 PM, "howarth at nitro dot med.uc.edu" <
gcc-bugzi...@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59148
--- Comment #3 from Alexander Potapenko ---
GCC emits calls to __strcpy_chk and __strncpy_chk in this test, which happens
because of source fortification being on by default on Darwin.
In Clang we're passing -D_FORTIFY_SOURCE=0 when compiling with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59148
--- Comment #5 from Alexander Potapenko ---
I've opened https://code.google.com/p/address-sanitizer/issues/detail?id=247 to
track this. But until that issue is fixed we'll have to disable source
fortification in GCC if ASan is enabled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59369
--- Comment #3 from Alexander Potapenko ---
Should be fine to disable this test on Darwin due to what Yury said.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136
--- Comment #12 from Alexander Potapenko ---
I wonder if https://code.google.com/p/address-sanitizer/issues/detail?id=253 is
relevant here. In the case TSan tests do fork() (which I'm not expecting from
them, however) the parent and the child will
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289
Alexander Potapenko changed:
What|Removed |Added
CC||glider at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289
--- Comment #29 from Alexander Potapenko 2012-11-14
16:40:53 UTC ---
Index: mach_override.c
===
--- mach_override.c(revision 167724)
+++ mach_override.c(working copy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289
--- Comment #39 from Alexander Potapenko 2012-11-15
08:18:01 UTC ---
I agree with Kostya that no major changes to mach_override are necessary
because we are really going to dump it. However minor fixes required for ASan
in GCC to work on D
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289
--- Comment #49 from Alexander Potapenko 2012-11-22
10:43:03 UTC ---
The new interposition library should work on 10.6.
But ASan itself doesn't work on 10.5, at least I remember some problems with
its compilation. We're not really interest
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55599
--- Comment #2 from Alexander Potapenko 2012-12-05
01:07:36 UTC ---
Not that it prohibits the use of static ASan, they just currently can't coexist
in a single program with the current setup. It is theoretically possible to
have them both,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55599
--- Comment #5 from Alexander Potapenko 2012-12-05
04:50:43 UTC ---
The dynamic interposition library is based on the __DATA,__interpose dyld
feature (see http://toves.freeshell.org/interpose/ or Amit Singh's "Mac OS X
Internals" book), wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
Alexander Potapenko changed:
What|Removed |Added
CC||glider at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #6 from Alexander Potapenko 2013-01-29
09:59:09 UTC ---
Looking at the disassembly I see that __asan_init is placed into some
__GLOBAL__sub_I_00099_1_cov.cc function, which isn't being called at runtime
(__GLOBAL__sub_I_cov.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #7 from Alexander Potapenko 2013-01-29
11:56:02 UTC ---
Here's the dump of __mod_init_func (the static ctors array):
===
Disassembly of section __DATA.__mod_init_func:
0001
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #10 from Alexander Potapenko 2013-01-30
12:29:00 UTC ---
I suppose this isn't important. __mod_term_func are destructors, and they even
aren't called in the crashing program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #12 from Alexander Potapenko 2013-01-30
14:32:54 UTC ---
> The question is why does...
>
> if (builtin_decl_implicit_p (BUILT_IN_ASAN_INIT))
> return;
>
> in initialize_sanitizer_builtins() not emit a __asan_init whi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #20 from Alexander Potapenko 2013-01-30
17:07:25 UTC ---
(In reply to comment #19)
> Well, if somebody does the work and in a clean way that won't penalize targets
> with sane linkers and object formats, I'm not objecting, I ju
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #21 from Alexander Potapenko 2013-01-30
17:30:18 UTC ---
Created attachment 29309
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29309
Dummy patch that reverses the order of the constructors
Attached is a hacky POC patc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #48 from Alexander Potapenko 2013-02-04
10:11:32 UTC ---
(In reply to comment #40)
> if (ctor_recA->position > ctor_recB->position)
> return -1;
> if (ctor_recA->position < ctor_recB->position)
> return 1;
>
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #49 from Alexander Potapenko 2013-02-04
10:13:49 UTC ---
I agree with Jakub: it's better to return back to the qsort version of the
patch, since it fixes ASan as well, but also provides better support for
priorities in general.
27 matches
Mail list logo
