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.
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. 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
