[v2] build: Make FILE symbol paths consistent

Commit Message

Ross Lagerwall Feb. 13, 2023, 4:55 p.m. UTC

The FILE symbols in out-of-tree builds may be either a relative path to
the object dir or an absolute path depending on how the build is
invoked. Fix the paths for C files so that they are consistent with
in-tree builds - the path is relative to the "xen" directory (e.g.
common/irq.c).

This fixes livepatch builds when the original Xen build was out-of-tree
since livepatch-build always does in-tree builds. Note that this doesn't
fix the behaviour for Clang < 6 which always embeds full paths.

Fixes: 7115fa562fe7 ("build: adding out-of-tree support to the xen build")
Signed-off-by: Ross Lagerwall <[e-mail]>
---

In v2:
* Adjust commit description.
* Rename rel_path.

 xen/Rules.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Jan Beulich Feb. 15, 2023, 9:55 a.m. UTC | #1

On 13.02.2023 17:55, Ross Lagerwall wrote:
> The FILE symbols in out-of-tree builds may be either a relative path to
> the object dir or an absolute path depending on how the build is
> invoked. Fix the paths for C files so that they are consistent with
> in-tree builds - the path is relative to the "xen" directory (e.g.
> common/irq.c).
> 
> This fixes livepatch builds when the original Xen build was out-of-tree
> since livepatch-build always does in-tree builds. Note that this doesn't
> fix the behaviour for Clang < 6 which always embeds full paths.

Is "fix" here actually correct? I.e. is there anything to fix in that
case? It looks to me as if "always absolute paths" is as good as
"always relative paths". In which case s/fix/alter/?

> Fixes: 7115fa562fe7 ("build: adding out-of-tree support to the xen build")
> Signed-off-by: Ross Lagerwall <[e-mail]>

With the above clarified (a possible adjustment could be done while
committing):
Reviewed-by: Jan Beulich <[e-mail]>

Jan

Ross Lagerwall Feb. 15, 2023, 10:15 a.m. UTC | #2

> From: Jan Beulich <[e-mail]>
> Sent: Wednesday, February 15, 2023 9:55 AM
> To: Ross Lagerwall <[e-mail]>
> Cc: Andrew Cooper <[e-mail]>; George Dunlap <[e-mail]>; Julien Grall <[e-mail]>; Stefano Stabellini <[e-mail]>; Wei Liu <[e-mail]>; Anthony Perard <[e-mail]>; [e-mail] <[e-mail]>
> Subject: Re: [PATCH v2] build: Make FILE symbol paths consistent 
>  
> On 13.02.2023 17:55, Ross Lagerwall wrote:
> > The FILE symbols in out-of-tree builds may be either a relative path to
> > the object dir or an absolute path depending on how the build is
> > invoked. Fix the paths for C files so that they are consistent with
> > in-tree builds - the path is relative to the "xen" directory (e.g.
> > common/irq.c).
> > 
> > This fixes livepatch builds when the original Xen build was out-of-tree
> > since livepatch-build always does in-tree builds. Note that this doesn't
> > fix the behaviour for Clang < 6 which always embeds full paths.
> 
> Is "fix" here actually correct? I.e. is there anything to fix in that
> case? It looks to me as if "always absolute paths" is as good as
> "always relative paths". In which case s/fix/alter/?
> 

If embedding absolute paths, the livepatch-build process will fail to
match symbols between the base xen-syms and the newly built, patched
objects unless they are built with the source directory at the exact
same path. So yes, I would consider this as not "fixed" for Clang < 6.

Thanks,
Ross

Patch

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 70b7489ea8..d6b7cec0a8 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -228,8 +228,9 @@  quiet_cmd_cc_o_c = CC      $@
 ifeq ($(CONFIG_ENFORCE_UNIQUE_SYMBOLS),y)
     cmd_cc_o_c = $(CC) $(c_flags) -c $< -o $(dot-target).tmp -MQ $@
     ifneq ($(CONFIG_CC_IS_CLANG)$(call clang-ifversion,-lt,600,y),yy)
+        rel-path = $(patsubst $(abs_srctree)/%,%,$(call realpath,$(1)))
         cmd_objcopy_fix_sym = \
-	    $(OBJCOPY) --redefine-sym $(<F)=$< $(dot-target).tmp $@ && rm -f $(dot-target).tmp
+           $(OBJCOPY) --redefine-sym $(<F)=$(call rel-path,$<) $(dot-target).tmp $@ && rm -f $(dot-target).tmp
     else
         cmd_objcopy_fix_sym = mv -f $(dot-target).tmp $@
     endif