RFC: Use file-prefix-map to lie about build paths

[dan.mcgregor_usask.ca]

Summary

Unconditionally remap the cross sysroot to /, so debug information
points to (for example) /usr/include rather than
/usr/obj/usr/src/amd64.amd64/tmp/usr/include.

If MK_REPRODUCIBLE_BUILD is on, then use file-prefix-map to replace
SRCDIR with /usr/src, and OBJDIR with /usr/obj/usr/src. This causes
builds to appear to come from /usr/src and be build from /usr/obj no
matter the real paths.

[dan.mcgregor_usask.ca]

This is a large portion of the userland changes to give consistent debug data path data no matter the source or object directories. There are more reviews coming.

[brooks]

I think this is like to need a ports exp-run.

share/mk/bsd.compat.mk

145–146

I'm not a fan of the _libcompat_machine variable name. I think I might write this something like the suggestion.

share/mk/bsd.sys.mk

268–271

These lines should go.

[dan.mcgregor_usask.ca]

share/mk/bsd.compat.mk

145–146

I'm not a huge fan of the name either, but.. three hard problems in computer science.

The issue I have with your suggestion is goals. On the high level it's reproducibility, and your suggestion maintains that. But it changes the debug output of the compat builds. I'll use amd64 as an example: with my change, the 32-bit libraries show the path /usr/obj/usr/src/i386.i386/ in their debug data, just as if it were an i386 build. With your suggestion, it gives /usr/obj/usr/src/amd64.amd64/obj-lib32/.

Neither is objectively right or wrong, but I prefer the former.

share/mk/bsd.sys.mk

268–271

Agreed, they'll be gone in the next version of this.

[dan.mcgregor_usask.ca]

share/mk/bsd.compat.mk

145–146

Hmm. Looks like I haven't tested this as extensively as I had when I wrote it against 12. The intent was as I describe, but with 14 my output is what your suggestion would do. Looks like I might need to revisit that part :/

[brooks]

share/mk/bsd.compat.mk

145–146

We've extended bsd.compat.mk substantially in 13+ so things work quite a bit differently, in particular it's shared between use by Makefile.libcompat and use in libexec/rtld-elf32/Makefile, etc.

Now that I understand what you're proposing here, I think my suggestion is what we want because there are subtle differences between a few libraries built for /usr/lib32 and the native 32-bit ones due to the need to look elsewhere for things like PAM modules. In some cases the differences may be considerably less subtle (e.g., in CheriBSD memcpy uses CHERI instructions when built for lib32, but does so optionally when it's the default ABI).