CODEWITHSUNDEEP
cdebugginglldb
Gael Lorieul
Gael Lorieul

Reputation: 3246

Printing a variable's content using lldb

Okay, so this is going to sound like a silly question, yet I am stuck : I have trouble reading the value of a variable during a lldb debugging session (things work fine with gdb).

I have found posts from other people who had encountered the same error message than myself, but the difference is that I can't even figure out how to print out the value of the simplest form of variable.

To better express my problem, I will consider a very simple example here. We have a file "main.c" containing the following code :

#include <stdlib.h>
#include <stdio.h>

int main(void) {
  int a = 1;
  int b = 2;
  int c = 0;
  c = a + b;
  c = c*b;
  printf("c = %d\n", c);
  return 0;
}

I compile it using :

user@machine ~ $ gcc -g main.c

A binary file named "a.out" is generated

I then ivoque lldb :

user@machine ~ $ lldb-3.4 ./a.out

I want to stop at line 9 and read the value of c. Therefore, I start by adding a breakpoint :

(lldb) breakpoint set -f main.c -l 9

Then I run the code :

(lldb) run

Up until now, every thing goes as expected. Now comes the tricky part : I want to read the value of variable c. Therefore, I write :

(lldb) print c

And lldb returns me :

error: use of undeclared identifier 'c'
error: 1 errors parsing expression

Of course :

(lldb) expression c

returns exactly the same error message.

Is there anything that I missed ? Any help would be very much appreciated.

My setup :

Some more information following answer from @Sean Perry :

1: It seems that appending option -O0 does not change the debugger's behaviour.

2: I also tried to use the following dummy code instead of my previous one

#include <stdlib.h>
#include <stdio.h>

int main(void) {
  long a = 1;
  long b = 2;
  long c = 0;
  c = a + b;
  c += (long) &c;
  printf("c = %ld\n", c);
  return 0;
}

I am not certain that is what @Sean Perry meant by "using pointers", but I suppose it must prevent code optimisation anyway since the address of variable c (more or less) randomly changes for each run of the binary file.

3: Eventually, I noticed something interesting :

edit1 : reply to @SeanPerry edit2 : distinguishing the software version from the package version

Upvotes: 3

Views: 5636

Answers (3)

Jason Molenda
Jason Molenda

Reputation: 15375

The best way to investigate the behavior you're seeing is to look at the debug info. On a Mac OS X system, you'd run dwarfdump on the .dSYM bundle or on the .o file if you didn't create a dSYM. The debug information has the instructions from the compiler to the debugger about where to find variables.

In a live process, with lldb, you can have lldb show you where all the local variables are stored (expressed in the DWARF location expression language) with image lookup -v -a $pc (or im loo -va $pc for short).

If there's a program where gdb can't print a variable and lldb at the same pc address cannot, that sounds like it could be an lldb bug. The debug information is the ultimate truth (as far as the debugger is concerned) about where variables are stored and how long they are "live". In optimized code, they may be live for very short sections of your function.

From a hack point of view, the real source of truth is to read the assembly code. Often, under optimization, the compiler doesn't track the location of the variables as well as it could -- it may say that a variable is unavailable at a given pc address, but if you read the assembly closely enough, you might find a copy of the last value still saved on the stack & such.

Upvotes: 1

Scis
Scis

Reputation: 2974

Seems like this was a specific issue when using gcc 4.8.1 and lldb-3.4

Using gcc-4.8.2 and gcc-4.7.3 works fine.

Upvotes: 2

Sean Perry
Sean Perry

Reputation: 3886

This code is so simple I bet llvm has removed the variables completely. Try compiling with optimizations disabled (-O0) and see if it helps. Beyond that, use a pointer or do something a little more complicated so the compiler does not removed your math and replace it with precomputed values.

Upvotes: 0

Related Questions