[LLVMdev] Inserting a function call into bitcode

Nehal Gandhi nbg2k7 at gmail.com
Fri Jun 4 01:09:11 PDT 2010

Hi Eli,

I have attached a tar file containing Pass (ConditionPass.cpp), External
function (PrintRes.cpp) and test program (try.c). I use command chain as
describe in previous mail.


-----Original Message-----
From: Eli Friedman [mailto:eli.friedman at gmail.com] 
Sent: Friday, June 04, 2010 3:39 AM
To: Nehal Gandhi
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Inserting a function call into bitcode

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
> 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
> 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
> 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
> (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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ProfileCond.tar.bz2
Type: application/octet-stream
Size: 1305 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100604/5639f8b7/attachment.obj>

More information about the llvm-dev mailing list