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

Authored by dan.mcgregor_usask.ca on Feb 18 2021, 12:22 AM.

Details

Reviewers

brooks
arichardson

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.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 37145
Build 34034: arc lint + arc unit

Event Timeline

dan.mcgregor_usask.ca created this revision.Feb 18 2021, 12:22 AM

Herald added subscribers: emaste, bdrewery. · View Herald TranscriptFeb 18 2021, 12:22 AM

dan.mcgregor_usask.ca requested review of this revision.Feb 18 2021, 12:22 AM

Harbormaster completed remote builds in B37145: Diff 84169.Feb 18 2021, 12:22 AM

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.

dan.mcgregor_usask.ca mentioned this in D28765: RFC: Use file-prefix-map to lie about kernel build paths.Feb 18 2021, 12:26 AM

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 added inline comments.Feb 18 2021, 1:49 AM

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 added inline comments.Feb 18 2021, 2:34 AM

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 added inline comments.Feb 18 2021, 4:58 PM

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