On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Tue, Nov 13, 2012 at 03:31:21AM -0800, H.J. Lu wrote:
>> On Tue, Nov 13, 2012 at 3:20 AM, Dodji Seketeli <do...@redhat.com> wrote:
>> > Diego Novillo <dnovi...@google.com> a écrit:
>> >
>> >> Patches to libsanitizer should be sent upstream. We should only
>> >> contain a copy of the master in the LLVM repository. There should be
>> >> instructions in libsanitizer/README.gcc (Jakub, Dodji, are they there?
>> >> I can't check ATM).
>> >
>> > No there are not, for the moment. README.gcc just says where the
>> > sources the 'upstream' project is.
>> >
>>
>> What is the plan to add GCC specific support:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55291
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55292
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55304
>>
>> and
>>
>> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00967.html
>
> CCing Wei, I don't know the details about the import. To me it looks like
> that most or all of the libsanitizer/ level files (and
> libsanitizer/*/Makefile.{am,in}) don't originate from
> llvm/projects/compiler-rt/lib , so they should be owned by GCC and thus
> should be changed to support multilibs, use the same libtool/autoconf/etc.
> versions as rest of gcc etc.
Correct. Whatever happens to Makefile, configure and other non-.{cc,h}
files is a purely GCC thing.
>
> For changes to the files actually imported from LLVM I guess it depends on
> if google is going to accept such changes in the LLVM upstream.
Yes, we are willing to support any changes that make libasan support
more targets.
We would prefer all patches to go through LLVM first, and then ported
to GCC by copying files verbatim
This is the only way we can cope with the two versions.
(Wei, we will need the exact details for doing this in the README file)
--kcc
> For
> unsupported targets we want to add target-libsanitizer into noconfigdirs
> in toplevel configure.
>
> Note that just making libsanitizer to build on some architecture is not
> enough for full ASAN support, one needs to also add the target hook with
> mem>>3 to shadow offset, and I guess review all other spots where
> libsanitizer uses __i386__ or __x86_64__ macros.
>
> I'd also say that using sanitizer_atomic_clang.h for GCC is not a good
> idea, now that GCC 4.7+ has __atomic_* support that should be usable
> for most of the __sanitizer::atomic* stuff.
>
> Jakub
