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 <k...@munnari.oz.au> a écrit : > > Date: Thu, 9 Apr 2020 22:24:47 +0000 (UTC) > From: NetBSD Test Fixture <brac...@netbsd.org> > Message-ID: <158647108721.6125.11585167398565454...@babylon5.netbsd.org> > > | 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 >