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 functionto>> GlobalAddress table!"' failed. >> >> So my main concern - is that a correct way to insert a call instructionin>> 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. > >-EliWell 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. - Nehal.
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
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. Thanks, Nehal. -----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 addfunction> 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 thefile> 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 biggerpass> (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 -------------- 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>