Build fails on Arch Linux

[Vtec234]

Hello, I had some trouble building fcd on Arch Linux with LLVM and Clang 3.8 installed. Firstly, the Makefile contains LLVM_VERSION_SUFFIX = -3.7 on line 6. Since I only have 3.8 installed, and do not have the binaries aliased with the version number, ie things such as llvm-config-3.8 simply do not exist, I set it to LLVM_VERSION_SUFFIX = (null string), which made it work. However, running make then produces an error:

make -f /home/wojciech/Downloads/fcd/Makefile.sub -C /home/wojciech/Downloads/fcd/fcd/
make[1]: Entering directory '/home/wojciech/Downloads/fcd/fcd'
clang++ -isystem /usr/include -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong  -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -std=c++11 -ffunction-sections -fdata-sections -O3 -DNDEBUG  -fno-exceptions -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/home/wojciech/Downloads/fcd/fcd/ -I/home/wojciech/Downloads/fcd/fcd/ast/ -I/home/wojciech/Downloads/fcd/fcd/callconv/ -I/home/wojciech/Downloads/fcd/fcd/codegen/ -I/home/wojciech/Downloads/fcd/fcd/cpu/ -I/home/wojciech/Downloads/fcd/fcd/executables/ -I/home/wojciech/Downloads/fcd/fcd/llvm-gvn-rewrite/ -I/home/wojciech/Downloads/fcd/fcd/python/ -isystem /home/wojciech/Downloads/fcd/build/includes -isystem /usr/include/capstone -Wall -Wunreachable-code -Wempty-body -Wconditional-uninitialized -Werror=conversion -Wno-error=sign-conversion -Winvalid-offsetof -Wnewline-eof --std=gnu++14 -fno-rtti -c -o /home/wojciech/Downloads/fcd/build/pass_regaa.o pass_regaa.cpp
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [-Wunknown-warning-option]
In file included from pass_regaa.cpp:27:
In file included from /home/wojciech/Downloads/fcd/fcd/metadata.h:26:
In file included from /home/wojciech/Downloads/fcd/fcd/callconv/params_registry.h:26:
In file included from /home/wojciech/Downloads/fcd/fcd/targetinfo.h:28:
In file included from /usr/include/llvm/IR/DataLayout.h:23:
In file included from /usr/include/llvm/ADT/DenseMap.h:17:
In file included from /usr/include/llvm/ADT/DenseMapInfo.h:17:
In file included from /usr/include/llvm/ADT/ArrayRef.h:13:
In file included from /usr/include/llvm/ADT/Hashing.h:48:
In file included from /usr/include/llvm/Support/DataTypes.h:35:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/cmath:45:15: fatal error: 'math.h' file not found
#include_next <math.h>
          ^
1 warning and 1 error generated.
/home/wojciech/Downloads/fcd/Makefile.sub:12: recipe for target '/home/wojciech/Downloads/fcd/build/pass_regaa.o' failed
make[1]: *** [/home/wojciech/Downloads/fcd/build/pass_regaa.o] Error 1
make[1]: Leaving directory '/home/wojciech/Downloads/fcd/fcd'
Makefile:44: recipe for target '/home/wojciech/Downloads/fcd/fcd/' failed
make: *** [/home/wojciech/Downloads/fcd/fcd/] Error 2

At this point I gave up on the Makefile and tried CMake like this:

mkdir build
cd build
cmake ..
make

The CMakeLists.txt file is unfortunately also erroneous, but I managed to make it build with two fixes. First, on line 41, I had to add -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS, since without that this happens:

[  4%] Generating bindings.cpp
In file included from /usr/include/llvm-c/Core.h:18:
In file included from /usr/include/llvm-c/ErrorHandling.h:17:
In file included from /usr/include/llvm-c/Types.h:17:
/usr/include/llvm/Support/DataTypes.h:57:3: error: "Must #define __STDC_LIMIT_MACROS before #including Support/DataTypes.h"
# error "Must #define __STDC_LIMIT_MACROS before #including Support/DataTypes.h"
  ^
/usr/include/llvm/Support/DataTypes.h:61:3: error: "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h"
#17  error "Must #define __STDC_CONSTANT_MACROS before " \

