Re: [PATCH 1/7] tools/xenalyze: Work around GCC-15 -Werror=nonnull false positive

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Sat, Jun 13, 2026 at 12:09:18AM +0100, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> ---
> CC: Anthony PERARD <anthony.perard@xxxxxxxxxx>
> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> CC: Michal Orzel <michal.orzel@xxxxxxx>
> CC: Doug Goldstein <cardoe@xxxxxxxxxx>
> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> CC: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> CC: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
> 
> I don't particularly like this, but I see no better option.  It's clearly some
> kind of VRA failure, yet we don't see it with GCC 15 in other distros.  I
> suspect that Musl (as opposed to glibc) might be relevant, and perhaps even as
> simple as not realising that error() is terminal for a non-zero input.

While it's true in this case, maybe it's a bit too complicated for gcc
to find out? error() is terminal only if the first argument is greater
than opt.tolerance, but there's a check that it can't be too high (when
parsing options) and ERR_SYSTEM is above that.

If I do that:

     void error(enum error_level l, struct record_info *ri)
     {
    -    if ( l > opt.tolerance )
    +    if ( l > opt.tolerance || l > ERR_MAX_TOLERABLE)

gcc seems happy enough.

And I've notice the compilation error only happens with `debug=n`.

What do you thing of changing the error() function instead of hidding
NULL-less of the pointer?

> ---
>  tools/xentrace/xenalyze.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
> index 876d59d42ca5..cec1354cf779 100644
> --- a/tools/xentrace/xenalyze.c
> +++ b/tools/xentrace/xenalyze.c
> @@ -3789,6 +3789,17 @@ void update_io_address(struct io_address ** list, 
> unsigned int pa, int dir,
>              error(ERR_SYSTEM, NULL);
>          }
>  
> +        /*
> +         * GCC 15.2 in Alpine Linux 3.24 fails with -Werror=nonnull,
> +         * complaining that we're calling bzero(NULL, 128).
> +         *
> +         * This looks to be a false positive as p being NULL will never reach
> +         * here as the error() above will have called exit().
> +         *
> +         * Work around this by hiding the NULL-ness of p from the compiler.
> +         */
> +        asm ("" : "+r" (p));
> +
>          bzero(p, sizeof(*p));
>  
>          p->pa=pa;


--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech