[LLVMdev] Function calls only being JIT'd once by Kaleidoscope with MCJIT?

[Per Mildner]

On Apr 22, 2015, at 10:47 PM, Lang Hames <lhames at gmail.com> wrote:

> Hi Dave, Per,
> 
> Dave - The issue Eric raised was with chapters 7 and 8. I've fixed that in 235541.
> 
> Per - It's not obvious to my why Chapter 4 should need RTTI. What error are you seeing?

The Chapter 4 code has a class, HelpingMemoryManager, that inherits from the LLVM class SectionMemoryManager.

It was my understanding that LLBM is built without RTTI by default, but clang++ enables RTTI by default, and that it is not possible for code using RTTI (toy.cpp) to inherit from a class compiled without RTTI.

Transcript:

bash$ uname -a
Darwin dhcpu02.sics.se 12.6.0 Darwin Kernel Version 12.6.0: Wed Mar 18 16:23:48 PDT 2015; root:xnu-2050.48.19~1/RELEASE_X86_64 x86_64
bash$ /usr/bin/clang++ --version
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.6.0
Thread model: posix
bash$ llvm-config --version
3.7.0svn
bash$ llvm-config --cxxflags --ldflags --system-libs --libs core mcjit native
-I/Users/perm/bin/llvm-git/include  -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -std=c++11 -fcolor-diagnostics -g  -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-L/Users/perm/bin/llvm-git/lib -Wl,-search_paths_first -Wl,-headerpad_max_install_names
-lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMCodeGen -lLLVMScalarOpts -lLLVMProfileData -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMX86Desc -lLLVMMCDisassembler -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT -lLLVMTarget -lLLVMAnalysis -lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMObject -lLLVMMCParser -lLLVMBitReader -lLLVMMC -lLLVMCore -lLLVMSupport
-lcurses -lpthread -lz -lm
bash$ /usr/bin/clang++ -g toy4.cpp `llvm-config --cxxflags --ldflags --system-libs --libs core mcjit native` -O3 -o toy4
Undefined symbols for architecture x86_64:
  "typeinfo for llvm::SectionMemoryManager", referenced from:
      typeinfo for HelpingMemoryManager in toy4-e7e3d4.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
bash$ /usr/bin/clang++ -fno-rtti -g toy4.cpp `llvm-config --cxxflags --ldflags --system-libs --libs core mcjit native` -O3 -o toy4
bash$ ./toy4
ready> 


> 
> Cheers,
> Lang.
> 
> On Tue, Apr 21, 2015 at 3:11 PM, David Blaikie <dblaikie at gmail.com> wrote:
> On Tue, Apr 21, 2015 at 3:07 PM, Lang Hames <lhames at gmail.com> wrote:
> > No progress since Charlie last looked at it.
> 
> Sorry, I meant to refer to the issue Per Mildner mentioned regarding
> the tutorials not building due to RTTI - which I recall discussing
> with you & Eric, but don't know what came of it.
> 
> > As Per suggested, it may be
> > worth adding an explicit #error, or at least a comment, noting that the
> > later examples are broken.
> >
> > Going forward, I see three options:
> >
> > (1) Remove the old tutorials entirely, and encourage people to check out the
> > MCJIT and Orc versions.
> > (2) Build an Orc-based stack that approximates the behavior of the Old JIT
> > (which the old tutorials assume).
> > (3) Rewrite the old tutorial to natively use the new APIs.
> >
> > I much prefer the third option. The first option misses out on a lot of
> > language/API discussion that's contained in the later chapters of the old
> > tutorials. The second option replicates a JIT stack that wouldn't be useful
> > for most clients.
> >
> > If we were going to pursue option three, the simple JIT from the Orc/initial
> > tutorial seems like a good starting point to re-write the old tutorials.
> > Then we'd have an interesting bifurcation part way through the tutorial
> > series: Go one way and add new language features on top of the simple JIT,
> > or go another and add features to the JIT while keeping the language steady.
> > Cross-polination of the two branches (new JIT features + new language
> > features) could be handled in future tutorials, or left as an exercise for
> > the reader.
> >
> > The tricky part, as usual, is finding the time to do this.
> > Volunteers/patches welcome. :)
> >
> > Cheers,
> > Lang.
> >
> >
> > On Tue, Apr 21, 2015 at 9:16 AM, David Blaikie <dblaikie at gmail.com> wrote:
> >>
> >>
> >>
> >> On Tue, Apr 21, 2015 at 7:26 AM, Per Mildner <Per.Mildner at sics.se> wrote:
> >>>
> >>> Charlie Turner <charlesturner7c5 <at> gmail.com> writes:
> >>>
> >>> > I was planning on committing these changes with the corresponding
> >>> > changes to the Kaleidoscope tutorial walk-through. Might be a bit of a
> >>> > surprise to have no explanation of what MCJITHelper and friends is
> >>> > doing.
> >>> >
> >>> > I'll try and make time to prepare some patches along these lines, as
> >>> > well as updating future chapters with the same fix.
> >>> >
> >>> > Thanks for taking a look :)
> >>>
> >>>
> >>> Any progress on fixing the tutorial?
> >>>
> >>> I am about to dive into LLVM and after some hair-pulling found that the
> >>> Kaleidoscope tutorials (from part 5 onwards), are broken.
> >>>
> >>> Obviously this is not a good first impression.
> >>>
> >>> (even a note in the source code, #error "currently does not work", would
> >>> be
> >>> a huge improvement, since it would avoid a lot of wasted time for the
> >>> beginner.)
> >>>
> >>> PS. On OS X 10.8.5, the compile command for part 4 of the tutorial needs
> >>> -fno-rtti, presumably because the code now inherits from a LLVM class.
> >>
> >>
> >> Lang - recall what the state is here?
> >>
> >>>
> >>>
> >>> Regards,
> >>>
> >>> Per Mildner
> >>>
> >>>
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>
> >>
> >
> 

Per Mildner
Per.Mildner at sics.se