Then, on the same line (41), python has to be switched to python2.7, since Python 3 is the default on my system. Otherwise the script python/bindings.py fails with

File "/home/wojciech/Downloads/fcd/fcd/python/bindings.py", line 143
    raise ValueError, "callback type %s" % cFunction.returnType

The above two changes make it build, but I won't put them in a PR since I'm unsure whether they actually produce a correct binary - running what I built on a braindead-simple C++ app from this source with clang++ -g main.cpp -o ack2:

int main(int argc, char** argv) {
    int a = 20;
    int c = a + 4;

    return 0;
}

like ./fcd ack2 results in a segfault :/

[fay59]

For make: have you also tried just make in the directory with the Makefile? Makefile.sub is called by the Makefile and it depends on a number of variables defined there. (I don't know if this is usual or not, this is essentially the first and only non-trivial project that I tried to use make for.) EDIT oh wait I didn't read that right.

For CMake: the two -D parameters should have been obtained from llvm-config --cxxflags. @Trass3r might be able to look into it since he contributed CMakeLists.txt.

For Python: if there is a smart way to select Python 2 (or also make the script legal under Python 3 as well, which I don't use because it still doesn't ship with OS X), that would make me happier than suffixing 2.7.

For the segfault, if you could join the executable, I could at least tell if fcd does something dumb or if your fcd executable is broken.

[fay59]

FWIW, there were many problems with the Makefile that have now been resolved. I'm not sure I understand how your Clang ends up missing <math.h> and this specific part hasn't changed, however. Can you #include <cmath> without errors with Clang in another program?

[Vtec234]

About make, the culprit is this flag: -isystem /usr/include in the clang++ command. It puts /usr/include at the first position in the search order for include directories, and all other directories are after it. #include_next <math.h> only searches in directories AFTER the one in which cmath was found, and since -isystem /usr/include puts it at the beginning, /usr/include/math.h cannot be found. I cannot compile anything with #include <cmath> when this flag is present, but it works fine without it.

As for llvm-config --cxxflags, the CMake script actually uses some CMake modules provided by LLVM, which internally define LLVM_DEFINITIONS to include the -D__STDC.. stuff. Unfortunately, for whatever reason (CMake kinda sucks), ${LLVM_DEFINITIONS} in the CMakeLists script no longer contains these flags, so I had to add them manually.

Finally, I included the executables. ack2 is my exec which computes a sinf and prints it, fcd is, well, fcd, which I compiled. They are both Linux ELF64s, so you won't launch them on OSX, but maybe you can take a look at the disassembly or such. execs.zip

[fay59]

The #include situation is annoying. You can't ask llvm-config to not output include options. (I guess this is what you get for installing it right in /usr!)

Ack2 doesn't come out too well because fcd does not attempt to support floating-point numbers yet, but the version that I just built on Debian did produce output.

As it turns out, I can't run your fcd copy because it appears that it linked in a way that upsets my virtual machine. If all you changed is the required -D parameters to generate bindings.cpp and and using Python 2.7, it seems to me that it should work. Make sure that you're compiling fcd with the same C++ standard library as your LLVM installation was compiled with.

[Vtec234]

The actual issue here is that the -isystem flag is hardcoded in a few places in the Makefile and messes up the order. You're right that you cannot/should not modify the output of llvm-config --cxxflags, but on my system it outputs -I\usr\include instead of -isystem\usr\include and works perfectly fine, meaning I can compile stuff which #include <cmath> using the LLVM output. CMake not setting the right variables is another issue, and I have little idea on how to fix that.

As for the binaries, I used strings on both, and my exec includes GLIBCXX 3.4, while fcd includes 3.4, 3.4.14, 3.4.18, 3.4.15, 3.4.20, 3.4.21, and libLLVM includes the same ones as fcd. Not sure if that is what you meant about how to check what it was compiled with.

[fay59]

My understanding of the -I option is that much like -isystem it puts the directory at the beginning of the search list, so I'm surprised to hear that this works. If it really does, just change $(subst -I,-isystem ,$(shell $(LLVM_CONFIG) --cxxflags)) to $(shell $(LLVM_CONFIG) --cxxflags) and add --system-header-prefix=llvm/, and that might be it.

The only other time I've seen a bad build of fcd that systematically crashed was in a situation where LLVM had been built against libstdc++ but fcd was being built against libc++.

Can you run fcd without parameters? Can you get a stack trace?

[Vtec234]

This is the output from LLDB at the point where it segfaults:

Process 26659 stopped
* thread #1: tid = 26659, 0x00000000007384e4 fcd`llvm::PointerIntPair<ExpressionUse*, 2u, unsigned int, llvm::PointerLikeTypeTraits<ExpressionUse*>, llvm::PointerIntPairInfo<ExpressionUse*, 2u, llvm::PointerLikeTypeTraits<ExpressionUse*> > >::setPointer(this=0x2000000100000004, PtrVal=0x0000000001941630) + 20 at PointerIntPair.h:63, name = 'fcd', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
frame #0: 0x00000000007384e4 fcd`llvm::PointerIntPair<ExpressionUse*, 2u, unsigned int, llvm::PointerLikeTypeTraits<ExpressionUse*>, llvm::PointerIntPairInfo<ExpressionUse*, 2u, llvm::PointerLikeTypeTraits<ExpressionUse*> > >::setPointer(this=0x2000000100000004, PtrVal=0x0000000001941630) + 20 at PointerIntPair.h:63
   60     }
   61   
   62     void setPointer(PointerTy PtrVal) {
-> 63       Value = Info::updatePointer(Value, PtrVal);
   64     }
   65   
   66     void setInt(IntType IntVal) {

And this is the backtrace:

* thread #1: tid = 28787, 0x00000000007384e4 fcd`llvm::PointerIntPair<ExpressionUse*, 2u, unsigned int, llvm::PointerLikeTypeTraits<ExpressionUse*>, llvm::PointerIntPairInfo<ExpressionUse*, 2u, llvm::PointerLikeTypeTraits<ExpressionUse*> > >::setPointer(this=0x2000000100000004, PtrVal=0x0000000001941630) + 20 at PointerIntPair.h:63, name = 'fcd', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
  * frame #0: 0x00000000007384e4 fcd`llvm::PointerIntPair<ExpressionUse*, 2u, unsigned int, llvm::PointerLikeTypeTraits<ExpressionUse*>, llvm::PointerIntPairInfo<ExpressionUse*, 2u, llvm::PointerLikeTypeTraits<ExpressionUse*> > >::setPointer(this=0x2000000100000004, PtrVal=0x0000000001941630) + 20 at PointerIntPair.h:63
frame #1: 0x00000000007384c4 fcd`ExpressionUse::setNextPrev(this=0x0000000001941630, use=0x0000000001941630) + 52 at expression_use.cpp:44
frame #2: 0x0000000000738b3a fcd`ExpressionUse::setUse(this=0x0000000001941630, target=0x00000000014c3f28) + 170 at expression_use.cpp:128
frame #3: 0x000000000073afcb fcd`ExpressionUser::setOperand(this=0x0000000001941660, index=1, expression=0x00000000014c3f28) + 43 at expression_user.h:176
frame #4: 0x0000000000742b11 fcd`CallExpression::setParameter(this=0x0000000001941660, index=0, param=0x00000000014c3f28) + 49 at expressions.h:412
frame #5: 0x0000000000751e15 fcd`InstToExpr::visitCallInst(this=0x00007fffffffdc38, inst=0x0000000001bb6c80) + 181 at ast_context.cpp:267
frame #6: 0x0000000000751ba1 fcd`llvm::InstVisitor<InstToExpr, Expression*>::delegateCallInst(this=0x00007fffffffdc38, I=0x0000000001bb6c80) + 529 at InstVisitor.h:281
frame #7: 0x000000000074f76d fcd`llvm::InstVisitor<InstToExpr, Expression*>::visitCall(this=0x00007fffffffdc38, I=0x0000000001bb6c80) + 29 at Instruction.def:186
frame #8: 0x000000000074ec31 fcd`llvm::InstVisitor<InstToExpr, Expression*>::visit(this=0x00007fffffffdc38, I=0x0000000001bb6c80) + 1569 at Instruction.def:186
frame #9: 0x000000000074df0d fcd`llvm::InstVisitor<InstToExpr, Expression*>::visit(this=0x00007fffffffdc38, I=0x0000000001bb6c80) + 29 at InstVisitor.h:114
frame #10: 0x000000000074acf0 fcd`InstToExpr::visitValue(this=0x00007fffffffdc38, val=0x0000000001bb6c80) + 64 at ast_context.cpp:154
frame #11: 0x000000000074ae1f fcd`AstContext::expressionFor(this=0x0000000001b74fd8, value=0x0000000001bb6c80) + 95 at ast_context.cpp:524
frame #12: 0x000000000074af68 fcd`AstContext::statementFor(this=0x0000000001b74fd8, inst=0x0000000001bb6c80) + 232 at ast_context.cpp:543
frame #13: 0x0000000000764bce fcd`FunctionNode::basicBlockToStatement(this=0x0000000001b74fb0, bb=0x0000000001b91b00) + 142 at function.cpp:44
frame #14: 0x0000000000766286 fcd`AstBackEnd::runOnFunction(this=0x0000000001bb2c50, fn=0x0000000001ab8698) + 278 at pass_backend.cpp:597
frame #15: 0x0000000000765e5c fcd`AstBackEnd::runOnModule(this=0x0000000001bb2c50, m=0x0000000001478760) + 284 at pass_backend.cpp:556
frame #16: 0x000000000097c494 fcd`llvm::legacy::PassManagerImpl::run(llvm::Module&) + 772
frame #17: 0x00000000007d53d3 fcd`(anonymous namespace)::Main::generateEquivalentPseudocode(this=0x00007fffffffe6b8, module=0x0000000001478760, output=0x00000000013cc460) + 339 at main.cpp:580
frame #18: 0x00000000007d346a fcd`main(argc=2, argv=0x00007fffffffe838) + 2410 at main.cpp:795
frame #19: 0x00007ffff5e89741 libc.so.6`__libc_start_main + 241
frame #20: 0x00000000006aa949 fcd`_start + 41

[fay59]

It definitely gets far enough to call it my fault, and I'm pretty sure that your build changes didn't break it. setPointer(this=0x2000000100000004) is probably uninitialized memory, I'll look into it after work.

[fay59]

I didn't find uninitialized memory but I did run into two use-after-frees trying to figure out what is causing the problem (the second of which could have caused incorrect results, so yay!). At this point, however, fcd dies because it does not know how to handle indirect jumps and there's one in a function called from _init.

I'm waiting on LLVM features that will make it easier to go back and forth between passes for a definitive fix to that (as it's often not super hard to figure out possible destinations for an indirect jump), but until then, it would probably be better to see a stranded goto *somewhere than not seeing anything at all.

