Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology)

[xiangzhangllvm]

Summary

This patch comes from H.J.'s https://github.com/hjl-tools/llvm-project/commit/2bd54ce7fa9e94fcd1118b948e14d1b6fc54dfd2

This patch fix the failed llvm unit tests which running on CET machine. (e.g. ExecutionEngine/MCJIT/MCJITTests)

The reason we enable IBT at "JIT compiled with CET" is mainly that: the JIT don't know the its caller program is CET enable or not.
If JIT's caller program is non-CET, it is no problem JIT generate CET code or not.
But if JIT's caller program is CET enabled, JIT must generate CET code or it will cause Control protection exceptions.

I have test the patch at llvm-unit-test and llvm-test-suite at CET machine. It passed.
and H.J. also test it at building and running VNCserver(Virtual Network Console), it works too.
(if not apply this patch, VNCserver will crash at CET machine.)

[LuoYuanke]

llvm/lib/Target/X86/X86TargetMachine.cpp

217

Can you add an test for it? Where to pass the JIT information to compiler?

llvm/lib/Target/X86/X86TargetMachine.h

34

What's the default value for IsJIT?

[xiangzhangllvm]

llvm/lib/Target/X86/X86TargetMachine.cpp

217

There is already JIT tests in llvm unit test at /llvm/unittests/ExecutionEngine/, and some examples at llvm/example.

This patch base on the build of llvm and libllvm.
To test this patch, we need to build llvm self source code with CET enabled(-fcf-protection).
JIT test mainly test runtime status (running fail/correct), not like lit test.
So current is enough to test it.

llvm/lib/Target/X86/X86TargetMachine.h

34

In the LVM code the default is false (X86TargetMachine.h), but actually There is no meaning of "default value" for IsJIT.
The value for IsJIT is decided by the if JIT is built/called in the program.
for example, if you use clang/llc to build your code, the value is false, otherwise if you use lli or directly call JIT with JIT API (e.g. MCJIT, ORCJIT) in your program the value is true.

JITBuilder will create the target for it, it will pass true for IsJIT to create X86TargetMachine object.

[xiangzhangllvm]

llvm/lib/Target/X86/X86TargetMachine.cpp

217

Yes, Usually we pass options information to JIT within the code self which JIT will handle.
But for CET, it different. because:
At runtime JIT don't know its caller program is CET enable or not.
So we do this:
If we build the LLVM code with CET enabled (e.g. use gcc -fcf-protection), the CET macro will pass to LLVM compiler. If this Macro is defined, we default enable IBT for JIT in this patch.

[efriedma]

llvm/lib/Target/X86/X86IndirectBranchTracking.cpp

124–128

This looks wrong; you can't get the address of a function with internal linkage, whether or not the JIT is involved.

That said, it's possible there something else going wrong here; the JIT defaults to the large code model, which is rarely used otherwise.

[xiangzhangllvm]

llvm/lib/Target/X86/X86IndirectBranchTracking.cpp

124–128

The isInternalLinkage will be checked in line 129, for isInternalLinkage, !MF.getFunction().hasLocalLinkage() will get true, and then we mainly check the indirect branch tracking requirement at line 130.

[efriedma]

llvm/lib/Target/X86/X86IndirectBranchTracking.cpp

124–128

The logic without your patch is, if a function has its address taken, or the symbol is visible to other modules, emit ENDBR, because it could be the target of an indirect call. Otherwise, we don't emit an ENDBR: all possible callers of the function call it directly, and direct calls will be lowered to a "call" instruction, which doesn't need ENDBR.

Your patch overrides that logic and says, if we're compiling for a JIT target, emit ENDBR anyway. That doesn't make sense: the control flow rules are the same whether or not the compiled ELF file is written to disk.

[xiangzhangllvm]

llvm/lib/Target/X86/X86IndirectBranchTracking.cpp

124–128

Make sense! here should not check isJIT, Thank you very much!

[hjl.tools]

llvm/lib/Target/X86/X86IndirectBranchTracking.cpp

124–128

As

https://bugs.llvm.org/show_bug.cgi?id=45182

shows, MF.getFunction().hasAddressTaken() isn't sufficient for IBT. Assembly dump has
landing pad address taken, but MF.getFunction().hasAddressTaken() returns false. Without

if ((isJITwithCET ||
     MF.getFunction().hasAddressTaken() ||
     !MF.getFunction().hasLocalLinkage()) &&
    !MF.getFunction().doesNoCfCheck()) {
  auto MBB = MF.begin();
  Changed |= addENDBR(*MBB, MBB->begin());
}

