=
> --- libsanitizer/configure.tgt (revision 193500)
> +++ libsanitizer/configure.tgt (working copy)
> @@ -22,6 +22,8 @@
> case "${target}" in
>x86_64-*-linux* | i?86-*-linux*)
> ;;
> + x86_64-*-darwin* | i?86-*-darwin*)
> + ;;
>*)
> UNSUPPORTED=1
> ;;
--
Alexander Potapenko
Software Engineer
Google Moscow
That would
> certainly be easier than figuring things out on your own one by one. I
> guess several target and os port maintainers would want to do so in GCC.
>
> Thanks.
> Rainer
>
> --
> -----
> Rainer Orth, Center for Biotechnology, Bielefeld University
--
Alexander Potapenko
Software Engineer
Google Moscow
structure (like libffi) to only compile
> target-specific code on the relevant platforms, instead of wrapping
> every source file in #ifdef __linux__ or similar and extending the
> conditionals once a new platform is added.
Yes, this might be a problem. I also wonder how much Solaris is l
I've responded to the bug.
Sorry for offtopics unrelated to your original patch.
On Wed, Nov 14, 2012 at 8:11 PM, Jack Howarth wrote:
> On Wed, Nov 14, 2012 at 07:56:18PM +0400, Alexander Potapenko wrote:
>> Hi Rainer,
>>
>> The quick answer is no, although the ex
>> Also, Alexander Potapenko is the best person to ask about asan-darwin.
>
> here.
>
>> Maybe we can add him to the list of sanitizer maintainers?
>
> Seconded. At least for libsanitier/Darwin.
>
> Cheers.
I can take this, but I'll be busy within th
>> While trying to add support for ARM (AArch32 GNU / Linux) implementation for
>> GCC after-hours but still keep seeing failures on my chromebook running an
>> ubuntu fs on a ChrOS kernel, because the shadow memory apparently overlaps
>> with normal memory. Has anyone else hit this while porting ?
p --target_board=unix'{-m32,-m64}'"
>
> without regressions.
> Jack
> ps This version adds the requested importation of the LICENSE.txt file from
> llvm.org's
> compiler-rt in interception/mach_override. It also sets TSAN_SUPPORTED=no in
> co
pped on
> x86_64-apple-darwin10,
> x86_64-apple-darwin11 and x86_64-apple-darwin12. Passes...
>
> make -k check RUNTESTFLAGS="asan.exp --target_board=unix'{-m32,-m64}'"
>
> and fixes the previously failing cond1.C test case from PR55521 on all three
> tar
On Sun, Dec 2, 2012 at 10:15 PM, Jack Howarth wrote:
> On Sun, Dec 02, 2012 at 10:21:02AM +0400, Alexander Potapenko wrote:
>> Hi Jack,
>>
>> IIUC the wrappers for dispatch_async_f, dispatch_sync_f and other
>> dispatch_smth_f do not need blocks support in the compiler,
view and approve it, even
> though it says darwin and is heavily darwin specific… It's ok by me.
--
Alexander Potapenko
Software Engineer
Google Moscow
I've added MISSING_BLOCKS_SUPPORT to LLVM compiler-rt in r169206.
The rest of your change looks good to me as well.
On Mon, Dec 3, 2012 at 6:33 PM, Alexander Potapenko wrote:
> Jack,
>
> Note that MAC_INTERPOSE_FUNCTIONS is always defined in interception.h
> to either 0 or 1.
&g
_override out of llvm's compiler-rt
>> > trunk so
>> > lib/interception/mach_override/, lib/interception/interception_mac.cc and
>> > lib/interception/interception_mac.h could be removed.
>> >>
>> >> On Tue, Dec 4, 2012 at 6:44 AM, Alexander Potapenko
>> replacement mac function
>> imposition code results in a non-functional static libasan (PR55599).
>
> Ok unless the asan people have a better idea...
--
Alexander Potapenko
Software Engineer
Google Moscow
ell).
>> The patch has been bootstrap and regression tested on
>> x86_64-apple-darwin12.
>> Okay for gcc trunk?
>
> But that does not work across translation units, no? ISTR collect2 has
> support
> to handle constructor priorities all by itself (at link time,
> considering all inputs).
> I wonder why darwin cannot use that mechanism to support init priorities?
>
> Richard.
>
>> Jack
>> ps Unfortunately the flag_sort variable is unavailable inside of
>> machopic_asm_out_constructor
>> so we have to unconditionally test for priority == 99.
>>
--
Alexander Potapenko
Software Engineer
Google Moscow
> But that does not work across translation units, no? ISTR collect2 has
> support
> to handle constructor priorities all by itself (at link time,
> considering all inputs).
> I wonder why darwin cannot use that mechanism to support init priorities?
>
> Richard.
(resending, sorry for top-posting
On Mon, Feb 4, 2013 at 1:38 PM, Jakub Jelinek wrote:
> On Mon, Feb 04, 2013 at 10:22:48AM +0100, Richard Biener wrote:
>> > Okay for gcc trunk?
>>
>> But that does not work across translation units, no? ISTR collect2 has
>> support
>> to handle constructor priorities all by itself (at link time,
x27;d be
> happy to review that. A good patch for that would add it to clang for darwin,
> and have gcc use that same mechanism so that we can interoperate nicely.
> Absent interoperability… I think it would be annoying, as then you have to
> have a binary incompatibility to fix the one that is wrong.
--
Alexander Potapenko
Software Engineer
Google Moscow
> Alexander,
>I never claimed full init priority support however FSF gcc on darwin
> currently
> has no init priority support at all. Since Mike wanted to sort the
> destructors as
> well as the constructors and this achieves usable intra-module init priority
> support
> for FSF gcc darwin,
sion
> tested on
> x86_64-apple-darwin12. Okay for gcc trunk?
> Jack
--
Alexander Potapenko
Software Engineer
Google Moscow
19 matches
Mail list logo