That's all the time I had for tonight. I'll return to it tomorrow. Until then, you can try C programs, since they tend to include by default less stuff that breaks fcd :)

[fay59]

Indirect jumps are now replaced with an __indirect_jump "function" and I can't reproduce the issue that you had. Could you try building again and see if the problem is fixed? If not, upload your new executable and I'll set up some environment that I can debug it in.

[Vtec234]

Yep, the __indirect_jump call allows correct decompilation, so thanks for that. As for the -isystem flags, is there any necessity to keep them over simple -Is? And I found another issue. When compiling fcd and its components (like bindings.cpp) with a -g flag, I can't decompile the simplest things due to a SIGSEGV here:

* thread #1: tid = 1034, 0x0000000000437521 fcd`AstContext::getType(llvm::Type&) [inlined] llvm::StructType::hasName(this=0x0000000000000000) const at DerivedTypes.h:268, name = 'fcd', stop reason = signal SIGSEGV: invalid address (fault address: 0x18)
    frame #0: 0x0000000000437521 fcd`AstContext::getType(llvm::Type&) [inlined] llvm::StructType::hasName(this=0x0000000000000000) const at DerivedTypes.h:268 [opt]
   265    bool isSized(SmallPtrSetImpl<Type *> *Visited = nullptr) const;
   266  
   267    /// hasName - Return true if this is a named struct that has a non-empty name.
