This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 3/3] libsanitizer: add LFS guards
- From: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Bernhard Reutner-Fischer <rep dot dot dot nop at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Dodji Seketeli <dodji at redhat dot com>, Kostya Serebryany <kcc at google dot com>, Dmitry Vyukov <dvyukov at google dot com>
- Date: Fri, 5 Apr 2013 10:42:21 +0400
- Subject: Re: [PATCH 3/3] libsanitizer: add LFS guards
- References: <1365105210-16552-1-git-send-email-rep dot dot dot nop at gmail dot com> <1365105210-16552-4-git-send-email-rep dot dot dot nop at gmail dot com> <20130405063740 dot GX4201 at tucnak dot redhat dot com>
On Fri, Apr 5, 2013 at 10:37 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Apr 04, 2013 at 09:53:30PM +0200, Bernhard Reutner-Fischer wrote:
>> uClibc can be built without Largefile support, add the corresponding
>> guards. uClibc does not have __libc_malloc()/__libc_free(), add guard.
>
> Ugh, this is very ugly. In addition to the stuff mentioned by Konstantin
> that this really should go into upstream first:
>
>> --- a/libsanitizer/interception/interception_type_test.cc
>> +++ b/libsanitizer/interception/interception_type_test.cc
>> @@ -22,7 +22,7 @@ COMPILER_CHECK(sizeof(SSIZE_T) == sizeof(ssize_t));
>> COMPILER_CHECK(sizeof(PTRDIFF_T) == sizeof(ptrdiff_t));
>> COMPILER_CHECK(sizeof(INTMAX_T) == sizeof(intmax_t));
>>
>> -#ifndef __APPLE__
>> +#if !defined __APPLE__ && (defined __USE_LARGEFILE64 && defined __off64_t_defined)
>
> Using the internal implementation detail of __USE_LARGEFILE64 is very ugly,
> but why __off64_t_defined? That macro is there just to avoid typedefing it
> multiple times, if you include more than one of the sys/types.h, stdio.h and
> unistd.h headers. If you include any of those headers, it will be defined
> when __USE_LARGEFILE64 is defined. Or is uClibc not guaranteeing that?
>
>> --- a/libsanitizer/sanitizer_common/sanitizer_allocator.cc
>> +++ b/libsanitizer/sanitizer_common/sanitizer_allocator.cc
>> @@ -9,11 +9,13 @@
>> // run-time libraries.
>> // This allocator that is used inside run-times.
>> //===----------------------------------------------------------------------===//
>> +
>> +#include <features.h>
I overlooked this.
The sanitizer files (other than *_linux.cc and such) may not include
*any* system header files.
We've been there, it cost us lots of pain and lots of work to get rid of.
--kcc
>
> I'm afraid features.h won't exist on many targets, it isn't a standard
> header. I'd say you want to include some standard header instead (stdio.h?)
> or guard this.
>
> Jakub