[Bug c/87210] [RFE] introduce build time options to zero initialize automatic stack variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210 Alexander Potapenko changed: What|Removed |Added CC||glider at google dot com --- Comment #4 from Alexander Potapenko --- To give an update, upstream Clang now supports force initialization of stack variables under the -ftrivial-auto-var-init flag. -ftrivial-auto-var-init=pattern initializes local variables with a 0xAA pattern (actually it's more complicated, see https://reviews.llvm.org/D54604) -ftrivial-auto-var-init=zero provides zero-initialization of locals. This mode isn't officially supported yet and is hidden behind an additional -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang flag. This is done to avoid creating a C++ dialect where all variables are zero-initialized. Starting v5.2, Linux kernel has a CONFIG_INIT_STACK_ALL config that performs the build with -ftrivial-auto-var-init=pattern. This one isn't widely adopted yet, partially because initializing locals with 0xAA isn't fast enough. Linus Torvalds is quite positive about zero-initializing the locals though, see https://lkml.org/lkml/2019/7/30/1303 So having a flag similar to -ftrivial-auto-var-init=zero in GCC will be appreciated by the Linux kernel community.
[Bug sanitizer/59136] [4.9 Regression] llvm-symbolizer shouldn't be started always
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136 --- Comment #12 from Alexander Potapenko glider at google dot com --- 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 share the same symbolizer, which will just fail to multiplex their queries.
[Bug sanitizer/59369] c-c++-common/asan/pr59063-[1,2].c fails on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59369 --- Comment #3 from Alexander Potapenko glider at google dot com --- Should be fine to disable this test on Darwin due to what Yury said.
[Bug sanitizer/59148] FAIL: c-c++-common/asan/strncpy-overflow-1.c -O0 execution test on darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59148 --- Comment #5 from Alexander Potapenko glider at google dot com --- 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.
[Bug sanitizer/59148] FAIL: c-c++-common/asan/strncpy-overflow-1.c -O0 execution test on darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59148 --- Comment #3 from Alexander Potapenko glider at google dot com --- 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 -fsanitize=address. I've checked that manually adding -D_FORTIFY_SOURCE=0 fixes strncpy-overflow-1.c Jack, can you please make the changes in the GCC driver?
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #6 from Alexander Potapenko glider at google dot com --- 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() calls __asan_init() and _NSGetEnviron(). The fix is trivial (call the real __cxa_atexit() if asan_inited == 0 instead of calling __asan_init()), but before landing it I'll check why the crash doesn't happen on LLVM (I suspect different linkage order).
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #7 from Alexander Potapenko glider at google dot com --- 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 requires declaring void *__asan_mapping_offset=0x1000;, since the GCC instrumentation pass doesn't insert the mapping offset). The executable linked with Clang works just fine, while the GCC one crashes on the same env_ptr assertion. Clang: $ $CLANG stack-overflow-1.o -fsanitize=address -v ./a.out ... /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.8.0 -o a.out stack-overflow-1.o -lstdc++ /Users/glider/src/asan/llvm/llvm_cmake_build/bin/../lib/clang/3.4/lib/darwin/libclang_rt.asan_osx_dynamic.dylib -lSystem = ==37032==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff5add8aea at pc 0x104e27c93 bp 0x7fff5add89f0 sp 0x7fff5add89e8 ... GCC: $ $GCC stack-overflow-1.o -fsanitize=address -v ./a.out ... /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.8.5 -weak_reference_mismatches non-weak -o a.out -L/Users/glider/src/gcc-asan/build/inst/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0 -L/Users/glider/src/gcc-asan/build/inst/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/../../.. stack-overflow-1.o -lasan -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v ... ==37029==AddressSanitizer CHECK failed: ../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc:146 ((env_ptr)) != (0) (0x0, 0x0) This seems to have nothing to do with the linkage order: I've tried to change the order of -l flags in the ld invocation from $GCC, but that didn't work. However when I replaced '-lasan' with the full path to the ASan runtime from the Clang build, it worked fine. So there's some subtle difference between the ASan runtimes compiled when building GCC and Clang.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #8 from Alexander Potapenko glider at google dot com --- 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.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #10 from Alexander Potapenko glider at google dot com --- This might help, but we don't actually need that dependency. Instead libsanitizer should be updated to r194573.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #12 from Alexander Potapenko glider at google dot com --- That was Foundation, not sure if CoreFoundation also works.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #14 from Alexander Potapenko glider at google dot com --- 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 nitro dot med.uc.edu gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #13 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Alexander Potapenko from comment #12) That was Foundation, not sure if CoreFoundation also works. Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at r204750 suppresses all of the failures in asan.exp on x86_64-apple-darwin12. Retesting with -Wl,-framework,Foundation. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #16 from Alexander Potapenko glider at google dot com --- 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?id=58994 --- Comment #15 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Alexander Potapenko from comment #14) 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 nitro dot med.uc.edu gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #13 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Alexander Potapenko from comment #12) That was Foundation, not sure if CoreFoundation also works. Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at r204750 suppresses all of the failures in asan.exp on x86_64-apple-darwin12. Retesting with -Wl,-framework,Foundation. -- You are receiving this mail because: You are on the CC list for the bug. The Foundation framework is already linked against the CoreFoundation framework. I've confirmed that linking libasan against -Wl,-framework,Foundation alone (as is done by llvm) is sufficient to suppress the asan.exp failures. This change will duplicate the linkage used by llvm for the asan shared library. Posted proposed patch at http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01499.html, -- You are receiving this mail because: You are on the CC list for the bug.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #48 from Alexander Potapenko glider at google dot com 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; This is wrong. I think we want this reversed as well. We want original order. A testcase with two ctors, should in the end have the one with the lower original position first. So, for me to approve it, I need to know if sorting just inside 1 translation unit is enough to make -fsanitize=address work. I fear the answer to that is no, and without cross translation unit support, this is just bug pushing (obscuring a bug with a non-fix that just makes fixing it even harder). I won't approve it if it is bug pushing. If cross has to work, then cross shared libraries I suspect has to work as well. In LLVM this is done without cross-TU: we just emit a call to __asan_init per TU and append it to the list of global constructors for the current module (note that the constructors' priorities on Darwin do not work across modules at all: http://llvm.org/bugs/show_bug.cgi?id=12556
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #49 from Alexander Potapenko glider at google dot com 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.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #10 from Alexander Potapenko glider at google dot com 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.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #12 from Alexander Potapenko glider at google dot com 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 while apparently... I'm guessing initialize_sanitizer_builtins() just warms something up, but doesn't actually emit any code. IANAGCCH though. tree fn = builtin_decl_implicit (BUILT_IN_ASAN_INIT); in asan_finish_file() emits an apparenty unnecessary one in the wrong section. This one is a necessary one. asan_finish_file inserts __asan_init into the array of constructors (aka __mod_init_func section). But for some reason it is inserted at the end of that array, while the constructors are being executed from the start of the array at program startup. That's why the program crashes (because it's trying to execute some instrumented code that accesses the shadow memory, which isn't mapped yet), and the real question is how do we put the new constructor first provided that the ctor priorities do not work well on Darwin.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #20 from Alexander Potapenko glider at google dot com 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 just am not going to spend time on this. If clang can handle ctor priorities right at least inside of each individual CUs, perhaps those that care about targets which don't support that in the linker can add similar support to gcc (what I've been suggesting, if priorities aren't supported by linker, don't emit stuff right away, but just queue it and at the end sort it and emit. Looks like you're right and the constructors are just being emitted by machopic_asm_out_constructor() in gcc/config/darwin.c, so ASan just has no chance to add his ctor before the default one. I suppose this can be fixed in gcc/config/darwin.c, but we don't have enough knowledge and/or cycles for this. Perhaps the right thing to do is to file a bug against the owner of that file.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #21 from Alexander Potapenko glider at google dot com 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 patch that intends to just reverse the order of constructors in the module. It fixes the current problem with ASan ctor being the last one (it is the first one now), yet it doesn't fix the missing support for priorities. It also contains a fixed-size array of ctors, which needs to be replaced with some dynamic structure. I also have no idea what rtx is and whether it remains allocated throughout the compilation or we're just using dangling pointers.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
Alexander Potapenko glider at google dot com changed:
What|Removed |Added
CC||glider at google dot com
--- Comment #5 from Alexander Potapenko glider at google dot com 2013-01-29
09:49:44 UTC ---
Here's a smaller repro for this problem:
$ cat cov.cc
struct c18 {
virtual void bar() { }
};
c18 ret;
int main () {
}
=
$ inst/bin/g++ -fsanitize=address cov.cc -o cov -g
$ gdb cov
(gdb) r
Starting program: /Users/glider/src/gcc_failures/asan_g++_failures/cov
Reading symbols for shared libraries . done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x1000221c
0x00010dd2 in c18::c18 (this=0x110e0) at cov.cc:1
1 struct c18 {
(gdb) bt
#0 0x00010dd2 in c18::c18 (this=0x110e0) at cov.cc:1
#1 0x00010d5a in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535) at cov.cc:4
#2 0x00010d6f in _GLOBAL__sub_I_cov.cc () at cov.cc:6
#3 0x7fff5fc13378 in
__dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
()
#4 0x7fff5fc13762 in
__dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE
()
#5 0x7fff5fc1006e in
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
()
#6 0x7fff5fc0feba in
__dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE
()
#7 0x7fff5fc01fc0 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#8 0x7fff5fc05b04 in
__dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_Pm ()
#9 0x7fff5fc01397 in
__dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_Pm ()
#10 0x7fff5fc0105e in __dyld__dyld_start ()
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #6 from Alexander Potapenko glider at google dot com 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 is called instead): 00010d31 __Z41__static_initialization_and_destruction_0ii: 10d31: 55 push %rbp 10d32: 48 89 e5mov%rsp,%rbp 10d35: 48 83 ec 10 sub$0x10,%rsp 10d39: 89 7d fcmov%edi,-0x4(%rbp) 10d3c: 89 75 f8mov%esi,-0x8(%rbp) 10d3f: 83 7d fc 01 cmpl $0x1,-0x4(%rbp) 10d43: 75 15 jne10d5a __Z41__static_initialization_and_destruction_0ii+0x29 10d45: 81 7d f8 ff ff 00 00cmpl $0x,-0x8(%rbp) 10d4c: 75 0c jne10d5a __Z41__static_initialization_and_destruction_0ii+0x29 10d4e: 48 8d 3d 8b 03 00 00lea0x38b(%rip),%rdi# 110e0 _ret 10d55: e8 9c 00 00 00 callq 10df6 __ZN3c18C1Ev$stub 10d5a: c9 leaveq 10d5b: c3 retq 00010d5c __GLOBAL__sub_I_cov.cc: 10d5c: 55 push %rbp 10d5d: 48 89 e5mov%rsp,%rbp 10d60: be ff ff 00 00 mov$0x,%esi 10d65: bf 01 00 00 00 mov$0x1,%edi 10d6a: e8 c2 ff ff ff callq 10d31 __Z41__static_initialization_and_destruction_0ii 10d6f: 5d pop%rbp 10d70: c3 retq 00010d71 __GLOBAL__sub_D_00099_0_cov.cc: 10d71: 55 push %rbp 10d72: 48 89 e5mov%rsp,%rbp 10d75: be 01 00 00 00 mov$0x1,%esi 10d7a: 48 8d 3d 1f 03 00 00lea0x31f(%rip),%rdi# 110a0 __ZTI3c18+0x20 10d81: e8 88 00 00 00 callq 10e0e ___asan_unregister_globals$stub 10d86: 5d pop%rbp 10d87: c3 retq 00010d88 __GLOBAL__sub_I_00099_1_cov.cc: 10d88: 55 push %rbp 10d89: 48 89 e5mov%rsp,%rbp 10d8c: e8 6b 00 00 00 callq 10dfc ___asan_init$stub 10d91: be 01 00 00 00 mov$0x1,%esi 10d96: 48 8d 3d 03 03 00 00lea0x303(%rip),%rdi# 110a0 __ZTI3c18+0x20 10d9d: e8 60 00 00 00 callq 10e02 ___asan_register_globals$stub 10da2: 5d pop%rbp 10da3: c3 retq
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #7 from Alexander Potapenko glider at google dot com 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: 00011040 __DATA.__mod_init_func: 11040: 5c pop%rsp 11041: 0d 00 00 01 00 or $0x1,%eax 11046: 00 00 add%al,(%rax) 11048: 88 0d 00 00 01 00 mov%cl,0x1(%rip)# 10001104e _ret+0xff6e === -- Looks like both __GLOBAL__sub_I_00099_1_cov.cc (00010d88, which is the analog of _asan.module_ctor in Clang instrumentation) and __GLOBAL__sub_I_cov.cc (00010d5c, the original module ctor) are present in __mod_init_func, but are ordered incorrectly. I've fixed the order using bvi for OS X: === 00011040 __DATA.__mod_init_func: 11040: 88 0d 00 00 01 00 mov%cl,0x1(%rip)# 100011046 _ret+0xff66 11046: 00 00 add%al,(%rax) 11048: 5c pop%rsp 11049: 0d 00 00 01 00 or $0x1,%eax === and the resulting binary didn't segfault for me.
[Bug sanitizer/55599] switch from mach_override to mac interpose function support in libasan broke -static-libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55599 --- Comment #2 from Alexander Potapenko glider at google dot com 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, although we definitely do not want to. I'm guessing that the link problems have been caused by the removal of mach_override from the tree.
[Bug sanitizer/55599] switch from mach_override to mac interpose function support in libasan broke -static-libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55599 --- Comment #5 from Alexander Potapenko glider at google dot com 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), which strictly requires the interposing functions to be in a shared library that must be preloaded using DYLD_INSERT_LIBRARIES (ASan does that automatically in __asan_init) The dynamic library doesn't require the mach_override code (we don't link it in LLVM), but the static one does. Since you have removed the mach_override code, it's time to drop the static library support (note that in LLVM the static runtime library is still the default one, because it's now the one that simply works)
[Bug sanitizer/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 #49 from Alexander Potapenko glider at google dot com 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 interested in supporting 10.5, as it's completely unsupported by Apple.
[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 #39 from Alexander Potapenko glider at google dot com 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 Darwin right now should be perfectly ok. As there currently are issues blocking the dynamic ASan runtime (e.g. https://code.google.com/p/address-sanitizer/issues/detail?id=124), and we still depend on CoreFoundation I can't promise that we'll get rid of mach_override before the GCC 4.8 release.
[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 Alexander Potapenko glider at google dot com changed: What|Removed |Added CC||glider at google dot com --- Comment #28 from Alexander Potapenko glider at google dot com 2012-11-14 16:13:47 UTC --- === t.o: file format mach-o-x86-64 Disassembly of section .text: _foo: 0:55 push %rbp 1:48 89 e5 mov%rsp,%rbp 4:90 nop 5:90 nop 6:90 nop 7:90 nop 8:48 8d 05 11 4f 0b 00 lea0xb4f11(%rip),%rax# b4f20 _foo.eh+0xb4ee8 f:53 push %rbx 10:48 8d 5f e0 lea-0x20(%rdi),%rbx 14:48 89 77 90 mov%rsi,-0x70(%rdi) 18:5d pop%rbp 19:c3 retq === mach_override must be choking on the lea instruction. The easiest way to handle it is to add 48 8d 05 00 00 00 00 to the list of instructions and mark it as lea $imm(%rip),%rax. You can also dive into the opcodes a bit and mask the bits that select the destination register. I'll take a look at mach_override.c code to suggest the actual patch.
[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 #29 from Alexander Potapenko glider at google dot com 2012-11-14
16:40:53 UTC ---
Index: mach_override.c
===
--- mach_override.c(revision 167724)
+++ mach_override.c(working copy)
@@ -725,6 +725,8 @@
{ 0x2, {0xFF, 0x00}, {0x89, 0x00} }, //
mov r/m32,r32 or r/m16,r16
{ 0x3, {0xFF, 0xFF, 0xFF}, {0x49, 0x89, 0xF8} }, //
mov %rdi,%r8
{ 0x4, {0xFF, 0xFF, 0xFF, 0xFF}, {0x40, 0x0F, 0xBE, 0xCE} }, //
movsbl %sil,%ecx
+{ 0x7, {0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00},
+ {0x48, 0x8D, 0x05, 0x00, 0x00, 0x00, 0x00} }, // lea
$imm(%rip),%rax
{ 0x3, {0xFF, 0xFF, 0xFF}, {0x0F, 0xBE, 0xCE} }, // movsbl, %dh, %ecx
{ 0x3, {0xFF, 0xFF, 0x00}, {0xFF, 0x77, 0x00} }, // pushq $imm(%rdi)
{ 0x2, {0xFF, 0xFF}, {0xDB, 0xE3} }, // fninit
===
Please also make sure the interceptors work in 32-bit programs
