[lldb-dev] IRInterpreter strange behavior
Zachary Turner
zturner at google.com
Thu Jun 26 17:21:53 PDT 2014
Thanks, I think that was it. This was a guard variable as mangled by the
Microsoft mangler.
On Thu, Jun 26, 2014 at 4:47 PM, Sean Callanan <scallanan at apple.com> wrote:
> Zachary,
>
> LLI’s interpreter is (a) not really supported code, having been superseded
> by the JIT; and (b) founded on the assumption that we’re interpreting
> inside the current process.
> The LLDB IRInterpreter is focused on interpreting in the context of
> another process (the IRMemoryMap is the interface it uses).
>
> It’s not clear to me what’s doing this. On OS X we don’t get this error:
> –
> (lldb) expr const unsigned int $foo = 5
> (lldb) expr &$foo
> (const unsigned int *) $0 = 0x046cdbe26a5d1000
> –
> and the symbol isn’t there either:
>
> –
> ; ModuleID = '$__lldb_module'
> target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
> target triple = "x86_64-apple-macosx"
>
> ; Function Attrs: nounwind
> define void @"_Z12$__lldb_exprPv"(i8* %"$__lldb_arg") #0 {
>
> %1 = getelementptr i8* %"$__lldb_arg", i32 8
> %2 = bitcast i8* %1 to i32**
> %3 = getelementptr i8* %"$__lldb_arg", i32 0
> %4 = bitcast i8* %3 to i32***
> %5 = load i32*** %4
> %6 = alloca i8*, align 8, !clang.decl.ptr !8
> store i8* %"$__lldb_arg", i8** %6, align 8
> %7 = icmp eq i8 0, 0
> br i1 %7, label %8, label %10
>
> ; <label>:8 ; preds = %0
> %9 = load i32** %2, align 8
> store i32* %9, i32** %5, align 8
> br label %10
>
> ; <label>:10 ; preds = %8, %0
> ret void
> }
> –
> What’s producing that? Is it some kind of guard variable?
> (IRForTarget.cpp strips those, but only the ones I’ve seen…)
>
> Sean
>
> On Jun 26, 2014, at 4:34 PM, Zachary Turner <zturner at google.com> wrote:
>
> I'm trying to diagnose a problem with the IRInterpreter, but this is all
> very foreign to me so I think I should ask here.
>
> Before I go into the details though, a simple question which I don't want
> to get lost in the shuffle: Why doesn't LLDB use LLI instead of creating
> its own interpreter?
>
> Anyway, on to the problem. First of all, this is only on Windows. This
> all just works on Linux and presumably Mac, although I don't have a Mac to
> test. The scenario is this: I run the following two commands:
>
> (lldb) expr const unsigned int $foo = 5
> (lldb) expr &$foo
>
> And this results in an error. Printing the value of $foo works fine, it
> just can't get the address.
>
> I turn on logging and I see this:
>
> Module as passed in to IRInterpreter::Interpret:
> "; ModuleID = '$__lldb_module'
> target datalayout = "e-m:w-p:32:32-i64:64-f80:32-n8:16:32-S32"
> target triple = "i686-pc-windows-msvc"
>
> *@"\01?$S1@?0??$__lldb_expr@@YAXPAX at Z@4IA" = internal global i32 0*
>
> ; Function Attrs: nounwind
> define void @"\01?$__lldb_expr@@YAXPAX at Z"(i8* %"$__lldb_arg") #0 {
> %1 = getelementptr i8* %"$__lldb_arg", i32 8
> %2 = bitcast i8* %1 to i32**
> %3 = getelementptr i8* %"$__lldb_arg", i32 0
> %4 = bitcast i8* %3 to i32***
> %5 = load i32*** %4
> %6 = alloca i8*, align 4, !clang.decl.ptr !8
> store i8* %"$__lldb_arg", i8** %6, align 4
> * %7 = load i32* @"\01?$S1@?0??$__lldb_expr@@YAXPAX at Z@4IA"*
> %8 = and i32 %7, 1
> %9 = icmp ne i32 %8, 0
> br i1 %9, label %13, label %10
>
> ; <label>:10 ; preds = %0
> %11 = or i32 %7, 1
> store i32 %11, i32* @"\01?$S1@?0??$__lldb_expr@@YAXPAX at Z@4IA"
> %12 = load i32** %2, align 4
> store i32* %12, i32** %5, align 4
> br label %13
>
> ; <label>:13 ; preds = %10, %0
> ret void
> }
>
> attributes #0 = { nounwind "less-precise-fpmad"="false"
> "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"
> "no-infs-fp-math"="false" "no-nans-fp-math"="false" "no-realign-stack"
> "stack-protector-buffer-size"="0" "unsafe-fp-math"="false"
> "use-soft-float"="false" }
>
> !clang.global.decl.ptrs = !{!0, !1, !2, !0, !0}
> !llvm.module.flags = !{!3, !4, !5, !6}
> !llvm.ident = !{!7}
>
> !0 = metadata !{null, i64 7787680}
> !1 = metadata !{null, i64 7787504}
> !2 = metadata !{void (i8*)* @"\01?$__lldb_expr@@YAXPAX at Z", i64 7787328}
> !3 = metadata !{i32 1, metadata !"Objective-C Version", i32 2}
> !4 = metadata !{i32 1, metadata !"Objective-C Image Info Version", i32 0}
> !5 = metadata !{i32 1, metadata !"Objective-C Image Info Section",
> metadata !"__DATA, __objc_imageinfo, regular, no_dead_strip"}
> !6 = metadata !{i32 4, metadata !"Objective-C Garbage Collection", i32 0}
> !7 = metadata !{metadata !"clang version 3.5.0 "}
> !8 = metadata !{i64 7787200}
> "
> IRMemoryMap::WriteMemory (0x81ffc, 0x124db54, 0x4) went to
> [0x2000..0x82000)
> Made an allocation for argument i8* %"$__lldb_arg"
> Data region : 1000
> Ref region : 81ffc
> Interpreting %1 = getelementptr i8* %"$__lldb_arg", i32 8
> IRMemoryMap::WriteMemory (0x81ff8, 0x702b00, 0x4) went to [0x2000..0x82000)
> Interpreted a GetElementPtrInst
> P : i8* %"$__lldb_arg" 0x81ffc
> Poffset : %1 = getelementptr i8* %"$__lldb_arg", i32 8 0x81ff8
> Interpreting %2 = bitcast i8* %1 to i32**
> IRMemoryMap::WriteMemory (0x81ff4, 0x702b00, 0x4) went to [0x2000..0x82000)
> Interpreting %3 = getelementptr i8* %"$__lldb_arg", i32 0
> IRMemoryMap::WriteMemory (0x81ff0, 0x702b00, 0x4) went to [0x2000..0x82000)
> Interpreted a GetElementPtrInst
> P : i8* %"$__lldb_arg" 0x81ffc
> Poffset : %3 = getelementptr i8* %"$__lldb_arg", i32 0 0x81ff0
> Interpreting %4 = bitcast i8* %3 to i32***
> IRMemoryMap::WriteMemory (0x81fec, 0x702b00, 0x4) went to [0x2000..0x82000)
> Interpreting %5 = load i32*** %4
> IRMemoryMap::ReadMemory (0x81fec, 0x702b00, 0x4) came from
> [0x2000..0x82000)
> IRMemoryMap::ReadMemory (0x1000, 0x702b00, 0x4) came from [0x1000..0x1010)
> IRMemoryMap::WriteMemory (0x81fe8, 0x702b00, 0x4) went to [0x2000..0x82000)
> Interpreted a LoadInst
> P : 0x81fec
> R : 0x1000
> D : 0x81fe8
> Interpreting %6 = alloca i8*, align 4, !clang.decl.ptr !8
> IRMemoryMap::WriteMemory (0x81fe0, 0x124dc00, 0x4) went to
> [0x2000..0x82000)
> Interpreted an AllocaInst
> R : 0x81fe4
> P : 0x81fe0
> Interpreting store i8* %"$__lldb_arg", i8** %6, align 4
> IRMemoryMap::ReadMemory (0x81fe0, 0x702b00, 0x4) came from
> [0x2000..0x82000)
> IRMemoryMap::ReadMemory (0x81ffc, 0x702b00, 0x4) came from
> [0x2000..0x82000)
> IRMemoryMap::WriteMemory (0x81fe4, 0x702b00, 0x4) went to [0x2000..0x82000)
> Interpreted a StoreInst
> D : 0x81ffc
> P : 0x81fe0
> R : 0x81fe4
> *Interpreting %7 = load i32* @"\01?$S1@?0??$__lldb_expr@@YAXPAX at Z@4IA"*
> *LoadInst's pointer doesn't resolve to anything*
>
> I've bolded a few of the relevant lines. I'm not really sure what's going
> on here, or even how to diagnose it. Can anyone offer some advice?
>
> Thanks
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140626/55495055/attachment.html>
More information about the lldb-dev
mailing list