Page MenuHomeFreeBSD

Fix TARGET_TRIPLE assembly and retrieve OS version automatically

Authored by alfredo on Feb 18 2019, 7:30 PM.
Referenced Files
Unknown Object (File)
Fri, Mar 22, 11:35 AM
Unknown Object (File)
Mar 9 2024, 1:54 PM
Unknown Object (File)
Mar 4 2024, 3:32 PM
Unknown Object (File)
Mar 2 2024, 6:22 PM
Unknown Object (File)
Feb 12 2024, 5:46 AM
Unknown Object (File)
Dec 25 2023, 5:07 PM
Unknown Object (File)
Dec 22 2023, 8:21 PM
Unknown Object (File)
Dec 10 2023, 1:09 PM



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


Test Plan

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

Diff Detail

Lint Passed
No Test Coverage
Build Status
Buildable 34745
Build 31801: arc lint + arc unit

Event Timeline

alfredo retitled this revision from Fix TARGET_TRIPLE variable computation when specifying TARGET_ABI to Fix TARGET_TRIPLE variable assembly when specifying TARGET_ABI.Feb 18 2019, 7:41 PM
alfredo edited the summary of this revision. (Show Details)
alfredo edited the test plan for this revision. (Show Details)
alfredo added reviewers: emaste, bdragon, jhibbits.

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.

This revision is now accepted and ready to land.Feb 18 2019, 8:57 PM

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?


any way of getting this automatically?


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


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. think you can make the changes @jhb and @imp are suggesting? Looks fine to me overall.

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

This revision now requires review to proceed.Jul 1 2019, 8:29 PM

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

remove a level of identation

352 ↗(On Diff #59315)

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

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.

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

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 to get this info.
And I think you want is something like

.if !defined(OS_VERSION)
.export OS_VERSION

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

removed debugging temporary code

Needs reroll after the massive libcompat changes settle down.

alfredo retitled this revision from Fix TARGET_TRIPLE variable assembly when specifying TARGET_ABI to Fix TARGET_TRIPLE assembly and retrieve OS version automatically.Nov 9 2019, 1:45 AM

Need to reroll

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/" 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 edited the summary of this revision. (Show Details)

Updated patch to latest HEAD (thanks to @bdragon)

Updated patch to latest HEAD


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 added inline comments.

Hi @bdrewery, I found no noticeable difference here:

without patch:


with patch:


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.


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

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


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

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