libsanitizer in GCC 10 is dropping symbols without bumping the soversions

libsanitizer in GCC 10 is dropping symbols without bumping the soversions

[Matthias Klose]

libsanitizer on trunk only bumps the soversion for asan, but the other libraries
drop some symbols without bumping the soname, Are these changes intended, and
should the soversions be bumped?

Matthias


diff --git a/debian/liblsan0.symbols b/debian/liblsan0.symbols
index f318d9a..5aa23a6 100644
--- a/debian/liblsan0.symbols
+++ b/debian/liblsan0.symbols
@@ -1,5 +1,4 @@
 liblsan.so.0 liblsan0 #MINVER#
- OnPrint@Base 8
  _ZdaPv@Base 4.9
  _ZdaPvRKSt9nothrow_t@Base 4.9
  _ZdaPvSt11align_val_t@Base 8
@@ -138,7 +140,6 @@ liblsan.so.0 liblsan0 #MINVER#
  calloc@Base 4.9
  cfree@Base 4.9
  free@Base 4.9
- (arch=base-any-any-amd64 any-mips any-mipsel)internal_sigreturn@Base 7
  mallinfo@Base 4.9
  malloc@Base 4.9
  malloc_usable_size@Base 4.9

diff --git a/debian/libtsan0.symbols b/debian/libtsan0.symbols
index 827bb58..6a282a4 100644
--- a/debian/libtsan0.symbols
+++ b/debian/libtsan0.symbols
@@ -35,7 +35,6 @@ libtsan.so.0 libtsan0 #MINVER#
  AnnotateThreadName@Base 4.9
  AnnotateTraceMemory@Base 4.9
  AnnotateUnpublishMemoryRange@Base 4.9
- OnPrint@Base 8
  RunningOnValgrind@Base 4.9
  ThreadSanitizerQuery@Base 4.9
  ValgrindSlowdown@Base 4.9
@@ -1637,7 +1712,7 @@ libtsan.so.0 libtsan0 #MINVER#
  initgroups@Base 4.9
  inotify_init1@Base 4.9
  inotify_init@Base 4.9
- (arch=base-any-any-amd64 any-mips any-mipsel)internal_sigreturn@Base 7
+#MISSING: 10# (arch=base-any-any-amd64 any-mips
any-mipsel)internal_sigreturn@Base 7
  ioctl@Base 4.9
  kill@Base 4.9
  lgamma@Base 4.9

diff --git a/debian/libubsan1.symbols b/debian/libubsan1.symbols
index b829376..731d0db 100644
--- a/debian/libubsan1.symbols
+++ b/debian/libubsan1.symbols
@@ -1,5 +1,4 @@
 libubsan.so.1 libubsan1 #MINVER#
- OnPrint@Base 8
  __asan_backtrace_alloc@Base 4.9
  __asan_backtrace_close@Base 4.9
@@ -91,8 +93,8 @@ libubsan.so.1 libubsan1 #MINVER#
  __ubsan_handle_dynamic_type_cache_miss_abort@Base 4.9
  __ubsan_handle_float_cast_overflow@Base 4.9
  __ubsan_handle_float_cast_overflow_abort@Base 4.9
- __ubsan_handle_function_type_mismatch@Base 4.9
- __ubsan_handle_function_type_mismatch_abort@Base 4.9
+ __ubsan_handle_function_type_mismatch_v1@Base 4.9
+ __ubsan_handle_function_type_mismatch_v1_abort@Base 4.9
  __ubsan_handle_implicit_conversion@Base 9
  __ubsan_handle_implicit_conversion_abort@Base 9
  __ubsan_handle_invalid_builtin@Base 8
@@ -126,4 +128,3 @@ libubsan.so.1 libubsan1 #MINVER#
  __ubsan_handle_vla_bound_not_positive_abort@Base 4.9
  __ubsan_on_report@Base 9
  __ubsan_vptr_type_cache@Base 4.9