VNC crashes. A jitted function has to be referenced. There are 3 ways to reference a function

1. Direct call.
2. Indirect call.
3. Take address.

2 and 3 are mostly likely in x86 jitted codes.

[efriedma]

llvm/lib/Target/X86/X86IndirectBranchTracking.cpp

124–128

I'm not saying there isn't a bug somewhere. I'm just saying this isn't the right way to write whatever check is necessary.

This code is checking whether all calls must be direct at the IR level. If all calls are direct at the IR level, they must all be part of the module we're currently JIT'ing. The code that lowers calls does not check IsJIT. Therefore, the code here also shouldn't use IsJIT.

LIke I said earlier, I suspect the issue is related to the large code model.

[hjl.tools]

llvm/lib/Target/X86/X86IndirectBranchTracking.cpp

124–128

I believe the same problem also exists for ia32 which doesn't have large code model.

[xiangzhangllvm]

llvm/lib/Target/X86/X86IndirectBranchTracking.cpp

149–152

landing pad address taken have been add to here now. But still need to check some other un-normal exception model, e.g SjLj exception model.

[hjl.tools]

Please take a look at

https://gitlab.freedesktop.org/mesa/mesa

to see how LLVM JIT is used and extract a testcase from it.

[xiangzhangllvm]

In D76900#1948503, @hjl.tools wrote:

Please take a look at

https://gitlab.freedesktop.org/mesa/mesa

to see how LLVM JIT is used and extract a testcase from it.

1, Does it in your commits? I find 2 your commits without the JIT tests.

2, Do you mean here we need add JIT test for this patch ? Check endbr in JIT generated code?

[hjl.tools]

In D76900#1948978, @xiangzhangllvm wrote:

In D76900#1948503, @hjl.tools wrote:

Please take a look at

https://gitlab.freedesktop.org/mesa/mesa

to see how LLVM JIT is used and extract a testcase from it.

1, Does it in your commits? I find 2 your commits without the JIT tests.

This:

https://bugs.llvm.org/show_bug.cgi?id=45013

is all I have.

2, Do you mean here we need add JIT test for this patch ? Check endbr in JIT generated code?

My changes fixed the VNC crash. But there is no testcase to show why my patches are needed.

[xiangzhangllvm]

In D76900#1948990, @hjl.tools wrote:

2, Do you mean here we need add JIT test for this patch ? Check endbr in JIT generated code?

My changes fixed the VNC crash. But there is no testcase to show why my patches are needed.

Your tests failed on CET machine
and the existing llvm unit tests also failed the on the CET machine
They are the same reason for lack of endbr* in JIT.
So I think the existing llvm unit tests is enough for this patch.

[hjl.tools]

In D76900#1949020, @xiangzhangllvm wrote:

In D76900#1948990, @hjl.tools wrote:

2, Do you mean here we need add JIT test for this patch ? Check endbr in JIT generated code?

My changes fixed the VNC crash. But there is no testcase to show why my patches are needed.

Your tests failed on CET machine
and the existing llvm unit tests also failed the on the CET machine
They are the same reason for lack of endbr* in JIT.
So I think the existing llvm unit tests is enough for this patch.

My patch has 2 parts:

1. Check CET in JIT instead of checking -fcf-protection-branch.
2. Always insert ENDBR in JIT with CET.

I think the first one alone will fix LLVM JIT tests on CET machine. But
it won't fix VNC. The second one is needed for VNC. I don't have
a testcase for the second patch.

[xiangzhangllvm]

If "1 Check CET in JIT instead of checking -fcf-protection-branch" can't let VNC passed. The crash must happen at "Take address of a internal function."

This is not a IBT problem only for JIT, but also the static llvm compiler, e.g. llc.
And it may unable to track these calling through function address, because these function address may be calculated out in runtime or written in a big table.

and it really seems some disaccord/unbeautiful to add "isJITwithCET" for the old patch.

I think we should change the condition from

if ((**isJITwithCET ||**
     MF.getFunction().hasAddressTaken() ||
     !MF.getFunction().hasLocalLinkage()) &&
    !MF.getFunction().doesNoCfCheck()) {
  auto MBB = MF.begin();
  Changed |= addENDBR(*MBB, MBB->begin());
}

to

if (!MF.getFunction().doesNoCfCheck()) {
  auto MBB = MF.begin();
  Changed |= addENDBR(*MBB, MBB->begin());
}

[hjl.tools]

