On 12/6/20 9:00 AM, Bruno Haible wrote:
The solution to this problem is to use the option '-static-libubsan'.
Unfortunately -static-libusan doesn't solve the whole problem of dynamically
linking to extra libraries, and it introduces problems of its own. When I build
your foo.c program on Fedora 33 x86-64:
$ gcc -O2 foo.c
$ size a.out
text data bss dec hex filename
1231 548 12 1791 6ff a.out
$ ldd a.out
linux-vdso.so.1 (0x00007ffe583c8000)
libc.so.6 => /lib64/libc.so.6 (0x00007f60a557f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f60a576e000)
$ gcc -fsanitize=undefined -fsanitize-undefined-trap-on-error -O2 foo.c
$ size a.out
text data bss dec hex filename
1247 548 12 1807 70f a.out
$ ldd a.out
linux-vdso.so.1 (0x00007ffe0b100000)
libc.so.6 => /lib64/libc.so.6 (0x00007f79f2d98000)
/lib64/ld-linux-x86-64.so.2 (0x00007f79f2f87000)
$ gcc -fsanitize=undefined -static-libubsan -O2 foo.c
$ size a.out
text data bss dec hex filename
274576 15912 593416 883904 d7cc0 a.out
$ ldd a.out
linux-vdso.so.1 (0x00007ffe15d15000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f0bc6af6000)
librt.so.1 => /lib64/librt.so.1 (0x00007f0bc6aeb000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0bc6ac9000)
libm.so.6 => /lib64/libm.so.6 (0x00007f0bc6983000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f0bc6968000)
libc.so.6 => /lib64/libc.so.6 (0x00007f0bc679d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0bc6b21000)
$ gcc -fsanitize=undefined -O2 foo.c
$ size a.out
text data bss dec hex filename
1511 660 12 2183 887 a.out
$ ldd a.out
linux-vdso.so.1 (0x00007ffc208cd000)
libubsan.so.1 => /lib64/libubsan.so.1 (0x00007fac5540e000)
libc.so.6 => /lib64/libc.so.6 (0x00007fac55243000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fac5523c000)
librt.so.1 => /lib64/librt.so.1 (0x00007fac55231000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fac5520f000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fac55027000)
libm.so.6 => /lib64/libm.so.6 (0x00007fac54edf000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fac54ec4000)
/lib64/ld-linux-x86-64.so.2 (0x00007fac55d9d000)
I tried to condense all this into something short and installed the attached
into the Gnulib manual.
From d058c47204168676d6fe02b18d51916a1045149e Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
Date: Sun, 6 Dec 2020 10:03:37 -0800
Subject: [PATCH] doc: document -static-libubsan more
* doc/gnulib-readme.texi (High Quality): Document pros and cons of
-static-libubsan a bit more. Mostly cons.
---
ChangeLog | 6 ++++++
doc/gnulib-readme.texi | 16 ++++++++++++----
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 08cef4d15..14a2ea957 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2020-12-06 Paul Eggert <egg...@cs.ucla.edu>
+
+ doc: document -static-libubsan more
+ * doc/gnulib-readme.texi (High Quality): Document pros and cons of
+ -static-libubsan a bit more. Mostly cons.
+
2020-12-06 Bruno Haible <br...@clisp.org>
doc: Add more details regarding the undefined behaviour sanitizer.
diff --git a/doc/gnulib-readme.texi b/doc/gnulib-readme.texi
index cde6d7aab..833888320 100644
--- a/doc/gnulib-readme.texi
+++ b/doc/gnulib-readme.texi
@@ -559,8 +559,16 @@ the GNU C library.
@code{-fsanitize-undefined-trap-on-error} causes @code{ubsan} to
abort the program (through an ``illegal instruction'' signal). This
measure stops exploit attempts and also allows you to debug the issue.
-Without this option, @code{-fsanitize=undefined} causes messages to be
-printed, execution continues after an undefined behavior situation, and
-GCC links the program against @code{libstdc++} (which you can avoid
-through the option @code{-static-libubsan}).
@end itemize
+
+Without the @code{-fsanitize-undefined-trap-on-error} option,
+@code{-fsanitize=undefined} causes messages to be printed, and
+execution continues after an undefined behavior situation.
+The message printing causes GCC-like compilers to arrange for the
+program to dynamically link to libraries it might not otherwise need.
+With GCC, instead of @code{-fsanitize-undefined-trap-on-error} you can
+use the @code{-static-libubsan} option to arrange for two of the extra
+libraries (@code{libstdc++} and @code{libubsan}) to be linked
+statically rather than dynamically, though this typically bloats the
+executable and the remaining extra libraries are still linked
+dynamically.
--
2.27.0