- (arch=base-any-any-amd64 any-mips any-mipsel)internal_sigreturn@Base 7

Re: libsanitizer in GCC 10 is dropping symbols without bumping the soversions

[Martin Liška]

On 11/29/19 12:28 PM, Matthias Klose wrote:
> libsanitizer on trunk only bumps the soversion for asan, but the other libraries
> drop some symbols without bumping the soname, Are these changes intended, and
> should the soversions be bumped?

Hello.

Yes, it's intended. We should bump the library only if there's a ABI change for functions
that are utilized from an instrumented binary (with GCC -fsanitize=xyz).
Are these such functions?

Thanks,
Martin

Re: libsanitizer in GCC 10 is dropping symbols without bumping the soversions

[Jakub Jelinek]

On Fri, Nov 29, 2019 at 12:28:51PM +0100, Matthias Klose wrote:
> libsanitizer on trunk only bumps the soversion for asan, but the other libraries
> drop some symbols without bumping the soname, Are these changes intended, and
> should the soversions be bumped?

libsanitizer libs have upstream that doesn't really care about something
like ABI.
From this I'd be only worried about libubsan.
liblsan isn't a library that anybody should call anything from directly
except the malloc*/operator new/delete stuff it is overriding, it is kind of
libefence or other malloc replacement libraries.
libtsan isn't like that, but still the actual ABI is only in __tsan_*
APIs, OnPrint seems just like a screwup and the libc API interceptors
shouldn't cause harm, they are defined in libc and programs can use it
directly from there.
__ubsan_handle_function_type_mismatch* is something we don't use (Martin,
should we add such sanitizer?  We have gimple_call_fntype vs. actual decl
types, but it would need some inspection on what the sanitizer really does),
but still e.g. clang compiled binaries could and could be (at least in
theory) be linked against gcc libubsan.

> diff --git a/debian/liblsan0.symbols b/debian/liblsan0.symbols
> index f318d9a..5aa23a6 100644
> --- a/debian/liblsan0.symbols
> +++ b/debian/liblsan0.symbols
> @@ -1,5 +1,4 @@
>  liblsan.so.0 liblsan0 #MINVER#
> - OnPrint@Base 8
>   _ZdaPv@Base 4.9
>   _ZdaPvRKSt9nothrow_t@Base 4.9
>   _ZdaPvSt11align_val_t@Base 8
> @@ -138,7 +140,6 @@ liblsan.so.0 liblsan0 #MINVER#
>   calloc@Base 4.9
>   cfree@Base 4.9
>   free@Base 4.9
> - (arch=base-any-any-amd64 any-mips any-mipsel)internal_sigreturn@Base 7
>   mallinfo@Base 4.9
>   malloc@Base 4.9
>   malloc_usable_size@Base 4.9
> 
> diff --git a/debian/libtsan0.symbols b/debian/libtsan0.symbols
> index 827bb58..6a282a4 100644
> --- a/debian/libtsan0.symbols
> +++ b/debian/libtsan0.symbols
> @@ -35,7 +35,6 @@ libtsan.so.0 libtsan0 #MINVER#
>   AnnotateThreadName@Base 4.9
>   AnnotateTraceMemory@Base 4.9
>   AnnotateUnpublishMemoryRange@Base 4.9
> - OnPrint@Base 8
>   RunningOnValgrind@Base 4.9
>   ThreadSanitizerQuery@Base 4.9
>   ValgrindSlowdown@Base 4.9
> @@ -1637,7 +1712,7 @@ libtsan.so.0 libtsan0 #MINVER#
>   initgroups@Base 4.9
>   inotify_init1@Base 4.9
>   inotify_init@Base 4.9
> - (arch=base-any-any-amd64 any-mips any-mipsel)internal_sigreturn@Base 7
> +#MISSING: 10# (arch=base-any-any-amd64 any-mips
> any-mipsel)internal_sigreturn@Base 7
>   ioctl@Base 4.9
>   kill@Base 4.9
>   lgamma@Base 4.9
> 
> diff --git a/debian/libubsan1.symbols b/debian/libubsan1.symbols
> index b829376..731d0db 100644
> --- a/debian/libubsan1.symbols
> +++ b/debian/libubsan1.symbols
> @@ -1,5 +1,4 @@
>  libubsan.so.1 libubsan1 #MINVER#
> - OnPrint@Base 8
>   __asan_backtrace_alloc@Base 4.9
>   __asan_backtrace_close@Base 4.9
> @@ -91,8 +93,8 @@ libubsan.so.1 libubsan1 #MINVER#
>   __ubsan_handle_dynamic_type_cache_miss_abort@Base 4.9
>   __ubsan_handle_float_cast_overflow@Base 4.9
>   __ubsan_handle_float_cast_overflow_abort@Base 4.9
> - __ubsan_handle_function_type_mismatch@Base 4.9
> - __ubsan_handle_function_type_mismatch_abort@Base 4.9
> + __ubsan_handle_function_type_mismatch_v1@Base 4.9
> + __ubsan_handle_function_type_mismatch_v1_abort@Base 4.9
>   __ubsan_handle_implicit_conversion@Base 9
>   __ubsan_handle_implicit_conversion_abort@Base 9
>   __ubsan_handle_invalid_builtin@Base 8
> @@ -126,4 +128,3 @@ libubsan.so.1 libubsan1 #MINVER#
>   __ubsan_handle_vla_bound_not_positive_abort@Base 4.9
>   __ubsan_on_report@Base 9
>   __ubsan_vptr_type_cache@Base 4.9
> - (arch=base-any-any-amd64 any-mips any-mipsel)internal_sigreturn@Base 7

	Jakub