In D76900#1949402, @xiangzhangllvm wrote:

If "1 Check CET in JIT instead of checking -fcf-protection-branch" can't let VNC passed. The crash must happen at "Take address of a internal function."

This is not a IBT problem only for JIT, but also the static llvm compiler, e.g. llc.
And it may unable to track these calling through function address, because these function address may be calculated out in runtime or written in a big table.

It will be very nice to extract a testcase from Mesa. This bug may be harmless without CET,
but it is fatal with CET.

[xiangzhangllvm]

In D76900#1949660, @hjl.tools wrote:

It will be very nice to extract a testcase from Mesa. This bug may be harmless without CET,
but it is fatal with CET.

OK, I'll try to extract a testcase from Mesa.

[xiangzhangllvm]

Let me first update the patch self.

[efriedma]

Filed https://bugs.llvm.org/show_bug.cgi?id=45364 .

[xiangzhangllvm]

In D76900#1950977, @efriedma wrote:

Filed https://bugs.llvm.org/show_bug.cgi?id=45364 .

Hi, efriedma, It passed. Do you want to add this file as test? The test indirect-branch-tracking.ll have already test internal function.

[efriedma]

Yes, please add that as a test.

The current patch works, but it's emitting endbrs for small code model examples where they shouldn't be necessary. Maybe someone else can chime in on how important that is in practice.

[xiangzhangllvm]

In D76900#1951500, @efriedma wrote:

Yes, please add that as a test.

The current patch works, but it's emitting endbrs for small code model examples where they shouldn't be necessary. Maybe someone else can chime in on how important that is in practice.

OK, It is really hard to check if a internal function will be indirectly accessed or not, here we can first "sync" with GCC.

[xiangzhangllvm]

@efriedma Put the https://bugs.llvm.org/show_bug.cgi?id=45364 test into X86/indirect-branch-tracking.ll @test5

[hjl.tools]

In D76900#1951695, @xiangzhangllvm wrote:

@efriedma Put the https://bugs.llvm.org/show_bug.cgi?id=45364 test into X86/indirect-branch-tracking.ll @test5

Please take a look at

https://github.com/hjl-tools/llvm-project/commit/6a85ba472143c91e5686e1f0faf7fea7b4f0e350

It should fix both

https://bugs.llvm.org/show_bug.cgi?id=45013
https://bugs.llvm.org/show_bug.cgi?id=45364

[xiangzhangllvm]

I find your patch will not deal with internal function.
I tested GCC, It really will generate endbr for static functions:

gcc version 9.3.1 20200317 (Red Hat 9.3.1-1) (GCC)
 [xiangzh1@gnu-tgl-1 ~/tmp]$cat t.c
extern int foo2(int a);

extern int foo2(int a)
{
  return a*6;
}

static int foo3(int a)
{
  return a*7;
}

int foo(int a){
//  int (*pf3)(int) = foo;
//  int b = foo2(a) +foo3(a) + pf3(a);
  int b = foo2(a) +foo3(a);
  return b;
}
 [xiangzh1@gnu-tgl-1 ~/tmp]$
[xiangzh1@gnu-tgl-1 ~/tmp]$gcc -fcf-protection t.c -S -o t.s
[xiangzh1@gnu-tgl-1 ~/tmp]$cat t.s
        .file   "t.c"
        .text
        .globl  foo2
        .type   foo2, @function
foo2:
.LFB0:
        .cfi_startproc
        endbr64
        pushq   %rbp
        ....

        .size   foo2, .-foo2
        .type   foo3, @function
foo3:
.LFB1:
        .cfi_startproc
        endbr64
        pushq   %rbp
        .cfi_def_cfa_offset 16
      ....

[hjl.tools]

In D76900#1953937, @xiangzhangllvm wrote:

I find your patch will not deal with internal function.
I tested GCC, It really will generate endbr for static functions:

gcc version 9.3.1 20200317 (Red Hat 9.3.1-1) (GCC)
 [xiangzh1@gnu-tgl-1 ~/tmp]$cat t.c
extern int foo2(int a);

extern int foo2(int a)
{
  return a*6;
}

static int foo3(int a)
{
  return a*7;
}

int foo(int a){
//  int (*pf3)(int) = foo;
//  int b = foo2(a) +foo3(a) + pf3(a);
  int b = foo2(a) +foo3(a);
  return b;
}
 [xiangzh1@gnu-tgl-1 ~/tmp]$
[xiangzh1@gnu-tgl-1 ~/tmp]$gcc -fcf-protection t.c -S -o t.s

