[LLVMdev] Add call printf instructions problems

[Jin Huang]

Thanks,Cheers!

I found the problem is that the "Function *call_print" using the same name
as the “class call_print”, which made the compiler wrongly resolved the
call_print type!

But I got another problems. I successfully compile the pass and I can
insert the call printf (C Lib function) instructions in the LLVM IR(eg:
call.bc).  If the call.bc didn't contain call printf instruction ,I can
call printf successfully ,but if not ,there exists a problem. the llvm will
rename my inserted call function , and the transformed code can not run
correctly!

the original .bc file:

; ModuleID = 'call.bc'
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@.str = private unnamed_addr constant [4 x i8] c"%d\0A\00", align 1

; Function Attrs: nounwind uwtable
define i32 @main() #0 {
entry:
  %retval = alloca i32, align 4
  %a = alloca i32, align 4
  store i32 0, i32* %retval
  store i32 3, i32* %a, align 4
  %0 = load i32* %a, align 4
  %call = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([4 x
i8]* @.str, i32 0, i32 0), i32 %0)
  %1 = load i32* %a, align 4
  ret i32 %1
}

//contains call printf
declare i32 @printf(i8*, ...) #1

attributes #0 = { nounwind uwtable "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"="true"
"no-infs-fp-math"="false" "no-nans-fp-math"="false"
"unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"="true"
"no-infs-fp-math"="false" "no-nans-fp-math"="false"
"unsafe-fp-math"="false" "use-soft-float"="false" }

here is the .bc file that I get after the transform:

; ModuleID = 'call.opt.bc'
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@.str = private unnamed_addr constant [4 x i8] c"%d\0A\00", align 1
@.str2 = private constant [4 x i8] c"%d\0A\00"

; Function Attrs: nounwind uwtable
define i32 @main() #0 {
entry:
  %retval = alloca i32, align 4
  %a = alloca i32, align 4
  store i32 0, i32* %retval
  // this is the instruction that I inserted ,which calls a C Lib "printf"
  %0 = call i32 (i8*, ...)* @printf1(i8* getelementptr inbounds ([4 x i8]*
@.str2, i32 0, i32 0), i32 2)
  store i32 3, i32* %a, align 4
  %1 = load i32* %a, align 4
  %call = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([4 x
i8]* @.str, i32 0, i32 0), i32 %1)
  %2 = load i32* %a, align 4
  ret i32 %2
}

declare i32 @printf(i8*, ...) #1

// if the program didn't contain call printf instruction ,this declaration
should be as the one above,but now it was renamed and can not be resolved
declare i32 @printf1(i8*, ...)

attributes #0 = { nounwind uwtable "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"="true"
"no-infs-fp-math"="false" "no-nans-fp-math"="false"
"unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"="true"
"no-infs-fp-math"="false" "no-nans-fp-math"="false"
"unsafe-fp-math"="false" "use-soft-float"="false" }

Is there any method to avoid the rename manipulation ?
Thanks!


2013/12/16 Tim Northover <t.p.northover at gmail.com>

> Hi Jin,
>
> It's difficult to say just from looking at a pass, but one thing looked
> odd:
>
> > CallInst *call_print =
> CallInst::Create(call_print,paramArrayRef,"",ins_temp);
>
> This looks very dodgy. The "call_print" being used as an argument is
> the (uninitialised) one that's just been declared. This could be the
> source of the assertion failure (though a segfault is just as likely).
>
> Other than that I'd suggest hooking up a debugger and going up the
> call frames when that assertion hits. That should tell you exactly
> which line of your pass is causing trouble.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131217/321ff37e/attachment.html>