Fix 32-bit build.

It shouldn't be built for powerpc32, only powerpc64. However, it doesn't hurt anything, and is a good belt-and-suspenders change.

Address @kib's feedback. The man page will probably need more iterating, but I
think the code is correct. It may not be optimal, though.

Don't call getpid(), we can pass 0 now.

Incorporate mjg's changes.

Add a new sysctl, kern.proc.fdmap.<proc>, to provide the bitmap. Walk the bitmap instead of the file descriptor list.

In D21206#461101, @mjg wrote:

It's not hard to add such a sysctl. If you want I can hack it up for you. I think it should just export the fd bitmap, then iteration over it is trivial.

Address @kib's feedback. Man page will probably require several iterations
to get right. It's still a little muddy.

Looks fine overall, just the one question. I just want to be sure this is thoroughly tested before it goes in, on the corner cases.

Looks good now.

Looks good. Can the same change apply to powerpc?

Address @hselasky's comments.

In D20827#458864, @luporl wrote:

In D20827#458843, @jhibbits wrote:

Thanks for checking. Looks good. I assume you tested on bare metal, too?

Actually, I've tested on VMs only, as this changes loader only, that is not used on POWER8 and above.
Do you want to test this on a G5? Or is there a way to test loader under PetitBoot?

Thanks for checking. Looks good. I assume you tested on bare metal, too?

@hselasky yes, I'm working on it, but got sidetracked doing other things while working on it. I'll have an update either tonight or tomorrow.

In D21096#457864, @hselasky wrote:

I'll have a closer look tomorrow. Most of this looks good.
Is this patch also needed for powerpc?
D21008

Have you checked performance on this latest version?

Make MOEA64_STATS a compile option

I just tested with a *very* small page table (0x8000 entries on a 256GB machine), and hit the 'moea64_pte_insert: overflow' panic, which you had mentioned a few years back is indicative of the PTEGs being filled with wired entries. Checking the statistics, I do see 0x38 overflows, and other statistics look accurate, too. I don't see anything bad in this patch, because the only thing it does is optimistically try to insert the PVO, and go through the normal logic if it already exists.

In D20944#454542, @nwhitehorn wrote:

Just make the page table size really small. There's a spill counter in the statistics; when it gets small enough, you should see it moving. If spill-handling doesn't work, and you have spills, everything breaks fast.

In D20944#454504, @nwhitehorn wrote:

Does this break PTE spills? This code path historically was involved in re-adding PVOs to the hashed page table on faults if they got spilled.

It helps if I use an actual pointer.

Simplify the code. Revert to the first version tested.

I still see merit in keeping statistics available, for assessing performance issues as you mentioned, but I don't see it necessary in the general case. If there are no objections, I'll take @luporl's request and add an option for MOEA64_STATS, possibly enabled in CURRENT, but disabled in STABLE.

What do the statistics give us in general for pmap? I don't see statistics on other archs, so I'm not sure what the benefit is. I understood for bringup and early stabilization, but we're in pretty solid territory now.

In D20598#452687, @markmi_dsl-only.net wrote:

Justin wrote "Secure-PLT is fully compatible with BSS-PLT, so there's no issue with compatibility".
Well, modern ld from devel/powerpc64-binutils exits with an error code when it reports things
like:
QUOTE
bss-plt forced due to /usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crtbeginS.o
END QUOTE
The error code stops buildworld. (The old system binutils' ld does not exit with an error code and so does not stop the build.)

This can now be abandoned, 8.0.1-rc3 was pulled in just the other day.

Looks good overall. Just a couple nits..