You need -O2 to turn on optimization:

[hjl@gnu-cfl-2 tmp]$ cat y.c
__attribute__ ((noclone, noinline))
static int foo3(int a)
{
  return a*7;
}

extern int b;

void
foo(int a)
{
  b = foo3(a);
}
[hjl@gnu-cfl-2 tmp]$ gcc  -fcf-protection -O2 -S y.c
[hjl@gnu-cfl-2 tmp]$ cat y.s
	.file	"y.c"
	.text
	.p2align 4
	.type	foo3, @function
foo3:
.LFB0:
	.cfi_startproc
	leal	0(,%rdi,8), %eax
	subl	%edi, %eax
	ret
	.cfi_endproc
.LFE0:
	.size	foo3, .-foo3
	.p2align 4
	.globl	foo
	.type	foo, @function
foo:
.LFB1:
	.cfi_startproc
	endbr64
	call	foo3
	movl	%eax, b(%rip)
	ret
	.cfi_endproc
.LFE1:
	.size	foo, .-foo
	.ident	"GCC: (GNU) 9.3.1 20200317 (Red Hat 9.3.1-1)"
	.section	.note.GNU-stack,"",@progbits
	.section	.note.gnu.property,"a"
	.align 8
	.long	 1f - 0f
	.long	 4f - 1f
	.long	 5
0:
	.string	 "GNU"
1:
	.align 8
	.long	 0xc0000002
	.long	 3f - 2f
2:
	.long	 0x3
3:
	.align 8
4:
[hjl@gnu-cfl-2 tmp]$

[xiangzhangllvm]

1. Sync with HJ's large code changes in https://github.com/hjl-tools/llvm-project/commit/6a85ba472143c91e5686e1f0faf7fea7b4f0e350
2. Add Eli's test in https://bugs.llvm.org/show_bug.cgi?id=45364 to llc test and JIT test.

For Large code model:
The compiler is required to use the movabs instruction, as in the medium code model, even for dealing with addresses inside the text section.
Additionally, indirect branches are needed when branching to addresses whose offset from the current instruction pointer is unknown.

[hjl.tools]

In D76900#1956612, @xiangzhangllvm wrote:

1. Sync with HJ's large code changes in https://github.com/hjl-tools/llvm-project/commit/6a85ba472143c91e5686e1f0faf7fea7b4f0e350
2. Add Eli's test in https://bugs.llvm.org/show_bug.cgi?id=45364 to llc test and JIT test.

For Large code model:
The compiler is required to use the movabs instruction, as in the medium code model, even for dealing with addresses inside the text section.
Additionally, indirect branches are needed when branching to addresses whose offset from the current instruction pointer is unknown.

It looks very confusing. Can you create a diff against master branch, not your last change?

[hjl.tools]

In D76900#1957289, @hjl.tools wrote:

It looks very confusing. Can you create a diff against master branch, not your last change?

Never mind. I couldn't read :-).

llvm/test/ExecutionEngine/MCJIT/cet-code-model-lager.ll

4

What does this test check? Does it fail without the fix?

[xiangzhangllvm]

In D76900#1957289, @hjl.tools wrote:

It looks very confusing. Can you create a diff against master branch, not your last change?

Never mind. I couldn't read :-).

This is the whole diff against the master. :-)

llvm/test/ExecutionEngine/MCJIT/cet-code-model-lager.ll

4

lli will call JIT to compile this code. This test is same with Eli's large code model test.
This test will run fail if CET enabled JIT not generate endbr for the following 3 functions' entry in CET machine.

[hjl.tools]

Look good to me.

[LuoYuanke]

llvm/test/ExecutionEngine/MCJIT/cet-code-model-lager.ll

2

It seems the same test case to the previous one. Can we merge the 2 test case into one and use different run command?

; RUN: llc -mtriple=x86_64-unknown-unknown -code-model=large < %s | FileCheck %s
; RUN: %lli -code-model=large %s > /dev/null

4

lli can check CET even on machine without CET enabled?

[xiangzhangllvm]

llvm/test/ExecutionEngine/MCJIT/cet-code-model-lager.ll

4

lli can only check CET in CET enabled machine.

The llvm/test/CodeGen/X86/indirect-branch-tracking-cm-lager.ll test will staticly check the endbr in CET/nonCET machines.

[LuoYuanke]

LGTM

