Thread overview
Dlang LLVM ERROR: Program used external function which could not be resolved
Jun 15
Kagamin
June 14
https://stackoverflow.com/questions/44550353/dlang-llvm-error-program-used-external-function-which-could-not-be-resolved

I try to compile d code to llvm IR but when i compile or execute .ll i have error

LLVM ERROR: Program used external function '_d_throw_exception' which could not be resolved!

Why in c or c++ with

clang -S -emit-llvm foo.c
lli foo.ll

It is work normaly.
June 14
Hi Kevin,

On 14 Jun 2017, at 17:48, BARRE KEVIN via digitalmars-d-ldc wrote:
> LLVM ERROR: Program used external function '_d_throw_exception' which could not be resolved!
>
> Why in c or c++ with
>
> clang -S -emit-llvm foo.c
> lli foo.ll

`_d_throw_exception` is a function in the D standard library (druntime, to be precise). As such, even though the LLVM IR produced by LDC is well-formed (i.e. LDC is not at fault here), when lli tries to interpret the IR in question, it isn't able to find the address of the function ("could not be resolved"), because it doesn't know anything about druntime or how to load it.

lli has the necessary provisions for C/C++, so it works there (I don't remember off the top of my head whether they hardcode the C runtime functions or simply use the symbols from the lli executable itself, which is of course written in C++).

You could, for instance, work around this by compiling druntime into bitcode and linking that with your .ll files before trying to execute them. Why do you want to use lli in the first place, though?

Best,
David
June 15
Try this:
---
import core.stdc.stdio;
int main()
{
    puts("Hello World !!!");
    return 0;
}
---
June 15
On Wednesday, 14 June 2017 at 16:48:31 UTC, BARRE KEVIN wrote:
> https://stackoverflow.com/questions/44550353/dlang-llvm-error-program-used-external-function-which-could-not-be-resolved
>
> I try to compile d code to llvm IR but when i compile or execute .ll i have error
>
> LLVM ERROR: Program used external function '_d_throw_exception' which could not be resolved!
>
> Why in c or c++ with
>
> clang -S -emit-llvm foo.c
> lli foo.ll
>
> It is work normaly.

lli -load /usr/lib/libphobos2.so foo.ll

I forgot link the library
June 15
On Thursday, 15 June 2017 at 13:30:21 UTC, BARRE KEVIN wrote:
> On Wednesday, 14 June 2017 at 16:48:31 UTC, BARRE KEVIN wrote:
>> https://stackoverflow.com/questions/44550353/dlang-llvm-error-program-used-external-function-which-could-not-be-resolved
>>
>> I try to compile d code to llvm IR but when i compile or execute .ll i have error
>>
>> LLVM ERROR: Program used external function '_d_throw_exception' which could not be resolved!
>>
>> Why in c or c++ with
>>
>> clang -S -emit-llvm foo.c
>> lli foo.ll
>>
>> It is work normaly.
>
> lli -load /usr/lib/libphobos2.so foo.ll
>
> I forgot link the library

lli -load /usr/lib/libdruntime-ldc-debug.so.72 -load /usr/lib/libphobos2-ldc-debug.so.72 main.ll

no work :(

i forgot something ?
June 15
> lli -load /usr/lib/libdruntime-ldc-debug.so.72 -load /usr/lib/libphobos2-ldc-debug.so.72 main.ll
>
> no work :(
>
> i forgot something ?

LLVM ERROR: Program used external function '__start___minfo' which could not be resolved!

June 15
On 15 Jun 2017, at 15:50, BARRE KEVIN via digitalmars-d-ldc wrote:
> LLVM ERROR: Program used external function '__start___minfo' which could not be resolved!

lli's error message is slightly misleading; __start___minfo is not a function, but a special symbol usually "created" by the linker while producing the main executable. It is used to register the D modules from your executable with druntime, so that static constructors, etc. can be invoked.

You'd need to disable all the functionality requiring runtime support to make D code work within lli, for example using `-betterC` or `pragma(LDC_no_moduleinfo)`/…. Still not sure why you would want to use `lli` with LDC-compiled code in the first place, though.

 — David
June 15
On Wednesday, 14 June 2017 at 17:05:00 UTC, David Nadlinger wrote:
> Hi Kevin,
>
> On 14 Jun 2017, at 17:48, BARRE KEVIN via digitalmars-d-ldc wrote:
>> [...]
>
> [...]

I want try llvm tools :)

for example compile D source in llvm source (.bc, .ll) and compile later with llc or execute with lli.

it is possible ??

Thanks
June 15
On Thursday, 15 June 2017 at 14:59:48 UTC, David Nadlinger wrote:
> On 15 Jun 2017, at 15:50, BARRE KEVIN via digitalmars-d-ldc wrote:
>> LLVM ERROR: Program used external function '__start___minfo' which could not be resolved!
>
> lli's error message is slightly misleading; __start___minfo is not a function, but a special symbol usually "created" by the linker while producing the main executable. It is used to register the D modules from your executable with druntime, so that static constructors, etc. can be invoked.
>
> You'd need to disable all the functionality requiring runtime support to make D code work within lli, for example using `-betterC` or `pragma(LDC_no_moduleinfo)`/…. Still not sure why you would want to use `lli` with LDC-compiled code in the first place, though.
>
>  — David

ldc2 -output-ll -betterC main.d
lli -load /usr/lib/libphobos2-ldc.so.72 main.ll

output -> Hello World !!!

Thanks David

You are ninja
June 15
Hi Kevin,

On 15 Jun 2017, at 16:17, BARRE KEVIN via digitalmars-d-ldc wrote:
> I want try llvm tools :)
>
> for example compile D source in llvm source (.bc, .ll) and compile later with llc or execute with lli.
>
> it is possible ??

Using the LLVM tools is definitely possible – in fact, this is a large part of what makes LLVM development so much easier than for the DMD backend (and to some extent, also than GCC). Using llc should always work just fine. What LDC does to produce an executable is more or less equivalent to "llc -filetype=obj …", followed by a call to the system linker which you can see using "ldc2 -v". I also regularly use the opt tool to look at what individual optimizer passes do to a given piece of code, and bugpoint for debugging LLVM crashes/miscompilations.

lli is a bit different to the usual compilation workflow in that it literally executes the IR inside an interpreter. Thus, all the code that relies on the program image (executable file)/globals/… as a concept won't work. This includes the central druntime mechanics for module registration and (probably) also garbage collection. Thus, lli might not be the easiest thing to get started with, although it can definitely be made to work if you work without druntime.

Best,
David