Re: Automated report: NetBSD-current/i386 build failure

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu,  9 Apr 2020 22:24:47 +0000 (UTC)
    From:        NetBSD Test Fixture <bracket%NetBSD.org@localhost>
    Message-ID:  <158647108721.6125.11585167398565454187%babylon5.NetBSD.org@localhost>

  | This is an automatically generated notice of a NetBSD-current/i386
  | build failure.

The i386 build remains broken since this commit:

  |     2020.04.09.19.26.38 jdolecek src/sys/arch/xen/xen/xengnt.c,v 1.31

The problem is when compiling i386_PAE and is in the new function:

	 static int
  	 xengnt_map_status(void)

in this line:

         set_xen_guest_handle(getstatus.frame_list, pages);

which gcc diagnoses as assigning a pointer of one type to a
pointer of a different tye (u_long * being assigned to unsigned long long *).

While I have issues with this kind of thing being treated as an error,
it looks as if it might be easy to fix.

"pages" is the u_long * - and looks as if it should be a paddr_t *

When it is dereferenced later in the code, the value is cast to a paddr_t

This would perhaps be a real bug, as (as best I understand the x86
architecture) a u_long is not big enough to hold a paddr_t on 386 PAE.
(Only perhaps, as it looks as if it is really storing page numbers,
not paddr_t's at all, but ...)

Changing "pages" to be paddr_t * instead of u_long * seems to fix the
i386 builds (I also deleted the now redundant cast on the dereference
in the same function - whether there are more elsewhere I didn't look.)

I am not going to commit this, as I don't understand what is happening
well enough, and I also haven't tested to confirm that the amd64 builds
still work with that change made.

Jaromir could you check this, and commit a fix so as to make the i386 builds
work again?

There was a similar problem in a debug printf earlier, that was "fixed" by
turning off XEN_DEBUG (so the code isn't being compiled) - but it was a
related problem, with printf formats (attempting to print a paddr_t as
a pointer I(%p) I believe in that case (with a cast, but paddr_t's cannot
be transformed into pointers directly on PAE systems, I think,)

kre