Date: Sat, 8 Jan 2022 20:49:17 -0500 From: Rich Felker <dalias@...c.org> To: Rui Ueyama <rui314@...il.com>, musl@...ts.openwall.com Subject: Re: [PATCH] Explicitly pass the -fno-common flag On Sun, Jan 09, 2022 at 12:25:36AM +0100, Szabolcs Nagy wrote: > * Rui Ueyama <rui314@...il.com> [2022-01-08 16:45:51 +0900]: > > Common symbol is a special type of symbol that allows a linker to merge > > multiple common symbols into one and turn it into a defined symbol. > > This feature was used in C to allow tentative definitions. That is, > > you can write `int foo;` instead of `extern int foo;` in a header file. > > > > Common symbols are discouraged these days because they can easily > > hide unintentional duplicate symbol errors. For that reason, GCC > > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678) > > and Clang (https://github.com/llvm/llvm-project/commit/0a9fc9233e172601e26381810d093e02ef410f65) > > now default to `-fno-common`. > > > > That means, musl libc's global variables are compiled to common symbols > > or regular defined symbols depending on the compiler. That's not an issue > > per se, but it's unnecessary churn. > > > > This patch always passes the `-fno-common` flag to the compiler. > > building x86_64 musl with -fcommon i see these symbols in COM section: > > obj/src/malloc/replaced.lo: > __aligned_alloc_replaced > __malloc_replaced > obj/src/malloc/mallocng/malloc.lo: > __malloc_lock > obj/src/misc/getopt.lo: > __optpos > optarg > optopt > obj/src/env/__stack_chk_fail.lo: > __stack_chk_guard > obj/src/env/__init_tls.lo: > __thread_list_lock > obj/src/aio/aio.lo: > __aio_fut > obj/src/locale/locale_map.lo: > __locale_lock > obj/src/internal/libc.lo: > __hwcap > __libc > obj/src/internal/defsysinfo.lo: > __sysinfo > obj/src/signal/sigaction.lo: > __eintr_valid_flag > obj/src/exit/abort_lock.lo: > __abort_lock > obj/src/network/h_errno.lo: > h_errno > obj/src/time/getdate.lo: > getdate_err > > i'm not sure how this can cause trouble (maybe static linking?), but > if we care then another solution is to change > > int x; > > to > > int x = 0; > > instead of forcing -fno-common. I don't really see a need for us to care whether these are commons or bss. Having them be bss would give slightly better ability to error on build-time UB in static linked programs, but doesn't do anything at all for dynamic linking, and for static linking the problem is only diagnosable when the data object is in a file that's pulled in for an undefined symbol other than that of the data object (e.g. a function or other data object in the same TU). The one time bss is significantly preferable to common is for zero-initialized const objects (rare but they might appear in some places) since commons don't actually get made const. I don't think we have any of those that are commons now though. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.