Fix TARGET_TRIPLE assembly and retrieve OS version automatically

[alfredo]

Summary

This removes the hardcoded FreeBSD OS version used in target triple.
Also fixes wrong TARGET_TRIPLE assembly where TARGET_ABI is written where "vendor" string is expected. It's expected to be in the form "<arch><sub>-<vendor>-<sys>-<abi>" [1], but it's currently calculated as "<arch><sub>-<abi>-<sys>"

As example, 'make buildworld TARGET=powerpc TARGET_ARCH=powerpc64 TARGET_ABI=elfv2' must end like: 'TARGET_TRIPLE=powerpc64-unknown-freebsd13.0-elfv2'

TARGET_TRIPLE is used as argument to clang's "-target" parameter specially when cross compiling.

*note <sub> is ignored in this patch as well

[1] https://clang.llvm.org/docs/CrossCompilation.html#target-triple

Test Plan

buildworld powerpc64-elfv2 (cross)
buildworld x86_64 (native)

[bdragon]

Yeah, that's better.

Since I'm not an official member, make sure and get more approvals.

This will need verification on mips and arm I believe, to ensure nothing breaks.

[imp]

Makefile.inc1

136

not an objection, per-se, but an observation that these same transforms are used 4 times in an identical fasion. Any way to make that more common?

137

any way of getting this automatically?

[jhb]

Makefile.inc1

136

You could have TARGET_TRIPLE_ARCH and MACHINE_TRIPLE_ARCH helper variables to at least cut it in half.

137

Not really, it's the version we are building as opposed to the build host, etc. We already have to bump this one when creating a new branch, this just centralizes it. I think Makefile.libcompat also hardcodes freebsd13 and it would be nice if we could fix that to use OS_VERSION as part of this change.

[jhibbits]

@alfredo.junior_eldorado.org.br think you can make the changes @jhb and @imp are suggesting? Looks fine to me overall.

[alfredo]

I updated the patch to retrieve FreeBSD version automatically, however I'm not sure on how to better address 'lib/clang/llvm.build.mk'. The variables created on 'Makefile.inc1' are not visible there.

[alfredo]

TARGET=powerpc TARGET_ARCH=powerpc64 produces:

clang -target powerpc64-unknown-freebsd13.0

TARGET=powerpc TARGET_ARCH=powerpc64 TARGET_ABI=elfv2 produces:

clang -target powerpc64-unknown-freebsd13.0-elfv2

[alfredo]

remove a level of identation

[bdragon]

share/mk/sys.mk

352 ↗

(On Diff #59315)

This grep doesn't seem to actually work for some reason. It isn't picking up SRCTOP...

[bdragon]

share/mk/sys.mk

352 ↗

(On Diff #59315)

of course now I'm having trouble reproducing this. I distinctly remember seeing lots of "grep: /sys/sys/param.h not found" but I'm not seeing it anymore.

[imp]

So I think this belongs in share/mk/src.sys.env.mk, but I'm not sure.

share/mk/sys.mk

352 ↗

(On Diff #59315)

One $ is what you want since SRCTOP is a makefile variable.
However, I'm 100% sure this is the wrong place for this.
Also, just use newvers.sh to get this info.
And I think you want is something like

.if !defined(OS_VERSION)
OS_VERSION!=${SRCTOP}/sys/conf/newvers.sh -V REVISION
.export OS_VERSION
.endif

[alfredo]

This is a reworked version. I found that FreeBSD release was already being retrieved in share/mk/local.meta.sys.mk using variable FREEBSD_REVISION. Then I moved it to share/mk/src.sys.env.mk to make variable readable everywhere.

[alfredo]

removed debugging temporary code

[bdragon]

Needs reroll after the massive libcompat changes settle down.

[alfredo]

Need to reroll

share/mk/sys.mk

352 ↗

(On Diff #59315)

Strange, it works for me.
Does "make -v OS_VERSION" give "13.0" for you?

I appended the following code

BLA!=echo '$${SRCTOP}/sys/sys/param.h'
.info BLA SRCTOP is ${BLA}

and it gives me:

# make
make: "/root/src/freebsd/share/mk/sys.mk" line 358: BLA SRCTOP is /root/src/freebsd/sys/sys/param.h

Explicit target required.  Likely "buildworld" is wanted.  See build(7).

Also, changing /sys/sys/param.h doesn't change OS_VERSION value. If I change /root/src/freebsd//sys/sys/param.h it does change OS_VERSION

I tried to reproduce using the shells "csh, bash and sh" and result is ok to me.
What's the build command you're using ?

[alfredo]

Updated patch to latest HEAD (thanks to @bdragon)

[alfredo]

Updated patch to latest HEAD

[bdrewery]

share/mk/src.sys.env.mk

26–29

I think the export will handle my concern but can you compare the time for make -j1 print-dir with and without this change? Maybe run it an extra time first to prime the caches.

[alfredo]

share/mk/src.sys.env.mk

26–29

Hi @bdrewery, I found no noticeable difference here:

without patch:

1m18.201s
1m19.308s
1m18.782s
1m18.452s

with patch:

1m18.515s
1m18.386s
1m18.265s
1m18.228s

[brooks]

This generally looks fine.

The new MACHINE_ABI use will create conflicts with CheriBSD, but we can pick another name if needed. In CheriBSD we've renamed MACHINE_ABI to _MACHINE_ABI in Makefile.inc1 since it appears completely unused and MACHINE_ABI is now a list of ABI features similar to MACHINE_CPU.

[arichardson]

Makefile.inc1

139

Internally llvm::Triple uses "environment" rather than "abi" because the last component can also contain suffixes like -elf to indicate the object format.

https://github.com/llvm/llvm-project/blob/3b6481eae2597f656b9f5bb6a5eb5438eb8cb294/llvm/include/llvm/ADT/Triple.h#L386

If we were to use {TARGET,MACHINE}_TRIPLE_ENVIRONMENT (or {TARGET,MACHINE}_TRIPLE_ABI) instead, that would avoid conflicts with CheriBSD?

[alfredo]

Makefile.inc1

139

The problem with {TARGET,MACHINE}_ABI is that its use appears to be incorrect. Actually users wanted to use {TARGET,MACHINE}_VENDOR instead, when following "<arch><sub>-<vendor>-<sys>-<abi>" format. (note we don't have {TARGET,MACHINE}_SUB, we append it to {TARGET,MACHINE}_ARCH value)

I like your proposal of having {TARGET,MACHINE}_TRIPLE_ENVIRONMENT to customize compiler target triple (like {TARGET,MACHINE}_TRIPLE the overrides everything)
In this case I would drop {TARGET,MACHINE}_ABI and print a message explaining it should use {TARGET,MACHINE}_VENDOR to fill <vendor> field of target triple

[alfredo]

Suspending this since it requires changes to continue.
The OS revision part is now being discussed in D34429.

[alfredo]

This was superseded by https://reviews.freebsd.org/D36420