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

[Jaromír Doleček <jaromir.dolecek%gmail.com@localhost>]

Fix committed. The compiler was correct - I reused code around
frame_list from setup, didn't notice the type is different.

Thank yo.

Jaromir

Le ven. 10 avr. 2020 à 22:35, Robert Elz <kre%munnari.oz.au@localhost> a écrit :
>
>     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
>