The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: sect3/screen
Context English State
Start up lldb by typing
<prompt>%</prompt> <userinput>lldb -- <replaceable>progname</replaceable></userinput>
Running a Program with lldb
Compile the program with <option>-g</option> to get the most out of using <command>lldb</command>. It will work without, but will only display the name of the function currently running, instead of the source code. If it displays a line like:
Breakpoint 1: where = temp`main, address = …
(without an indication of source code filename and line number) when setting a breakpoint, this means that the program was not compiled with <option>-g</option>.
Most <command>lldb</command> commands have shorter forms that can be used instead. The longer forms are used here for clarity.
At the <command>lldb</command> prompt, type <userinput>breakpoint set -n main</userinput>. This will tell the debugger not to display the preliminary set-up code in the program being run and to stop execution at the beginning of the program's code. Now type <userinput>process launch</userinput> to actually start the program— it will start at the beginning of the set-up code and then get stopped by the debugger when it calls <function>main()</function>.
To step through the program a line at a time, type <userinput>thread step-over</userinput>. When the program gets to a function call, step into it by typing <userinput>thread step-in</userinput>. Once in a function call, return from it by typing <userinput>thread step-out</userinput> or use <userinput>up</userinput> and <userinput>down</userinput> to take a quick look at the caller.
Here is a simple example of how to spot a mistake in a program with <command>lldb</command>. This is our program (with a deliberate mistake):
#include &lt;stdio.h&gt;

int bazz(int anint);

main() {
int i;

printf("This is my program\n");
return 0;

int bazz(int anint) {
printf("You gave me %d\n", anint);
return anint;
This program sets <symbol>i</symbol> to be <literal>5</literal> and passes it to a function <function>bazz()</function> which prints out the number we gave it.
Compiling and running the program displays
<prompt>%</prompt> <userinput>cc -g -o temp temp.c</userinput>
<prompt>%</prompt> <userinput>./temp</userinput>
This is my program
anint = -5360
That is not what was expected! Time to see what is going on!
<prompt>%</prompt> <userinput>lldb -- temp</userinput>
(lldb) target create "temp"
Current executable set to 'temp' (x86_64).
(lldb) <userinput>breakpoint set -n main</userinput> <lineannotation>Skip the set-up code</lineannotation>
Breakpoint 1: where = temp`main + 15 at temp.c:8:2, address = 0x00000000002012ef <lineannotation>lldb puts breakpoint at main()</lineannotation>
(lldb) <userinput>process launch</userinput> <lineannotation>Run as far as main()</lineannotation>
Process 9992 launching
Process 9992 launched: '/home/pauamma/tmp/temp' (x86_64) <lineannotation>Program starts running</lineannotation>

