Harbour → LLVM IR

How it works

• harbour -GL hello.prg parses the xBase source and emits LLVM IR text (.ll), not C.
• The embedded libLLVM C API turns that IR into a native object; the embedded LLD linker links the executable — all in-process, no second pass.
• Each pcode opcode in the supported subset becomes one hb_vmsh_* shim call: one basic block per opcode, no interpreter dispatch — straight-line native code.
• Functions using opcodes outside the subset fall back, whole-function, to the hb_vmExecute interpreter — correctness is always preserved.

What you achieve

• Zero external toolchain. No gcc / MSVC / clang on PATH. No second-stage make. One harbour.exe.
• 100% Harbour-compatible. The shims call the same hb_vm* helpers the interpreter calls; every test diff-checks byte-for-byte against the C backend.
• Nine opcode groups straight-lined — FOR loops, arrays, RDD/memvars, OOP, FOR EACH, SWITCH, codeblocks, macros, SEQUENCE (try/catch + try/finally).
• Permanent fallback safety net. Programs that touch the (small) set of intentionally-unsupported opcodes still build and run correctly via the interpreter.
• Open to future type specialization — removing dispatch overhead is the first half; specializing local int/double slots is the next bigger win.

Does harbour -GL produce a .exe directly?

Yes — in one command, in-process, no external C/C++ compiler or linker on PATH. The intermediate .ll and .o are kept next to the binary for inspection.

$ harbour -GL -ohello hello.prg
$ ls hello.*
hello.prg  hello.ll  hello.o  hello.exe   # source + IR + object + binary
$ ./hello
hello, world

Is the .exe a pre-built template that gets patched, or freshly compiled each time?

Freshly compiled and linked every time. Each invocation produces a unique binary (verifiable via sha1sum) — IR generated fresh from source, object compiled fresh, executable linked fresh. No "template + patch" shortcut. Two different programs produce different IRs of different sizes, different objects, different binaries with different SHA1s.

The ~1.3 MB common floor is the Harbour runtime statically linked in — the variable delta on top is the program's own native code.

Who actually does the linking?

harbour.exe itself, via embedded LLD. The src/llvmbe/ directory builds libhbllvm.a which contains:

• libLLVM C API — turns the IR into a native object file.
• LLD — the LLVM linker, wrapped by a tiny C++ shim (src/compiler/hb_lldshim.cpp) so C code can call lld::mingw::link in-process.

When harbour -GL runs, after emitting the .ll it calls into libhbllvm.a's emitObject then linkExe — no process fork, no external tool, no shell-out. libhbllvm.a is linked only into harbour.exe via a dispatch table (g_hb_llvm_backend), so hbmk2 and hbrun stay small.

How are libraries linked into the final executable?

harbour.exe builds a ld.lld-style argv in src/compiler/hb_llvmobj.c and hands it to LLD. The argv references three sets of libraries, all shipped with Harbour:

Plus this program's own freshly-compiled .o. The end-user's machine needs no toolchain at all — Harbour ships its own C runtime, MinGW import libs, the Harbour runtime, and the LLVM/LLD code generator inside harbour.exe. One install, one binary, runnable executables out.