* libsanitizer in GCC 10 is dropping symbols without bumping the soversions
@ 2019-11-29 11:28 Matthias Klose
2019-11-29 11:33 ` Martin Liška
2019-11-29 11:48 ` Jakub Jelinek
0 siblings, 2 replies; 4+ messages in thread
From: Matthias Klose @ 2019-11-29 11:28 UTC (permalink / raw)
To: gcc Development; +Cc: Martin Liška
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: libsanitizer in GCC 10 is dropping symbols without bumping the soversions
2019-11-29 11:28 libsanitizer in GCC 10 is dropping symbols without bumping the soversions Matthias Klose
@ 2019-11-29 11:33 ` Martin Liška
2019-11-29 11:48 ` Jakub Jelinek
1 sibling, 0 replies; 4+ messages in thread
From: Martin Liška @ 2019-11-29 11:33 UTC (permalink / raw)
To: Matthias Klose, gcc Development
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: libsanitizer in GCC 10 is dropping symbols without bumping the soversions
2019-11-29 11:28 libsanitizer in GCC 10 is dropping symbols without bumping the soversions Matthias Klose
2019-11-29 11:33 ` Martin Liška
@ 2019-11-29 11:48 ` Jakub Jelinek
2019-11-29 12:07 ` Martin Liška
1 sibling, 1 reply; 4+ messages in thread
From: Jakub Jelinek @ 2019-11-29 11:48 UTC (permalink / raw)
To: Matthias Klose; +Cc: gcc Development, Martin Liška
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: libsanitizer in GCC 10 is dropping symbols without bumping the soversions
2019-11-29 11:48 ` Jakub Jelinek
@ 2019-11-29 12:07 ` Martin Liška
0 siblings, 0 replies; 4+ messages in thread
From: Martin Liška @ 2019-11-29 12:07 UTC (permalink / raw)
To: Jakub Jelinek, Matthias Klose; +Cc: gcc Development
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-11-29 12:07 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-29 11:28 libsanitizer in GCC 10 is dropping symbols without bumping the soversions Matthias Klose
2019-11-29 11:33 ` Martin Liška
2019-11-29 11:48 ` Jakub Jelinek
2019-11-29 12:07 ` Martin Liška
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).