This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: PR other/55292: libsanitizer doesn't support x32


On Tue, Nov 13, 2012 at 1:46 PM, Andrew Pinski <pinskia@gmail.com> wrote:
> On Tue, Nov 13, 2012 at 1:40 PM, Konstantin Serebryany
> <konstantin.s.serebryany@gmail.com> wrote:
>> On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek <jakub@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 <dodji@redhat.com> wrote:
>>>> > Diego Novillo <dnovillo@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)
>
> I rather have it the other way around; like how libffi is handled.
> Since GCC has many more targets and a different schedule than LLVM.

That may work too, but the very moment that the two versions get out of sync
we lose the ability to port the new version from LLVM to GCC with
reasonable effort.
So, whoever applies a change to the gcc version will need to make sure
the same change applies upstream.

>
> Thanks,
> Andrew
>
>>
>> --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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]