[LLVMdev] Inserting a function call into bitcode

Eli Friedman eli.friedman at gmail.com
Fri Jun 4 00:38:44 PDT 2010


On Fri, Jun 4, 2010 at 12:09 AM, Nehal Gandhi <nbg2k7 at gmail.com> wrote:
> On Thu, Jun 3, 2010 at 10:45 PM, Nehal Gandhi <nbg2k7 at gmail.com> wrote:
>>> Hi Eli,
>>>
>>> Thanks for that. Rookie mistake on my side. It solves the linking issue.
>>> However, it was not the main problem. The problem is when I execute the
>>> linked file ( modified bitcode + file containing the function), I get an
>>> assertion error - Assertion `Addr && "Code generation didn't add function
> to
>>> GlobalAddress table!"' failed.
>>>
>>> So my main concern - is that a correct way to insert a call instruction
> in
>>> the bitcode the way I did? The same code for inserting a function call
>>> instruction works correctly with LLVM2.5 .
>>
>>My best guess is that you're doing something wrong invoking the JIT;
>>there isn't anything obviously wrong with the code from your original
>>message.
>>
>>-Eli
>
> Well I am just using lli to run the linked file (i.e. program.bc). The
> command chain is usually as follows.
>
>        llvm-g++ --emit-llvm -c PrintRes.cpp -o PrintRes.bc
>        (PrintRes.bc has the function which I want to call from the
> newfile.bc below)
>
>        opt -load ../../../Release/lib/CondPass.so -ProfileCond < try.bc >
> /dev/null
>      (this generates newfile.bc while try.bc is original code)
>
>        llvm-link -o program.bc newfile.bc PrintRes.bc
>        lli program.bc
>
> where newfile.bc is the bitcode generated by pass and PrintRes.bcis the file
> that contains the function I am inserting using pass. Actually, program.bc
> starts running. But when it encounters call instruction for that function,
> it gives above assertion failure. The confusing thing how the same stuff
> works perfectly in LLVM2.5. It is preventing me porting a quite bigger pass
> (with lots of function calls and analysis part) from 2.5 to 2.6.

Hmm, so the crash is in a stock lli running over program.bc?  Then
your analysis pass isn't really relevant to the bug... can you attach
a crashing program.bc?

-Eli




More information about the llvm-dev mailing list