Re: [XEN PATCH] xen: Drop logic for old clang versions.

[Nicola Vetrini <nicola.vetrini@bugseng.com>]

On 2025-08-11 16:35, Roger Pau Monné wrote:
> On Mon, Aug 11, 2025 at 11:37:46AM +0200, Nicola Vetrini wrote:
>> On 2025-08-11 09:47, Roger Pau Monné wrote:
>> > On Sun, Aug 10, 2025 at 03:03:53PM +0200, nicola.vetrini@gmail.com
>> > wrote:
>> > > From: Nicola Vetrini <nicola.vetrini@bugseng.com>
>> > >
>> > > The enforced toolchain baseline for clang is version 11,
>> > > therefore this logic is effectively dead code.
>> > >
>> > > No functional change.
>> > >
>> > > Signed-off-by: Nicola Vetrini <nicola.vetrini@gmail.com>
>> >
>> > Acked-by: Roger Pau Monné <roger.pau@citrix.com>
>> >
>> > > ---
>> > > Mentioned in https://gitlab.com/xen-project/xen/-/issues/201
>> > > ---
>> > >  xen/common/coverage/llvm.c   | 4 ----
>> > >  xen/include/xen/self-tests.h | 9 +--------
>> > >  2 files changed, 1 insertion(+), 12 deletions(-)
>> > >
>> > > diff --git a/xen/common/coverage/llvm.c b/xen/common/coverage/llvm.c
>> > > index 50d7a3c5d301..517b2aa8c202 100644
>> > > --- a/xen/common/coverage/llvm.c
>> > > +++ b/xen/common/coverage/llvm.c
>> > > @@ -44,12 +44,8 @@
>> > >      ((uint64_t)'f' << 16) | ((uint64_t)'R' << 8)  | ((uint64_t)129)
>> > >  #endif
>> > >
>> > > -#if __clang_major__ >= 4 || (__clang_major__ == 3 &&
>> > > __clang_minor__ >= 9)
>> > >  #define LLVM_PROFILE_VERSION    4
>> > >  #define LLVM_PROFILE_NUM_KINDS  2
>> > > -#else
>> > > -#error "clang version not supported with coverage"
>> > > -#endif
>> >
>> > Rant: most of the LLVM coverage stuff is already kind of dead code, as
>> > the format of the data changes between versions and there's no way for
>> > LLVM to generate the blob itself using a builtin function or
>> > similar.  We haven't kept up with new formats, and now it's not
>> > possible to parse the output coverage data when using newish LLVM
>> > versions.
>> >
>> > Linux converts it's LLVM coverage data to gcov format (which AFAIK is
>> > way more stable), and exports it in gcov format.  We should consider
>> > importing that from Linux.
>> >
>> > Thanks, Roger.
>> 
>> Fair point. Generally I found coverage reports generated using LLVM 
>> tooling
>> a bit more informative than gcov's, but I don't know how much work 
>> would it
>> be to adapt Xen for newer versions of LLVM.
> 
> It's a pain because they keep changing the blob format between
> versions, so we would basically need code in Xen to be able to
> generate the right blob for each possible clang version.
> 
> It would be helpful if clang provided the helpers to generate the
> coverage data in a version agnostic way, but so far I haven't found a
> way to do it.  I've raised a question with upstream LLVM project, but
> no replies:
> 
> https://github.com/llvm/llvm-project/issues/123034
> 
> Regards, Roger.

Perhaps the "coverage" and "llvm-cov" tag might help get more traction; 
there is at least one developer working on the source-based code 
coverage area in the past months with various improvements.

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253