Custom target: data-layout changed

[phil-opp]

I use a custom target file to build code for ARM. I copied the file from somewhere and it worked without problems. But now, after an update to the latest nightly, the build fails with a strange LLVM error:

rustc:
/buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/llvm/lib/CodeGen/MachineFunction.cpp:108:
llvm::MachineFunction::MachineFunction(const llvm::Function*, const
llvm::TargetMachine&, unsigned int, llvm::MachineModuleInfo&): Assertion
`TM.isCompatibleDataLayout(getDataLayout()) && "Can't create a
MachineFunction using a Module with a " "Target-incompatible DataLayout
attached\n"' failed.

I don't understand any of this but it seems like the data-layout is suddently “Target-incompatible”. My target json looks like this:

{
    "arch": "arm",
    "cpu": "cortex-m4",
    "data-layout": "e-m:e-p:32:32-i1:8:32-i8:8:32-i16:16:32-i64:64-v128:64:128-a:0:32-n32-S64",
    "disable-redzone": true,
    "executables": true,
    "llvm-target": "thumbv7em-none-eabihf",
    "morestack": false,
    "os": "none",
    "relocation-model": "static",
    "target-endian": "little",
    "target-pointer-width": "32",
    "no-compiler-rt": true,
    "pre-link-args": [
        "-mcpu=cortex-m7", "-mthumb",
        "-Tlayout.ld"
    ],
    "post-link-args": [
        "-lm", "-lgcc", "-lnosys"
    ]
}

Removing the data-layout line fixes it and everything works again. So I think this issue is already solved :). I opened it anyway as I wasn't sure if this was intended (and maybe it helps someone).

If someone wants to investigate: The travis builds for nightly libcore started failing on rustc 1.8.0-nightly (9a07087bc 2016-01-30).

[alexcrichton]

This might be related to how LLVM was upgraded recently?

[dpc]

This also happend to me on travis where LLVM is in version 3.4. https://travis-ci.org/dpc/titanos/jobs/106659993 when compiling for ARMv8 aarch64 target. It works (well, fails but in unrelated way) on my local machine where llvm is in version 3.7.

Removing data-layout also helped. Is it OK to skip this line?

[tari]

I'm seeing this issue as well, with JSON targets for x86_64 that use a datalayout copied from rustc's x86_64-unknown-linux-gnu target. The LLVM assert does not trigger on the same code when using the built-in linux target.

Trying some nightlies, I still see this crash with the build from January 30 (303892e) and all subsequent ones. Testing further back will require downgrading the copy of libcore I'm building.

---

Removing datalayout from the target specification prevents the failure, but it's not clear to me what the implications of that are; either rustc or LLVM is quietly choosing a default, where if it's the former everything should be fine and if it's the latter there's a chance of hard-to-debug miscompilation.

[thejpster]

So I tried 1.10.0-nightly (b5ba592 2016-04-21) with my bare metal ARM project and it says it "failed to run rustc to learn about target-specific information". In verbose mode it complained that "Field data-layout in target specification is required".

Oh, well, I'll put it back in then. But if you put it back in, you still get this issue.

I note the O/Ps Travis build is also broken, so it's probably not just me.

[phil-opp]

The data-layout field was made manditory again in #32939. The correct values for the built-in target triples can be found in the commit diff. The field layout is specified in the LLVM documentation.

I note the O/Ps Travis build is also broken

Thanks for the hint :).

[japaric]

FWIW, I have found two ways to make llvm generate a (seemingly) correct data layout for you:

Using clang

$ touch empty.c
$ clang --target=thumbv7m-none-eabi -S -emit-llvm empty.c -o empty.ll
$ head empty.ll
; ModuleID = 'empty.c'
target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "thumbv7m-none--eabi"

Where thumbv7m-none-eabi is the llvm-target field in your target specification file. And clang should be recent-ish, probably 3.8+ or you'll get the old, longer data-layout format.

Using an old rustc

The other way is to use a rustc nightly from 2016-04-20 or older:

$ cat empty.rs
#![feature(no_core)]
#![crate_type = "rlib"]
#![no_core]

$ rustup run nightly-2016-04-20 rustc --target stm32f100 --emit=llvm-ir empty.rs
$ head empty.ll
; ModuleID = 'empty.0.rs'
target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "thumbv7m-none--eabi"

Where stm32f100 is your custom target, your target specification file must be in $PWD.

[thejpster]

I tried the clang method with clang-3.5, but the value it produced did not work. On a whim, I added a:0:32 and then it compiled OK. Haven't actually tested the binary though.

[pravic]

The other way is to use a rustc nightly from 2016-04-20 or older

You can use stable as well, I guess:

$ touch empty.rs
$ rustup run stable-i686   rustc --emit=llvm-ir --crate-type rlib -o x86.ll empty.rs
$ rustup run stable-x86_64 rustc --emit=llvm-ir --crate-type rlib -o x64.ll empty.rs

[Mark-Simulacrum]

Is there something in particular that is left to do here? I can't quite see any "bug" in this issue, though it would be great to document what @japaric says about getting a seemingly correct data layout somewhere.

[alexcrichton]

AFAIK there's not much left to do here, so closing.