clang 6.0 and newer behave like gcc in regards for the FILE symbol, so
only the filename rather than the full path to the source file.

clang 3.8.1-24 (in our debian:stretch container) and 3.5.0-10
(in our debian:jessie container) do store the full path to the source
file in the FILE symbol.

This means that we also need to check clang version to figure out
which command we need to use to redefine symbol.

I don't know which version of clang change behavior, we will guess
4.0.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---

"enforce unique symbols" works by chance with recent clang version.
The few object built from source in subdir don't pose an issue.

With checking for 4.0 or newer, build may fails with a version of
clang between 4.0 and 6.0.

With checking for 6.0 or newer, no build fails, but maybe that will
happen later with patch "build: build everything from the root dir,
use obj=$subdir" applied.
---

Notes:
    v8:
    - new patch, extracted from "build: build everything from the root dir, use obj=$subdir"

 xen/Rules.mk               | 2 +-
 xen/scripts/Kbuild.include | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 60d1d6c4f583..14b6e7fdd721 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -166,7 +166,7 @@ SRCPATH := $(patsubst $(BASEDIR)/%,%,$(CURDIR))
 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 $@
-    ifeq ($(CONFIG_CC_IS_CLANG),y)
+    ifeq ($(CONFIG_CC_IS_CLANG)$(call clang-ifversion,-lt,400,y),yy)
         cmd_objcopy_fix_sym = $(OBJCOPY) --redefine-sym $<=$(SRCPATH)/$< $(dot-target).tmp $@
     else
         cmd_objcopy_fix_sym = $(OBJCOPY) --redefine-sym $(<F)=$(SRCPATH)/$< $(dot-target).tmp $@
diff --git a/xen/scripts/Kbuild.include b/xen/scripts/Kbuild.include
index 21030cfcfbc1..b4b77f85d8d5 100644
--- a/xen/scripts/Kbuild.include
+++ b/xen/scripts/Kbuild.include
@@ -59,6 +59,8 @@ ld-option = $(call success,$(LD) -v $(1))
 # Usage:  EXTRA_CFLAGS += $(call cc-ifversion, -lt, 0402, -O1)
 cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1) $(2)000 ] && echo $(3) || echo $(4))
 
+clang-ifversion = $(shell [ $(CONFIG_CLANG_VERSION)0 $(1) $(2)000 ] && echo $(3) || echo $(4))
+
 # Shorthand for $(MAKE) clean
 # Usage:
 # $(MAKE) $(clean) dir
-- 
Anthony PERARD

On 25.11.2021 14:39, Anthony PERARD wrote:
> clang 6.0 and newer behave like gcc in regards for the FILE symbol, so
> only the filename rather than the full path to the source file.
> 
> clang 3.8.1-24 (in our debian:stretch container) and 3.5.0-10
> (in our debian:jessie container) do store the full path to the source
> file in the FILE symbol.
> 
> This means that we also need to check clang version to figure out
> which command we need to use to redefine symbol.
> 
> I don't know which version of clang change behavior, we will guess
> 4.0.

When I did this earlier work, it was clang5 that I used. Which would seem
to mean the change in behavior was in version 6.

Jan

On Tue, Dec 07, 2021 at 11:23:26AM +0100, Jan Beulich wrote:
> On 25.11.2021 14:39, Anthony PERARD wrote:
> > clang 6.0 and newer behave like gcc in regards for the FILE symbol, so
> > only the filename rather than the full path to the source file.
> > 
> > clang 3.8.1-24 (in our debian:stretch container) and 3.5.0-10
> > (in our debian:jessie container) do store the full path to the source
> > file in the FILE symbol.
> > 
> > This means that we also need to check clang version to figure out
> > which command we need to use to redefine symbol.
> > 
> > I don't know which version of clang change behavior, we will guess
> > 4.0.
> 
> When I did this earlier work, it was clang5 that I used. Which would seem
> to mean the change in behavior was in version 6.

Thanks, I forgot this fact. I'll make change in the patch, and replace
the last paragraph of the patch description and add something link this
instead:

    Also, based on commit 81ecb38b83 ("build: provide option to
    disambiguate symbol names"), which were using clang 5, the change of
    behavior likely happened in clang 6.0.

Thanks,

-- 
Anthony PERARD