Date: Sat, 19 Nov 2016 18:48:34 -0800 From: Mark Millard <markmi@dsl-only.net> To: Justin Hibbits <jhibbits@freebsd.org>, Alan Cox <alc@freebsd.org> Cc: svn-src-head@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] Message-ID: <AD552A9F-9F44-428C-B6EC-D35526B92039@dsl-only.net> In-Reply-To: <20161119203128.2ac46708@zhabar.knownspace> References: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> <20161119203128.2ac46708@zhabar.knownspace>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-Nov-19, at 6:31 PM, Justin Hibbits <jhibbits at freebsd.org> wrote: > On Sat, 19 Nov 2016 18:19:37 -0800 > Mark Millard <markmi at dsl-only.net> wrote: > >>> Author: jhibbits >>> Date: Fri Nov 18 22:59:33 2016 >>> New Revision: 308817 >>> URL: https://svnweb.freebsd.org/changeset/base/308817 >>> >>> Log: >>> Fix buildworld >>> >>> Change the pv_tracked flag to an int, just in case userspace >>> decides to include this file and defines BOOKE. >>> >>> Guard this block from unintentional inclusion with ifdef BOOKE. >>> >>> Reported by: emaste >> . . . >> >> (Later quotes are not from the list or from E-mail but from files.) >> >> I'm not targeting BOOKE but GENERIC64 (via include, with AIM but not >> ps3). I'm at head -r308860 yet for TARGET_ARCH=powerpc64 I get the >> following that did not happen with my older -r308247 builds: >> >>> --- kinfo_getallproc.o --- >> . . . >>> In file included from /usr/src/sys/sys/user.h:53:0, >>> from q:34: >>> /usr/src/sys/vm/vm_map.h:190:2: error: unknown type name 'pmap_t' >>> pmap_t pmap; /* (c) Physical map */ >>> ^ >>> /usr/src/sys/vm/vm_map.h:250:14: error: field 'vm_pmap' has >>> incomplete type struct pmap vm_pmap; /* private physical map */ >>> ^ >>> --- kinfo_getfile.o --- >>> In file included from /usr/src/sys/sys/user.h:53:0, >>> from /usr/src/lib/libutil/kinfo_getfile.c:5: >>> /usr/src/sys/vm/vm_map.h:190:2: error: unknown type name 'pmap_t' >>> pmap_t pmap; /* (c) Physical map */ >>> ^ >>> /usr/src/sys/vm/vm_map.h:250:14: error: field 'vm_pmap' has >>> incomplete type struct pmap vm_pmap; /* private physical map */ >> >> >> It is almost like a machine/pmap.h include is missing now so that the >> types are not defined. But I've not yet found where the relevant >> difference(s) are from -r308247. >> >> Showing a compile command (with -v) with its failure. . . >> > > The change is the "#elif defined(BOOKE)". Since userspace doesn't > define either AIM nor BOOKE, struct pmap no longer exists. > > Alan, do you know if vmspace *needs* struct pmap to exist when read > from userspace (in libprocstat and libkvm, from what I grepped)? If > not, I can add a simple '#else struct pmap {};' to quiet the build. > > - Justin pmap_t (the pointer type) would also be needed. So far as I can tell when . . . . . . #if defined(AIM) . . . (definitions here) #elif defined(BOOKE) . . . (definitions here) #endif . . . was instead the older: . . . #if defined(AIM) . . . (definitions here) #else . . . (definitions here) #endif . . . kinfo_getallproc.c and kinfo_getfile.c and the like got a pmap definition, just not necessarily the right one (when AIM was defined for build kernel). In my context AIM is defined for buildkernel (PowerMac G5 via GENERIC64 use, although I turn off ps3 and have both vt and sc). (I've still not tracked down where kinfo_getallproc.c and kinfo_getfile.c end up with a machine/pmap.h include happening.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AD552A9F-9F44-428C-B6EC-D35526B92039>