llvm/lib/Target/X86/X86IndirectBranchTracking.cpp

 // instruction.
 // The ENDBR instructions have a NOP encoding and as such are ignored in
 // targets that do not support CET IBT mechanism.
 //===----------------------------------------------------------------------===//
 
 #include "X86.h"
 #include "X86InstrInfo.h"
 #include "X86Subtarget.h"
+#include "X86TargetMachine.h"
 #include "llvm/ADT/Statistic.h"
 #include "llvm/CodeGen/MachineFunctionPass.h"
 #include "llvm/CodeGen/MachineInstrBuilder.h"
 #include "llvm/CodeGen/MachineModuleInfo.h"
 
 using namespace llvm;
 
 #define DEBUG_TYPE "x86-indirect-branch-tracking"

 }
 
 bool X86IndirectBranchTrackingPass::runOnMachineFunction(MachineFunction &MF) {
   const X86Subtarget &SubTarget = MF.getSubtarget<X86Subtarget>();
 
   // Check that the cf-protection-branch is enabled.
   Metadata *isCFProtectionSupported =
       MF.getMMI().getModule()->getModuleFlag("cf-protection-branch");
-  if (!isCFProtectionSupported && !IndirectBranchTracking)
+  // NB: We need to enable IBT in jitted code if JIT compiler is CET
+  // enabled.
+  const X86TargetMachine *TM =
+      static_cast<const X86TargetMachine *>(&MF.getTarget());
+#ifdef __CET__
+  bool isJITwithCET = TM->isJIT();
+#else
+  bool isJITwithCET = false;
+#endif
+  if (!isCFProtectionSupported && !IndirectBranchTracking && !isJITwithCET)
     return false;
 
   // True if the current MF was changed and false otherwise.
   bool Changed = false;
 
   TII = SubTarget.getInstrInfo();
   EndbrOpcode = SubTarget.is64Bit() ? X86::ENDBR64 : X86::ENDBR32;
 
-  // Non-internal function or function whose address was taken, can be
-  // accessed through indirect calls. Mark the first BB with ENDBR instruction
-  // unless nocf_check attribute is used.
-  if ((MF.getFunction().hasAddressTaken() ||
+  // Large code model, non-internal function or function whose address
+  // was taken, can be accessed through indirect calls. Mark the first
+  // BB with ENDBR instruction unless nocf_check attribute is used.
+  if ((TM->getCodeModel() == CodeModel::Large ||
+       MF.getFunction().hasAddressTaken() ||
        !MF.getFunction().hasLocalLinkage()) &&
       !MF.getFunction().doesNoCfCheck()) {
     auto MBB = MF.begin();
     Changed |= addENDBR(*MBB, MBB->begin());
   }
 
   for (auto &MBB : MF) {
     // Find all basic blocks that their address was taken (for example
     // in the case of indirect jump) and add ENDBR instruction.
     if (MBB.hasAddressTaken())
       Changed |= addENDBR(MBB, MBB.begin());
 
     // Exception handle may indirectly jump to catch pad, So we should add
     // ENDBR before catch pad instructions.
     bool EHPadIBTNeeded = MBB.isEHPad();
 
     for (MachineBasicBlock::iterator I = MBB.begin(); I != MBB.end(); ++I) {
       if (I->isCall() && IsCallReturnTwice(I->getOperand(0)))
         Changed |= addENDBR(MBB, std::next(I));
 
       if (EHPadIBTNeeded && I->isEHLabel()) {
-          Changed |= addENDBR(MBB, std::next(I));
-          EHPadIBTNeeded = false;
       }
     }
   }
   return Changed;
 }

llvm/lib/Target/X86/X86TargetMachine.h

 class StringRef;
 class X86Subtarget;
 class X86RegisterBankInfo;
 class TargetTransformInfo;
 
 class X86TargetMachine final : public LLVMTargetMachine {
   std::unique_ptr<TargetLoweringObjectFile> TLOF;
   mutable StringMap<std::unique_ptr<X86Subtarget>> SubtargetMap;
+  // True if this is used in JIT.
+  bool IsJIT;
 
 public:
   X86TargetMachine(const Target &T, const Triple &TT, StringRef CPU,
                    StringRef FS, const TargetOptions &Options,
                    Optional<Reloc::Model> RM, Optional<CodeModel::Model> CM,
                    CodeGenOpt::Level OL, bool JIT);
   ~X86TargetMachine() override;
 
   const X86Subtarget *getSubtargetImpl(const Function &F) const override;
   // DO NOT IMPLEMENT: There is no such thing as a valid default subtarget,
   // subtargets are per-function entities based on the target-specific
   // attributes of each function.
   const X86Subtarget *getSubtargetImpl() const = delete;
 
   TargetTransformInfo getTargetTransformInfo(const Function &F) override;
 
   // Set up the pass pipeline.
   TargetPassConfig *createPassConfig(PassManagerBase &PM) override;
 
   TargetLoweringObjectFile *getObjFileLowering() const override {
     return TLOF.get();
   }
+
+  bool isJIT() const { return IsJIT; }
 };
 
 } // end namespace llvm
 
 #endif // LLVM_LIB_TARGET_X86_X86TARGETMACHINE_H

llvm/lib/Target/X86/X86TargetMachine.cpp

X86TargetMachine::X86TargetMachine(const Target &T, const Triple &TT,
                                    Optional<Reloc::Model> RM,
                                    Optional<CodeModel::Model> CM,
                                    CodeGenOpt::Level OL, bool JIT)
     : LLVMTargetMachine(
           T, computeDataLayout(TT), TT, CPU, FS, Options,
           getEffectiveRelocModel(TT, JIT, RM),
           getEffectiveX86CodeModel(CM, JIT, TT.getArch() == Triple::x86_64),
           OL),
-      TLOF(createTLOF(getTargetTriple())) {
+      TLOF(createTLOF(getTargetTriple())), IsJIT(JIT) {
   // On PS4, the "return address" of a 'noreturn' call must still be within
   // the calling function, and TrapUnreachable is an easy way to get that.
   if (TT.isPS4() || TT.isOSBinFormatMachO()) {
     this->Options.TrapUnreachable = true;
     this->Options.NoTrapAfterNoreturn = TT.isOSBinFormatMachO();
   }
 
   setMachineOutliner(true);

llvm/test/CodeGen/X86/indirect-branch-tracking-cm-lager.ll

+; RUN: llc -mtriple=x86_64-unknown-unknown -code-model=large < %s | FileCheck %s
+
+; In large code model indirect branches are needed when branching to addresses
+; whose offset from the current instruction pointer is unknown.
+;CHECK-COUNT-3: endbr
+
+@a = dso_local local_unnamed_addr global i32 1, align 4
+
+; Function Attrs: nofree noinline norecurse nounwind uwtable writeonly
+define dso_local void @ext() local_unnamed_addr #0 {
+entry:
+  store i32 0, i32* @a, align 4
+  ret void
+}
+
+; Function Attrs: nofree norecurse nounwind uwtable
+define dso_local i32 @main() local_unnamed_addr #1 {
+entry:
+  tail call fastcc void @foo()
+  %0 = load i32, i32* @a, align 4
+  ret i32 %0
+}
+
+; Function Attrs: nofree noinline norecurse nounwind uwtable writeonly
+define internal fastcc void @foo() unnamed_addr #0 {
+entry:
+  tail call void @ext()
+  ret void
+}
+
+!llvm.module.flags = !{!0, !1, !2, !3}
+
+!0 = !{i32 1, !"wchar_size", i32 4}
+!1 = !{i32 4, !"cf-protection-return", i32 1}
+!2 = !{i32 4, !"cf-protection-branch", i32 1}
+!3 = !{i32 1, !"Code Model", i32 4}

