Re: [XEN PATCH v9 08/30] build: fix enforce unique symbols for recent clang version

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.01.2022 13:03, Anthony PERARD wrote:
> On Thu, Jan 27, 2022 at 04:57:20PM +0100, Jan Beulich wrote:
>> On 25.01.2022 12:00, 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.
>>>
>>> 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.
>>>
>>> This means that we also need to check clang version to figure out
>>> which command we need to use to redefine symbol.
>>>
>>> Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>>
>> The "likely" in the description still worries me some. Roger, would
>> you happen to know, or know of a way to find out for sure ("sure"
>> not meaning to exclude the usual risk associated with version
>> number checks)?
> 
> I found f5040b9685a7 ("Make .file directive to have basename only") as
> part of LLVM's "release/6.x" branch (and "llvmorg-6.0.0" tag), but not
> in "release/5.x".
> 
> https://github.com/llvm/llvm-project/commit/f5040b9685a760e584c576e9185295e54635d51e
> 
> This patch would seems to be the one changing the behavior. This still
> suggest clang 6.0.

Oh, thanks for digging this out. May I suggest to replace (or delete)
"likely" then in the description?

Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan