GDB display LLVM IR variables fails

Question

I build a simple application:

hello.c

#include <stdio.h>

void foo(int x)
{
    printf("%d", x);
}

int main()
{
    printf("Hello\n");
    foo(6+5);
    return 0;
}

With an LLVM IR representation:

; ModuleID = 'hello.ll'
source_filename = "hello.c"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"

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

; Function Attrs: noinline nounwind optnone uwtable
define dso_local void @foo(i32 %0) #0 {
  %2 = alloca i32, align 4
  store i32 %0, i32* %2, align 4
  %3 = load i32, i32* %2, align 4
  %4 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 %3)
  ret void
}

; Function Attrs: nounwind readnone speculatable willreturn
declare void @llvm.dbg.declare(metadata, metadata, metadata) #1

declare dso_local i32 @printf(i8*, ...) #2

; Function Attrs: noinline nounwind optnone uwtable
define dso_local i32 @main() #0 {
  %1 = alloca i32, align 4
  store i32 0, i32* %1, align 4
  %2 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([7 x i8], [7 x i8]* @.str.1, i64 0, i64 0))
  call void @foo(i32 11)
  ret i32 0
}

attributes #0 = { noinline nounwind optnone uwtable "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "frame-pointer"="all" "less-precise-fpmad"="false" "min-legal-vector-width"="0" "no-infs-fp-math"="false" "no-jump-tables"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "no-trapping-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { nounwind readnone speculatable willreturn }
attributes #2 = { "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "frame-pointer"="all" "less-precise-fpmad"="false" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "no-trapping-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "unsafe-fp-math"="false" "use-soft-float"="false" }

Using debug.ir tool, I convert it to:

./debugir hello.ll

hello.dbg.ll

; ModuleID = 'hello.ll'
source_filename = "hello.c"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"

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

; Function Attrs: noinline nounwind optnone uwtable
define dso_local void @foo(i32 %0) #0 !dbg !4 {
  %2 = alloca i32, align 4, !dbg !9
  store i32 %0, i32* %2, align 4, !dbg !10
  %3 = load i32, i32* %2, align 4, !dbg !11
  %4 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 %3), !dbg !12
  ret void, !dbg !13
}

; Function Attrs: nounwind readnone speculatable willreturn
declare void @llvm.dbg.declare(metadata, metadata, metadata) #1

declare dso_local i32 @printf(i8*, ...) #2

; Function Attrs: noinline nounwind optnone uwtable
define dso_local i32 @main() #0 !dbg !14 {
  %1 = alloca i32, align 4, !dbg !17
  store i32 0, i32* %1, align 4, !dbg !18
  %2 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([7 x i8], [7 x i8]* @.str.1, i64 0, i64 0)), !dbg !19
  call void @foo(i32 11), !dbg !20
  ret i32 0, !dbg !21
}

attributes #0 = { noinline nounwind optnone uwtable "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "frame-pointer"="all" "less-precise-fpmad"="false" "min-legal-vector-width"="0" "no-infs-fp-math"="false" "no-jump-tables"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "no-trapping-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { nounwind readnone speculatable willreturn }
attributes #2 = { "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "frame-pointer"="all" "less-precise-fpmad"="false" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "no-trapping-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "unsafe-fp-math"="false" "use-soft-float"="false" }

!llvm.dbg.cu = !{!0}
!llvm.module.flags = !{!3}

!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "LLVM Version 10.0", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2)
!1 = !DIFile(filename: "hello.ll", directory: "")
!2 = !{}
!3 = !{i32 2, !"Debug Info Version", i32 3}
!4 = distinct !DISubprogram(name: "foo", linkageName: "foo", scope: !1, file: !1, line: 9, type: !5, scopeLine: 11, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)
!5 = !DISubroutineType(types: !6)
!6 = !{!7, !8}
!7 = !DIBasicType(tag: DW_TAG_unspecified_type, name: "void")
!8 = !DIBasicType(name: "i32", size: 32, encoding: DW_ATE_unsigned)
!9 = !DILocation(line: 11, scope: !4)
!10 = !DILocation(line: 12, scope: !4)
!11 = !DILocation(line: 13, scope: !4)
!12 = !DILocation(line: 14, scope: !4)
!13 = !DILocation(line: 15, scope: !4)
!14 = distinct !DISubprogram(name: "main", linkageName: "main", scope: !1, file: !1, line: 23, type: !15, scopeLine: 25, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)
!15 = !DISubroutineType(types: !16)
!16 = !{!8}
!17 = !DILocation(line: 25, scope: !14)
!18 = !DILocation(line: 26, scope: !14)
!19 = !DILocation(line: 27, scope: !14)
!20 = !DILocation(line: 28, scope: !14)
!21 = !DILocation(line: 29, scope: !14)

Now running gdb:

gdb lli-10
(gdb) set args -jit-kind=mcjit hello.dbg.ll
(gdb) break hello.ll:14
(gdb) run
Starting program: /usr/bin/lli-10 -jit-kind=mcjit hello.dbg.ll
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Hello

Breakpoint 1, foo () at hello.ll:14
14    %4 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 %3)
(gdb)

When I try to get the variable value, I will get an error:

(gdb) print %3
A syntax error in expression, near `%3'.

How should I get the value of %3 variable?

Vaivaswatha N · Answer 1 · 2021-05-01T08:48:17.600

2

The Debug-IR pass only adds line number information and not variable location and type information, unfortunately. So what you're asking for cannot be achieved as far as I know.

There is some code in the pass (getOrCreateType()) to build debuginfo types from LLVM types. I suppose this can be extended, and then variable location information added to the IR to achieve what you want. It's non-trivial work though.

edit: I've updated the tool to annotate some variable location information. GDB can now print some local variables (info locals). It is far from perfect though.

edited May 01 '21 at 08:48

answered Apr 25 '21 at 07:26

Vaivaswatha N

153
1
7

If we cannot browse the variable, then what is the point of the debugger? – ar2015 Apr 25 '21 at 12:37
@ar2015 Tracing the flow of control (following the philosophy of "something is better than nothing"). At least until someone (or I) get the time to implement tagging of variable location information to the IR. – Vaivaswatha N Apr 27 '21 at 04:24
@ar2015 I've added some basic support for printing variables. https://github.com/vaivaswatha/debugir/commit/63e09c7ffdd04b657076e72628c071b14f46c04b. It is far from perfect though. – Vaivaswatha N May 01 '21 at 08:48

score 0 · Answer 2 · answered Apr 24 '21 at 17:53

0

(gdb) print %3

GDB doesn't understand (in fact doesn't know anything) about LLVM IR.

It's just not one of the languages GDB supports (assembly, C, C++, Fortran, Ada, etc.).

Here is a relevant thread from 2012.

answered Apr 24 '21 at 17:53

Employed Russian

199,314
34
295
362

Then how to inspect the variables? – ar2015 Apr 24 '21 at 18:54
Well, it does read line information from the bitcode file, so it should be able to lookup variables too. Maybe reading `debug-ir` pass would help. – arrowd Apr 24 '21 at 19:48
I think the whole premise is off here. "%3" is not a variable in any sense, but some kind of SSA thing, as I understand it. No kind of hypothetical LLVM IR support for GDB would make inspecting "%3" possible, would it? It isn't even a "variable" in the traditional sense. [*sigh* wishing for llvmpf...] – Leif Strand Apr 27 '21 at 00:41

GDB display LLVM IR variables fails

2 Answers2

Linked