llvm/test/ExecutionEngine/MCJIT/cet-code-model-lager.ll

+; RUN: %lli -code-model=large %s > /dev/null
+target triple = "x86_64-unknown-linux-gnu"
+
+@a = dso_local local_unnamed_addr global i32 1, align 4
+
+; Function Attrs: nofree noinline norecurse nounwind uwtable writeonly
+define dso_local void @ext() local_unnamed_addr #0 {
+entry:
+  store i32 0, i32* @a, align 4
+  ret void
+}
+
+; Function Attrs: nofree norecurse nounwind uwtable
+define dso_local i32 @main() local_unnamed_addr #1 {
+entry:
+  tail call fastcc void @foo()
+  %0 = load i32, i32* @a, align 4
+  ret i32 %0
+}
+
+; Function Attrs: nofree noinline norecurse nounwind uwtable writeonly
+define internal fastcc void @foo() unnamed_addr #0 {
+entry:
+  tail call void @ext()
+  ret void
+}
+
+!llvm.module.flags = !{!0, !1, !2, !3}
+
+!0 = !{i32 1, !"wchar_size", i32 4}
+!1 = !{i32 4, !"cf-protection-return", i32 1}
+!2 = !{i32 4, !"cf-protection-branch", i32 1}
+!3 = !{i32 1, !"Code Model", i32 4}