Re: libsanitizer in GCC 10 is dropping symbols without bumping the soversions

[Martin Liška]

On 11/29/19 12:47 PM, Jakub Jelinek wrote:
> __ubsan_handle_function_type_mismatch* is something we don't use (Martin,
> should we add such sanitizer?  We have gimple_call_fntype vs. actual decl
> types, but it would need some inspection on what the sanitizer really does),
> but still e.g. clang compiled binaries could and could be (at least in
> theory) be linked against gcc libubsan.

Yes, we can add it for GCC 11. The sanitizer is about:

$ cat indirect.C
int foo(int a)
{
   return a;
}

void bar(int (*fn) (void))
{
   fn();
}

int main()
{
   bar(reinterpret_cast<int (*)(void)> (foo));
}

$ clang++ indirect.C -fsanitize=function && ./a.out
indirect.C:8:3: runtime error: call to function foo(int) through pointer to incorrect function type 'int (*)()'
(/tmp/a.out+0x424c60): note: foo(int) defined here
     #0 0x424cfb in bar(int (*)()) (/tmp/a.out+0x424cfb)
     #1 0x424d2d in main (/tmp/a.out+0x424d2d)
     #2 0x7f2e8bbfee0a in __libc_start_main /usr/src/debug/glibc-2.30-1.2.x86_64/csu/../csu/libc-start.c:308:16
     #3 0x403309 in _start /home/abuild/rpmbuild/BUILD/glibc-2.30/csu/../sysdeps/x86_64/start.S:120

static bool handleFunctionTypeMismatch(FunctionTypeMismatchData *Data,
                                        ValueHandle Function,
                                        ValueHandle calleeRTTI,
                                        ValueHandle fnRTTI, ReportOptions Opts) {
   if (checkTypeInfoEquality(reinterpret_cast<void *>(calleeRTTI),
                             reinterpret_cast<void *>(fnRTTI)))
     return false;

So it should be quite trivial as we're already using checkTypeInfoEquality in
bool __ubsan::checkDynamicType(void *Object, void *Type, HashValue Hash) {

Martin