[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] Strip build path directories in tools and hypervisor


  • To: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 4 Sep 2025 14:58:20 +0200
  • Autocrypt: addr=jbeulich@xxxxxxxx; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL
  • Cc: Anthony PERARD <anthony.perard@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 04 Sep 2025 12:58:37 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 04.09.2025 13:41, Marek Marczykowski-Górecki wrote:
> Use -fdebug-prefix-map in preference to -ffile-prefix-map, as it's
> available in earlier toolchain versions. But use it together with
> -fmacro-prefix-map (if available) for hypervisor build, otherwise it
> still contains some paths in out-of-tree builds.

I consider it wrong not to use -ffile-prefix-map when available. That
already covers more than "debug" and "macro", and it may gain further
functionality.

> The out of tree build requires -fdebug-prefix-map mapping for both source
> dir and object dir - otherwise the latter is included (2 occurrences) in
> xen-syms.

As indicated in a reply to Andrew on the thread hanging off of my
patch - I think whether to remove those wants to be left to the user.

> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -1,4 +1,4 @@
> -XEN_ROOT = $(CURDIR)/..
> +XEN_ROOT = $(realpath $(CURDIR)/..)
>  
>  export PKG_CONFIG_DIR = $(CURDIR)/pkg-config
>  
> diff --git a/tools/Rules.mk b/tools/Rules.mk
> index 725c3c32e9a2..428fce094819 100644
> --- a/tools/Rules.mk
> +++ b/tools/Rules.mk
> @@ -166,6 +166,8 @@ endif
>  CFLAGS-$(CONFIG_X86_32) += $(call cc-option,$(CC),-mno-tls-direct-seg-refs)
>  CFLAGS += $(CFLAGS-y)
>  
> +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(realpath $(XEN_ROOT))=.)

Here and below - no need to use cc-option-add for -fdebug-prefix-map,
which all permissible compilers support.

Further, again as per reply to Andrew on the thread hanging off of my
patch - I don't view it as desirable to leave the tools/ prefix in
place, or e.g. for libraries, the entire tools/libs/<subdir>/ part.
Imo every binary should have only the path (if any) from its own source
root left. (And yes, how to deal with e.g. shared include files isn't
quite clear to me, yet. Maybe we actually need to pass two options.)

> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -208,7 +208,7 @@ VPATH := $(srctree)
>  
>  export srctree objtree VPATH
>  
> -export XEN_ROOT := $(abs_srctree)/..
> +export XEN_ROOT := $(patsubst %/xen,%,$(abs_srctree))

Unlike for tools/, is this still needed here? You don't use XEN_ROOT below.

> @@ -412,6 +412,10 @@ ifneq ($(CONFIG_CC_IS_CLANG),y)
>  CFLAGS += -Wa,--strip-local-absolute
>  endif
>  
> +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(abs_objtree)=./xen)
> +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(abs_srctree)=./xen)
> +$(call cc-option-add,CFLAGS,CC,-fmacro-prefix-map=$(abs_srctree)=./xen)

I disagree with leaving any xen/ prefix there. That's not how in-tree builds
name files; everything there is relative to xen/.

I also don't really see a point in using . in the substitution (similarly
for the toolstack, but there I have less to say).

Finally, why pass two identical, possibly long options for in-tree builds
(where $(abs_objtree) == $(abs_srctree))?

Below I'll reproduce my own further re-worked patch. It's not quite ready
for v2 submission yet, I expect though. For example, the actual Kconfig
portion is still missing. Whether the @SRC@ and @BLD@ parts actually make
sense (or what to replace them by) I'm also unsure about. If nothing else
they may need replacing by plain .

Jan

build: avoid absolute paths in executables

For in-tree builds relative paths are used in most cases, whereas for out-
of-tree builds in various situations absolute ones come into play. The
extra paths can be long, wasting space and e.g. serial line bandwidth.
They would also get in the way of location-independent reproducible
builds. Leverage newer gcc's (and Clang's) ability to "remap" file names.
For older gcc fall back to using the option affecting debug info only.

For the few absolute paths appearing in in-tree builds' debug info, use
the generally available option, conditional upon a new Kconfig control

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
---
Of course we may want to consider putting this in the top-level Config.mk,
to also affect other sub-trees (presently mainly/only affecting debug
info, for which even gcc5 already supports -fdebug-prefix-remap=).

As to a Fixes: tag, I wasn't quite sure whether to "blame" the
introduction of out-of-tree builds.

Note that at least in the gcc5 I'm testing with the (limited) effect is
further undermined by the compiler emitting the specified command line
options into debug info, thus still leaving references to the absolute
directories in place.

For the mentioned gcc15 issue see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121788.
---
v2: Use $(abs_srctree). Introduce DEBUG_INFO_REL_PATHS.

--- a/xen/Makefile
+++ b/xen/Makefile
@@ -461,7 +461,21 @@ CFLAGS += -flto
 LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin LLVMgold.so
 endif
 
+CFLAGS-$(CONFIG_DEBUG_INFO_REL_PATHS) += 
-fdebug-prefix-map=$(abs_srctree)=@SRC@
+
 ifdef building_out_of_srctree
+    # Need to add to CFLAGS-y here, as gcc checks later options before earlier
+    # ones, and we want in particular the latter one(s) here to be checked
+    # first.
+    CFLAGS-$(CONFIG_DEBUG_INFO_REL_PATHS) += 
-fdebug-prefix-map=$(abs_objtree)=@BLD@
+    CFLAGS-y += $(call cc-option,$(CC),-ffile-prefix-map=$(abs_srctree)/=)
+    # While -ffile-prefix-map= implies -fdebug-prefix-map=, we need to use the
+    # latter explicitly: Up to at least gcc15 the compiler specs translate all
+    # -ffile-prefix-map= ahead of all -fdebug-prefix-map= when invoking the
+    # the assembler for *.S files, thus breaking our intended ordering.
+    # (Otherwise the option below could be passed as 3rd [fallback] argument to
+    # cc-option above.)
+    CFLAGS-y += -fdebug-prefix-map=$(abs_srctree)/=
     CFLAGS += -I$(objtree)/include
     CFLAGS += -I$(objtree)/arch/$(SRCARCH)/include
 endif




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.