Process 9992 stopped
* thread #1, name = 'temp', stop reason = breakpoint 1.1 <lineannotation>lldb stops at main()</lineannotation>
frame #0: 0x00000000002012ef temp`main at temp.c:8:2
5 main() {
6 int i;
-&gt; 8 printf("This is my program\n"); <lineannotation>Indicates the line where it stopped</lineannotation>
9 bazz(i);
10 return 0;
11 }
(lldb) <userinput>thread step-over</userinput> <lineannotation>Go to next line</lineannotation>
This is my program <lineannotation>Program prints out</lineannotation>
Process 9992 stopped
* thread #1, name = 'temp', stop reason = step over
frame #0: 0x0000000000201300 temp`main at temp.c:9:7
6 int i;
8 printf("This is my program\n");
-&gt; 9 bazz(i);
10 return 0;
11 }
(lldb) <userinput>thread step-in</userinput> <lineannotation>step into bazz()</lineannotation>
Process 9992 stopped
* thread #1, name = 'temp', stop reason = step in
frame #0: 0x000000000020132b temp`bazz(anint=-5360) at temp.c:14:29 <lineannotation>lldb displays stack frame</lineannotation>
11 }
13 int bazz(int anint) {
-&gt; 14 printf("You gave me %d\n", anint);
15 return anint;
16 }
Hang on a minute! How did <symbol>anint</symbol> get to be <literal>-5360</literal>? Was it not set to <literal>5</literal> in <function>main()</function>? Let us move up to <function>main()</function> and have a look.
(lldb) <userinput>up</userinput> <lineannotation>Move up call stack</lineannotation>
frame #1: 0x000000000020130b temp`main at temp.c:9:2 <lineannotation>lldb displays stack frame</lineannotation>
6 int i;
8 printf("This is my program\n");
-&gt; 9 bazz(i);
10 return 0;
11 }
(lldb) <userinput>frame variable i</userinput> <lineannotation>Show us the value of i</lineannotation>
(int) i = -5360 <lineannotation>lldb displays -5360</lineannotation>
Oh dear! Looking at the code, we forgot to initialize <symbol>i</symbol>. We meant to put
main() {
int i;

i = 5;
printf("This is my program\n");
but we left the <literal>i=5;</literal> line out. As we did not initialize <symbol>i</symbol>, it had whatever number happened to be in that area of memory when the program ran, which in this case happened to be <literal>-5360</literal>.
The <command>lldb</command> command displays the stack frame every time we go into or out of a function, even if we are using <userinput>up</userinput> and <userinput>down</userinput> to move around the call stack. This shows the name of the function and the values of its arguments, which helps us keep track of where we are and what is going on. (The stack is a storage area where the program stores information about the arguments passed to functions and where to go when it returns from a function call.)
Examining a Core File with lldb
A core file is basically a file which contains the complete state of the process when it crashed. In <quote>the good old days</quote>, programmers had to print out hex listings of core files and sweat over machine code manuals, but now life is a bit easier. Incidentally, under FreeBSD and other 4.4BSD systems, a core file is called <filename><replaceable>progname</replaceable>.core</filename> instead of just <filename>core</filename>, to make it clearer which program a core file belongs to.
To examine a core file, specify the name of the core file in addition to the program itself. Instead of starting up <command>lldb</command> in the usual way, type <userinput>lldb -c <replaceable>progname</replaceable>.core -- <replaceable>progname</replaceable></userinput>
The debugger will display something like this:
<prompt>%</prompt> <userinput>lldb -c <filename><replaceable>progname</replaceable>.core</filename> -- <filename><replaceable>progname</replaceable></filename></userinput>
(lldb) target create "<filename><replaceable>progname</replaceable></filename>" --core "<filename><replaceable>progname</replaceable></filename>.core"
Core file '/home/pauamma/tmp/<filename><replaceable>progname</replaceable>.core</filename>' (x86_64) was loaded.
In this case, the program was called <filename><replaceable>progname</replaceable></filename>, so the core file is called <filename><replaceable>progname</replaceable>.core</filename>. The debugger does not display why the program crashed or where. For this, use <userinput>thread backtrace all</userinput>. This will also show how the function where the program dumped core was called.
(lldb) <userinput>thread backtrace all</userinput>
* thread #1, name = '<filename><replaceable>progname</replaceable></filename>', stop reason = signal SIGSEGV
* frame #0: 0x0000000000201347 <filename><replaceable>progname</replaceable></filename>`bazz(anint=5) at temp2.c:17:10
frame #1: 0x0000000000201312 <filename><replaceable>progname</replaceable></filename>`main at temp2.c:10:2
frame #2: 0x000000000020110f <filename><replaceable>progname</replaceable></filename>`_start(ap=&lt;unavailable&gt;, cleanup=&lt;unavailable&gt;) at crt1.c:76:7
<literal>SIGSEGV</literal> indicates that the program tried to access memory (run code or read/write data usually) at a location that does not belong to it, but does not give any specifics. For that, look at the source code at line 10 of file temp2.c, in <function>bazz()</function>. The backtrace also says that in this case, <function>bazz()</function> was called from <function>main()</function>.
Attaching to a Running Program with lldb


New source string 7 months ago
Browse all component changes

Things to check

Multiple failing checks

Following checks are failing:
Has been translated: Spanish
Unchanged translation: Spanish, Persian


Source information

Source string comment
(itstool) path: sect3/screen
no-wrap, read-only
Source string location
String age
7 months ago
Source string age
7 months ago
Translation file
books/developers-handbook.pot, string 342