libc: Build all i386 sources for amd64 lib32

[jrtc27]

Summary

Having the symbols exported by libc differ between i386 and amd64 lib32
is questionable. Since these files build just fine today, stop guarding
them with !defined(COMPAT_32BIT). Whether or not they work at run time
is a different matter, but an i386 jail would be similarly affected if
not, so that's not a problem with lib32.

[imp]

The only reason I can think of that one might want to restrict these is if we can't support them with 32-bit binaries running on a 64-bit kernel.
Entry into vm86 mode might be one of those things that we can't do, so better, it was thought, to have a link error than a run-time error.
But this will still fail at runtime (if indeed we can't do it), so I don't see any harm in doing this.

I remember having to create an i386 bhyve to run vm86 code that switched to 16-bit mode (or was it protected mode) when I was playing around with a 16-bit unix user-mode emulation.

Anyway, tl;dr: This is fine: either it will fail at runtime or it won't and at worst this changes the failure.

[jrtc27]

In D40937#931699, @imp wrote:

The only reason I can think of that one might want to restrict these is if we can't support them with 32-bit binaries running on a 64-bit kernel.
Entry into vm86 mode might be one of those things that we can't do, so better, it was thought, to have a link error than a run-time error.
But this will still fail at runtime (if indeed we can't do it), so I don't see any harm in doing this.

I remember having to create an i386 bhyve to run vm86 code that switched to 16-bit mode (or was it protected mode) when I was playing around with a 16-bit unix user-mode emulation.

Anyway, tl;dr: This is fine: either it will fail at runtime or it won't and at worst this changes the failure.

Yep; at worst it fails the exact same way an i386 jail does today

[jhb]

The watchpoints should work, and a runtime failure for vm86 is ok.