[SOLVED] Llvm target triple json - features cause assert failure?

Hi

Maybe this is more of a llvm question but hopefully someone here knows.
I used to build kernel stuff using a custom target triple. After updating my FreeBSD system I get this error when building libcore.

===> Building core
Assertion failed: (hasFlag(Feature)), function ApplyFeatureFlag, file /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/lib/MC/SubtargetFeature.cpp, line 194.
*** Signal 6

Removing this line from the json and the build works:
"features": "+soft-float, -mmx, -sse, -sse2, -sse3, -ssse3, -sse4.1, -sse4.2, -3dnow, -3dnowa, -avx, -avx2"

Any ideas what has changed in llvm and what I'm supposed to use instead of features?
The rust toolchain I use is unchanged.

You can check the supported features by typing

rustc --print target-features

optional you can specify your target with

rustc --target your-triple-here --print target-features

That's not the problem. The problem is that the syntax has changed.
Apparently the old way (as used here: Set Up Rust | Writing an OS in Rust (First Edition))
"features": "+soft-float,-mmx,-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-3dnow,-3dnowa,-avx,-avx2",
Cause assert failure in llvm code. However, this:
"features": ["+soft-float,-mmx,-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-3dnow,-3dnowa,-avx,-avx2"],
seem to work.
That is, it has to be an array, not one long string with features.

I'm still not sure though if this is due to change in llvm or rust...

Interesting enough: I hasn't? I mean, it works for you, but:

rustc --print target-spec-json -Z unstable-options --target thumbv7em-none-eabihf
{
  "abi-blacklist": [
    "stdcall",
    "fastcall",
    "vectorcall",
    "thiscall",
    "win64",
    "sysv64"
  ],
  "arch": "arm",
  "data-layout": "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64",
  "emit-debug-gdb-scripts": false,
  "env": "",
  "executables": true,
  "features": "+vfp4,+d16,+fp-only-sp",
  "is-builtin": true,
  "linker": "arm-none-eabi-gcc",
  "linker-flavor": "gcc",
  "llvm-target": "thumbv7em-none-eabihf",
  "max-atomic-width": 32,
  "os": "none",
  "panic-strategy": "abort",
  "relocation-model": "static",
  "target-c-int-width": "32",
  "target-endian": "little",
  "target-pointer-width": "32",
  "vendor": ""
}

as you can see, the feature line is still the same. Strange!

Hmm, that is weird indeed... I think default in FreeBSD is now LLVM 6 but the assertion message claims to be from LLVM 4 (which my rustc is built on?).
The only I can think of that changed on my system is the system compiler version from 5 to 6.

johannes@jd:~ % rustc --print target-spec-json -Z unstable-options
{
  "arch": "x86_64",
  "cpu": "x86-64",
  "data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128",
  "dynamic-linking": true,
  "env": "",
  "exe-allocation-crate": "alloc_jemalloc",
  "executables": true,
  "has-rpath": true,
  "is-builtin": true,
  "is-like-openbsd": true,
  "linker-flavor": "gcc",
  "linker-is-gnu": true,
  "llvm-target": "x86_64-unknown-freebsd",
  "max-atomic-width": 64,
  "os": "freebsd",
  "position-independent-executables": true,
  "pre-link-args": {
    "gcc": [
      "-Wl,--as-needed",
      "-Wl,-z,noexecstack",
      "-m64"
    ]
  },
  "relro-level": "full",
  "stack-probes": true,
  "target-c-int-width": "32",
  "target-endian": "little",
  "target-family": "unix",
  "target-pointer-width": "64",
  "vendor": "unknown"
}
johannes@jd:~ % rustc -V
rustc 1.25.0-nightly
johannes@jd:~ % uname -a
FreeBSD jd 12.0-CURRENT FreeBSD 12.0-CURRENT e267af3884f(drm-v4.15)-dirty: Mon May 28 18:00:29 BST 2018     root@jd:/usr/obj/usr/src/amd64.amd64/sys/JD-NODEBUG  amd64

No features?

Only the default features :slight_smile: (rustc --print cfg)
Would you mind doing a rustup update? 1.25 is pretty old?

Ok, now I'm seriously confused. After switching toolchains (with rustup) around for a bit it suddenly builds - the old style.

I can't update, rust-docs is broken on FreeBSD :frowning:
Besides, I need this version for a big project I'm working and it's a self-contained toolchain in the project so it should work.

1 Like

If it happens next time, please try to provide as much information as possibel (gdb dump etc). This will help to hunt the bug down. But if it now works for you, that's great. Maybe somebody can explain this weird behavoir.