From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 01EB63858C66 for ; Tue, 9 Jan 2024 07:49:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 01EB63858C66 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 01EB63858C66 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=63.228.1.57 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704786588; cv=none; b=fjuxQu0BYu9aefh5qjGMquNd1YyWe9dp42aPS8TGbK09kteGe68ypXGE7rvr03FRMZs+Wys43ER7J9p4cWgNHlQ81usfPGTyst50xjXMDyxQ9q+Id1AinyzEhXNyfurmEOxBNdJz0roDqo/xUIgfVXmTKs2wFR1LsBzlNXL8UmE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704786588; c=relaxed/simple; bh=yHO3cAos9A3PYHjt0XE015EUgRbwrEKzCqPdtSC+x3E=; h=Date:From:To:Subject:Message-ID:Mime-Version; b=F8P+A9egOD5oTI2XBxfJGo6RHkhZfVz5viI/8nHp3ZzZ40UDZvUjs9gFUbCxJ32yGeGiVvHZD/U20n3YGIU/hgWEBYRGtKta3lxDwXmp3uUGVeuYMVTD+dbN3nDA43ER+iE5qIdOfRa1Mc00pPB1C44zpIi4Ty8XLICn3RYjaQE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 4097miYa016493; Tue, 9 Jan 2024 01:48:44 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 4097mh2R016492; Tue, 9 Jan 2024 01:48:43 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 9 Jan 2024 01:48:43 -0600 From: Segher Boessenkool To: Xi Ruoyao Cc: richard clark , Mark Rutland , gcc-help@gcc.gnu.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: undefined reference to `__aarch64_cas4_sync' error on arm64 native build Message-ID: <20240109074843.GI19790@gate.crashing.org> References: <9aef98eed96ed32962ce90499291cb30ad5e3e14.camel@xry111.site> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9aef98eed96ed32962ce90499291cb30ad5e3e14.camel@xry111.site> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Jan 09, 2024 at 11:05:57AM +0800, Xi Ruoyao via Gcc-help wrote: > But the Linux kernel cannot use neither libc.so nor libgcc.a. I have built Linux using libgcc for many years. It is as easy as +LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name) +libs-y += $(LIBGCC) > (I know > some non-Linux kernel developers are overusing libgcc.a for kernels, but > IMO this is just wrong and Linux developers also do not do this. If the > Linux kernel needs a symbol from libgcc the developers just provide > their own implementation.) Yes, and often they have fallen behind. When they eventually catch up they usually just copy the GCC code anyway. Originally the only reasonable argument for not linking against libgcc was so kernel code would not accidentally use double-length divisions. There are other simple ways to have all uses of __divti3 and similar create link errors, so that is not really a good argument. libgcc is an essential part of the compiler. For most targets, for most code, GCC will not generate function calls, there usually are faster (or smaller) things it can do, but it still is necessary to have libgcc for more uncommon things. Using a partial copy of it, behind the times, and maybe even incompatible, is not a great idea. Segher