From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C3EE7D3C912 for ; Wed, 10 Dec 2025 14:40:34 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1182987.1505776 (Exim 4.92) (envelope-from ) id 1vTLMa-0003lI-Be; Wed, 10 Dec 2025 14:40:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1182987.1505776; Wed, 10 Dec 2025 14:40:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vTLMa-0003lB-85; Wed, 10 Dec 2025 14:40:20 +0000 Received: by outflank-mailman (input) for mailman id 1182987; Wed, 10 Dec 2025 14:40:18 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vTLMY-0003l5-SM for xen-devel@lists.xenproject.org; Wed, 10 Dec 2025 14:40:18 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vTLMX-003GZa-0w; Wed, 10 Dec 2025 14:40:17 +0000 Received: from [2a01:cb15:80df:da00:d2b0:117d:791c:30c0] (helo=l14) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vTLMX-008VeW-0g; Wed, 10 Dec 2025 14:40:17 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=PnBfQblPeOHXUj0Eaq8Uk+egKrZisOUmmYlmDocgmt4=; b=tD2b7qHFQ7oYwtOmSDDTwRGIJN /rQMpK0ZiRqh+bnYPefiOQA8+p/aTxWRs8CuWxJZfchlNXnPchYKpq6LxRDz1Sc4f1YJiG+n9K70B Q4gubZFsUAcDs+8afmyN4gg8w+cyN8XteQApChyebyJWx6/rAkhrgM1lc2rxrwjAULJM=; Date: Wed, 10 Dec 2025 15:40:13 +0100 From: Anthony PERARD To: Jason Andryuk Cc: xen-devel@lists.xenproject.org, Victor Lira , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk , Timothy Pearson , Alistair Francis , Bob Eshleman , Connor Davis , Oleksii Kurochko , Grygorii Strashko Subject: Re: [PATCH 2/2] xen: Add CONFIG_GC_SECTIONS Message-ID: References: <20251209214728.278949-1-jason.andryuk@amd.com> <20251209214728.278949-3-jason.andryuk@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251209214728.278949-3-jason.andryuk@amd.com> On Tue, Dec 09, 2025 at 04:47:28PM -0500, Jason Andryuk wrote: > diff --git a/xen/Makefile b/xen/Makefile > index e6cf287425..aeb5dcf2ee 100644 > --- a/xen/Makefile > +++ b/xen/Makefile > @@ -469,10 +469,13 @@ all-symbols-$(CONFIG_FAST_SYMBOL_LOOKUP) += --sort-by-name > > include $(srctree)/arch/$(SRCARCH)/arch.mk > > +XEN_FINAL_LDFLAGS-$(CONFIG_GC_SECTIONS) := --gc-sections Is there a good reason to add this flags after the arch-specific makefiles? If not, could you move that just before, and right after the definition of "$(all-symbols)" as it's a variable that is used in the same phase of the build. (With Jan's other feedback) > # define new variables to avoid the ones defined in Config.mk > export XEN_CFLAGS := $(CFLAGS) > export XEN_AFLAGS := $(AFLAGS) > export XEN_LDFLAGS := $(LDFLAGS) > +export XEN_FINAL_LDFLAGS := $(LDFLAGS) $(XEN_FINAL_LDFLAGS-y) "FINAL" isn't very descriptive. A completely wrong interpretation might be that we should use the "final" variable instead of "XEN_LDFLAGS". How about a name that describe where this set of flags is going to be used, like "XEN_LDFLAGS_xen_syms" (which unfortunately doesn't exactly fit with x86 xen.efi target), or maybe suffix it with "_target" or just "_xen"? (In Linux build system, they use "LDFLAGS_vmlinux", but I don't know what would be the equivalent of "vmlinux" in our build system.) The prefix "XEN_" is used as namespace, with one reason described in the comment. Also, could you use $(XEN_LDFLAGS) instead of $(LDFLAGS) ? Cheers, -- Anthony PERARD