-> 268    bool hasName() const { return SymbolTableEntry != nullptr; }
   269  
   270    /// getName - Return the name for this struct type if it has an identity.
   271    /// This may return an empty string for an unnamed struct type.  Do not call

with the backtrace:

* thread #1: tid = 1034, 0x0000000000437521 fcd`AstContext::getType(llvm::Type&) [inlined] llvm::StructType::hasName(this=0x0000000000000000) const at DerivedTypes.h:268, name = 'fcd', stop reason = signal SIGSEGV: invalid address (fault address: 0x18)
  * frame #0: 0x0000000000437521 fcd`AstContext::getType(llvm::Type&) [inlined] llvm::StructType::hasName(this=0x0000000000000000) const at DerivedTypes.h:268 [opt]
    frame #1: 0x0000000000437521 fcd`AstContext::getType(this=0x00000000016a6a98, type=0x0000000000f618d8) + 289 at ast_context.cpp:633 [opt]
    frame #2: 0x000000000043760d fcd`AstContext::getType(this=<unavailable>, type=<unavailable>) + 525 at ast_context.cpp:623 [opt]
    frame #3: 0x0000000000438f43 fcd`InstToExpr::visitConstant(this=0x00007fffffffd7f0, constant=0x00000000010219b8) + 2371 at ast_context.cpp:219 [opt]
    frame #4: 0x000000000043a427 fcd`InstToExpr::visitCallInst(llvm::CallInst&) + 48 at ast_context.cpp:524 [opt]
    frame #5: 0x000000000043a3f7 fcd`InstToExpr::visitCallInst(llvm::CallInst&) [inlined] InstToExpr::valueFor(this=0x00007fffffffd898, value=0x00000000010219b8) + 3 at ast_context.cpp:121 [opt]
    frame #6: 0x000000000043a3f4 fcd`InstToExpr::visitCallInst(this=<unavailable>, inst=0x000000000148a828) + 148 at ast_context.cpp:262 [opt]
    frame #7: 0x0000000000439367 fcd`llvm::InstVisitor<InstToExpr, Expression*>::visit(llvm::Instruction&) [inlined] llvm::InstVisitor<InstToExpr, Expression*>::visitCall(this=<unavailable>, I=<unavailable>) + 743 at Instruction.def:186 [opt]
    frame #8: 0x000000000043935f fcd`llvm::InstVisitor<InstToExpr, Expression*>::visit(this=0x00007fffffffd898, I=<unavailable>) + 735 at Instruction.def:186 [opt]
    frame #9: 0x0000000000436c4d fcd`AstContext::statementFor(llvm::Instruction&) + 48 at ast_context.cpp:524 [opt]
    frame #10: 0x0000000000436c1d fcd`AstContext::statementFor(this=0x00000000016a6a98, inst=0x000000000148a828) + 237 at ast_context.cpp:543 [opt]
    frame #11: 0x00000000004625b4 fcd`FunctionNode::basicBlockToStatement(this=<unavailable>, bb=<unavailable>) + 260 at function.cpp:44 [opt]
    frame #12: 0x000000000047b858 fcd`AstBackEnd::runOnFunction(this=<unavailable>, fn=<unavailable>) + 376 at pass_backend.cpp:597 [opt]
    frame #13: 0x000000000047b3ac fcd`AstBackEnd::runOnModule(this=<unavailable>, m=<unavailable>) + 588 at pass_backend.cpp:556 [opt]
    frame #14: 0x0000000000b5f6a4 fcd`llvm::legacy::PassManagerImpl::run(llvm::Module&) + 772
    frame #15: 0x0000000000467b5d fcd`main [inlined] (anonymous namespace)::Main::generateEquivalentPseudocode(llvm::Module&, llvm::raw_ostream&) + 274 at main.cpp:580 [opt]
    frame #16: 0x0000000000467a4b fcd`main(argc=<unavailable>, argv=<unavailable>) + 17099 at main.cpp:795 [opt]
    frame #17: 0x00007ffff5e89741 libc.so.6`__libc_start_main + 241
    frame #18: 0x0000000000431359 fcd`_start + 41

