From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22741 invoked from network); 9 Jan 2022 01:49:33 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 9 Jan 2022 01:49:33 -0000 Received: (qmail 32239 invoked by uid 550); 9 Jan 2022 01:49:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32201 invoked from network); 9 Jan 2022 01:49:30 -0000 Date: Sat, 8 Jan 2022 20:49:17 -0500 From: Rich Felker To: Rui Ueyama , musl@lists.openwall.com Message-ID: <20220109014916.GM7074@brightrain.aerifal.cx> References: <20220108232536.GC1320090@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220108232536.GC1320090@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] Explicitly pass the -fno-common flag On Sun, Jan 09, 2022 at 12:25:36AM +0100, Szabolcs Nagy wrote: > * Rui Ueyama [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