[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Automated report: NetBSD-current/i386 build failure
Date: Thu, 9 Apr 2020 22:24:47 +0000 (UTC)
From: NetBSD Test Fixture <bracket%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:
in this line:
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
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,)
Main Index |
Thread Index |