[fay59]

Clang doesn't report warnings for system headers. We need that because LLVM offends a lot of checks that fcd builds with. --system-header-prefix as outlined above solves the same problem, if that works with your configuration.

I might not have a lot of time to look into these crashes in the very near future (before Monday-ish) but I'll do it when I get a chance.

[Trass3r]

The CMake script relies on the exported llvm config file: http://llvm.org/docs/CMake.html#embedding-llvm-in-your-project Has worked fine for me so far.

[fay59]

In that crash case, it looks like an invalid llvm::Function object is referenced from another correct Function. I have a rough idea of what could be causing that, but it would really help me if you could attach the executable. (Since you seem to say that ack2 more or less decompiled correctly, I'm going to assume that it's a different one.)

[Vtec234]

I would, but since commit bc3bcc528f60293464c7b59dfd22221903c9782b I can't compile fcd due to the no-longer-suppressed LLVM warnings:

MemorySSA.cpp:138:27: warning: implicit conversion changes signedness: 'typename iterator_traits<SuccIterator<TerminatorInst *, BasicBlock> >::difference_type' (aka 'int') to 'unsigned int' [-Wsign-conversion]
      unsigned NumEdges = std::count(succ_begin(BB), succ_end(BB), S);
               ~~~~~~~~   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MemorySSA.cpp:278:13: error: implicit conversion loses integer precision: 'typename iterator_traits<PredIterator<BasicBlock, user_iterator_impl<User> > >::difference_type' (aka 'long') to 'unsigned int' [-Werror,-Wshorten-64-to-32]
        BB, std::distance(pred_begin(BB), pred_end(BB)), nextID++);
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Trass3r]

