llvm dev - Jun 2012 - [LLVMdev] PATCH: AddressSanitizer: Fix errors about mis-matched exception specifiers for intercepted libc functions on Linux

Hello,

On modern Linux installs, glibc has a very annoying practice: it adds an
empty exception specifier to lots of libc functions as an optimization. It
only does this if the compiler is modern and GCC-like, and we are compiling
in C++ mode.

This, however, causes GCC to complain about signature mismatches between
the glibc functions declared in malloc.h and those defined as an alias in
the interceptors library:

..../asan_malloc_linux.cc:57:1: error: declaration of 'void free(void*)'
has a different exception specifier
/usr/include/malloc.h:66:13: error: from previous declaration 'void
free(void*) throw ()'


I've attached a complete hack of a patch to address this... but surely
there is a better way? I'm open to suggestions about this sticky issue.

Amusingly, this is only diagnosed by GCC, not by Clang. =] So I didn't even
notice it at first.
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120625/5e64b4dd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: exception-spec.patch
Type: application/octet-stream
Size: 593 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120625/5e64b4dd/attachment.obj>

On Mon, Jun 25, 2012 at 1:10 PM, Chandler Carruth <chandlerc at
google.com>wrote:
> Hello,
>
> On modern Linux installs, glibc has a very annoying practice: it adds an
> empty exception specifier to lots of libc functions as an optimization. It
> only does this if the compiler is modern and GCC-like, and we are compiling
> in C++ mode.
>
> This, however, causes GCC to complain about signature mismatches between
> the glibc functions declared in malloc.h and those defined as an alias in
> the interceptors library:
>
> ..../asan_malloc_linux.cc:57:1: error: declaration of 'void
free(void*)'
> has a different exception specifier
> /usr/include/malloc.h:66:13: error: from previous declaration 'void
> free(void*) throw ()'
>
>
> I've attached a complete hack of a patch to address this... but surely
> there is a better way? I'm open to suggestions about this sticky issue.
>
ouch!
How do I reproduce the failure?
For me, the code build fine with gcc (4.4.3 and 4.7.0).

--kcc

>
> Amusingly, this is only diagnosed by GCC, not by Clang. =] So I didn't
> even notice it at first.
> -Chandler
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120625/3649ea12/attachment.html>

On Mon, Jun 25, 2012 at 1:10 PM, Chandler Carruth <chandlerc at
google.com> wrote:
> Hello,
>
> On modern Linux installs, glibc has a very annoying practice: it adds an
> empty exception specifier to lots of libc functions as an optimization. It
> only does this if the compiler is modern and GCC-like, and we are compiling
> in C++ mode.
>
> This, however, causes GCC to complain about signature mismatches between
the
> glibc functions declared in malloc.h and those defined as an alias in the
> interceptors library:
>
> ..../asan_malloc_linux.cc:57:1: error: declaration of 'void
free(void*)' has
> a different exception specifier
> /usr/include/malloc.h:66:13: error: from previous declaration 'void
> free(void*) throw ()'
Looking at /usr/include/malloc.h I don't see any instances of throw()
(Goobuntu Lucid)
Shouldn't we have the same set of standard headers?

.. And the right fix would be to completely get rid of "#include
<malloc.h>" in this file.
I'll do that change.

--kcc

On Mon, Jun 25, 2012 at 1:42 PM, Alexander Potapenko <glider at
google.com>wrote:
> On Mon, Jun 25, 2012 at 1:10 PM, Chandler Carruth <chandlerc at
google.com>
> wrote:
> > Hello,
> >
> > On modern Linux installs, glibc has a very annoying practice: it adds
an
> > empty exception specifier to lots of libc functions as an
optimization.
> It
> > only does this if the compiler is modern and GCC-like, and we are
> compiling
> > in C++ mode.
> >
> > This, however, causes GCC to complain about signature mismatches
between
> the
> > glibc functions declared in malloc.h and those defined as an alias in
the
> > interceptors library:
> >
> > ..../asan_malloc_linux.cc:57:1: error: declaration of 'void
free(void*)'
> has
> > a different exception specifier
> > /usr/include/malloc.h:66:13: error: from previous declaration
'void
> > free(void*) throw ()'
> Looking at /usr/include/malloc.h I don't see any instances of throw()
> (Goobuntu Lucid)
> Shouldn't we have the same set of standard headers?
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120625/99a69e23/attachment.html>

On Mon, Jun 25, 2012 at 2:25 AM, Kostya Serebryany <kcc at google.com>
wrote:
>
>
> On Mon, Jun 25, 2012 at 1:10 PM, Chandler Carruth <chandlerc at
google.com>wrote:
>
>> Hello,
>>
>> On modern Linux installs, glibc has a very annoying practice: it adds
an
>> empty exception specifier to lots of libc functions as an optimization.
It
>> only does this if the compiler is modern and GCC-like, and we are
compiling
>> in C++ mode.
>>
>> This, however, causes GCC to complain about signature mismatches
between
>> the glibc functions declared in malloc.h and those defined as an alias
in
>> the interceptors library:
>>
>> ..../asan_malloc_linux.cc:57:1: error: declaration of 'void
free(void*)'
>> has a different exception specifier
>> /usr/include/malloc.h:66:13: error: from previous declaration 'void
>> free(void*) throw ()'
>>
>>
>> I've attached a complete hack of a patch to address this... but
surely
>> there is a better way? I'm open to suggestions about this sticky
issue.
>>
>
> ouch!
> How do I reproduce the failure?
> For me, the code build fine with gcc (4.4.3 and 4.7.0).
>
I'm not sure... maybe add '-pedantic' to your compile flags? It
triggers
easily with the in-progress CMake build, and one of the differences is
inheritting the fairly strict set of compile flags from LLVM proper.

>
>
> --kcc
>
>
>>
>> Amusingly, this is only diagnosed by GCC, not by Clang. =] So I
didn't
>> even notice it at first.
>> -Chandler
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120625/60f9e275/attachment.html>

On Mon, Jun 25, 2012 at 2:42 AM, Alexander Potapenko <glider at
google.com>wrote:
> On Mon, Jun 25, 2012 at 1:10 PM, Chandler Carruth <chandlerc at
google.com>
> wrote:
> > Hello,
> >
> > On modern Linux installs, glibc has a very annoying practice: it adds
an
> > empty exception specifier to lots of libc functions as an
optimization.
> It
> > only does this if the compiler is modern and GCC-like, and we are
> compiling
> > in C++ mode.
> >
> > This, however, causes GCC to complain about signature mismatches
between
> the
> > glibc functions declared in malloc.h and those defined as an alias in
the
> > interceptors library:
> >
> > ..../asan_malloc_linux.cc:57:1: error: declaration of 'void
free(void*)'
> has
> > a different exception specifier
> > /usr/include/malloc.h:66:13: error: from previous declaration
'void
> > free(void*) throw ()'
> Looking at /usr/include/malloc.h I don't see any instances of throw()
> (Goobuntu Lucid)
> Shouldn't we have the same set of standard headers?
>
Ahem, not everyone works where we do? ;]

I'm testing this on a very generic Linux box. I think you'll find that
the
preprocessed source of malloc.h does include throw(). It's burried inside
of MALLOC_P, other macros, __THROW, etc. But eventually it gets there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120625/7df7f1d1/attachment.html>