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

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

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@xxxxxxxxx
> > > wrote:
> > > > From: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
> > > >
> > > > 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@xxxxxxxxx>
> > >
> > > Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > >
> > > > ---
> > > > 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