Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860]

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.)