Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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

Thank yo.


Le ven. 10 avr. 2020 à 22:35, Robert Elz <> a écrit :
>     Date:        Thu,  9 Apr 2020 22:24:47 +0000 (UTC)
>     From:        NetBSD Test Fixture <>
>     Message-ID:  <>
>   | This is an automatically generated notice of a NetBSD-current/i386
>   | build failure.
> The i386 build remains broken since this commit:
>   |     2020. 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

Home | Main Index | Thread Index | Old Index