Also fwiw these macros also worked for the msvc compiler since that one does not provide anything like isystem.

[fay59]

The build essentially always required Clang anyways. @Trass3r, since Clang is required at some point by the build process regardless of what other compiler you'd be using, I see no compelling reason to attempt to support other compilers.

@Vtec234, I'm talking about the executables you're trying to decompile, not fcd itself. Sorry about the build break though.

[Vtec234]

No problem, it's just that I wanted to have a working fcd (which I don't currently) to isolate the cause, since the crash I mentioned above (with hasName) only occurs when I compile fcd with the -g flag.

Here is the zipped executable which I ran it on, but I don't think the content matters much, since it's simply a main { return 0; } compiled with clang++ main.cpp -g -o ack.

Without -g in the Makefile, it decompiles normally (the code includes __indirect_jump though, so something the compiler/linker adds must use that).

[fay59]

Even on trivial programs, the compiler adds a lot of boilerplate and there's a chance that your specific installation does something that I haven't seen before. For instance, your test case might trigger UB in fcd that hasn't been identified yet because most of my test cases were compiled with the same version of GCC.

[fay59]

I spent some time with your ack program, built fcd with -g and used as much trickery as I could, but I couldn't reproduce that issue or find additional problems that could do something like that. At this point I'm probably going to need your binary, and I'll see what I can do to make it run on a machine I have access to.

The build has been fixed, by the way.

[Vtec234]

Sorry, this error is not in fact caused by building fcd with -g, but by building emulator.o with -g. In this archive I included some diffs to explain it. Makefile.diff is what has to be changed for it to compile on my system. Makefile.sub.diff contains the -g flag that breaks the build, and fcd is what I got that segfaults on the ack executable I included earlier.

[fay59]

Oh.

The emulator files aren't compiled to native code (at least in the main project) and they are never executed. The generated LLVM IR module is embedded into fcd and instruction implementations are inlined as the same instructions are encountered in the input executable. See Lifting x86 code into LLVM bitcode if you're interested in the process.

I'm not aware of any benefit in having debug symbols in there, but I can think of many problems that could be caused by that. Unless you really know what you're doing, don't add -g to *.emulator.cpp files.

[Vtec234]

Okay then, will not build the IR with -g. Thank you very much for the help, and since all the problems I had with building and running fcd have now been fixed, I can close the issue.

[Trass3r]

Building it with -gline-tables-only is quite useful if you use an AssemblyAnnotator. But -g creates too much noise.