I'm using lldb from the command line to debug a simple C program.
On my machine at work, I was able to use tab completion for symbol names. For example, if I type "b ma" then Tab, it'll tab-complete to "b main". The same goes for other functions.
However, I cannot get this feature to work on my laptop, where an actual tab (ASCII value 9) is inserted after the cursor. Both machines are running 10.8.4 and have the latest Xcode.
Any ideas?
I think you're running gdb on one of your two systems.
lldb can do tab completion -- it can do more sophisticated tab completion than gdb -- but you have to use the canonical form of the lldb commands for it to work. The b command you're using is an alias (a regular expression alias - a list of regular expressions that try to parse your breakpoint command and do the right thing) which doesn't give the lldb tab completion engine enough information about context to do anything.
Instead, if you were to do
(lldb) br s -n ma<TAB>
it would autocomplete. This is the short form of breakpoint set --name, of course.
The cleverness of lldb comes in to effect when you realize that lldb can tab complete lots of different arguments -- breakpoint set --filefileTab will complete "file" as a filename. breakpoint set --selector will autocomplete selector names. breakpoint set --shlib (which limits the breakpoint to only set in a specific dylib/framework/binary) will autocomplete with the list of dylibs/frameworks/binaries.
At some point in the future we want to get tab completion working with alias commands like b but no one has had time to tackle that one yet.
Related
Using the CodeLLDB extension, I'm successfully debugging my C projects with lldb in VSCode.
The problem is that I cannot use lldb commands in the VSCode watch window.
For example, I'm trying to print the first 10 items in an array using parray <COUNT> <EXPRESSION>.
This is what I obtain:
Is there a way to manipulate data using lldb?
For reference, with GDB you can do *myarr#10 in VSCode.
parray is an lldb command line command. It looks like the watch window expects an expression, not lldb commands. lldb's expression parser, unlike gdb's, is just the underlying language parser (e.g. it uses a copy of clang for C++). That makes it a more faithful evaluator of the expressions you hand it, but limits what debugger centric syntax we can introduce (like the gdb #10). So you could watch the elements one by one, but there isn't C syntax for "elements 0-9 of an array" so the expression parser doesn't support that either.
Presumably, VSCode has a "debugger console" for debugger commands. That's where you would enter the parray command. lldb also has stop hooks, so if you wanted to see this array's values in the console each time you stopped, you could do:
(lldb) target stop-hook add -o "parray 10 passport.data"
stop hooks can be set to trigger only for certain functions, so you could limit this printing to the function where passport is defined, as well.
I am debugging a problem with programmatically adding constraints. When my app crashes LLDB tells me to break on -[UIView _viewHierarchyUnpreparedForConstraint:] to debug the problem further. However, when I add a breakpoint with LLDB :
b s -n -[UIView _viewHierarchyUnpreparedForConstraint:]
I get the following warning from LLDB:
WARNING: Unable to resolve breakpoint to any actual locations.
I also tried adding a symbolic breakpoint using the Breakpoint navigator + option.
So it looks to me as if this symbol does not exist.
How can i see a list of all the symbols generated in order to make sure that this symbol exists or not?
thanks for your help
-Malena
The lldb command line is space-delimited, so if you want to pass arguments or option values to it that have spaces in them, you need to use quotes to protect the spaces. See if this works:
(lldb) b s -n "-[UIView _viewHierarchyUnpreparedForConstraint:]"
The careful reader would have noted that the command as you typed it had "-[UIView" as the option value for -n and then a dangling argument "_viewHierarchyUnpreparedForConstraint:]" and by rights (since break set takes no arguments) you should have gotten an error about break set taking no arguments. THAT is a bug...
To answer your other question, the lldb command:
(lldb) image dump symtab
will dump all the symbols in the program. You can scope this to a particular library by adding it to the command line, so for instance this one is probably in UIKit, so:
(lldb) image dump symtab UIKit
will show you only the symbols in UIKit. There's also a command to lookup particular symbols by name, image lookup -n though in general if the breakpoint setter can't find them, image lookup isn't going to find them either.
I need to print some structure for debugging purposes.Since the code base is huge i am having difficulty locating the exact member I need to look into.Is there some way I could print out the entire structure? or atleast know what type of structure it is so that I can go back and look into it's definition?
Use a debugger. Most debuggers give you an option to see the contents of an entire structure whenever you hit a breakpoint. On *nix the most popular debugger is gdb, and on Windows the most popular IDE (which includes a debugger) is Visual Studio. Both the sited I linked to have free-as-in-beer download links.
In gdb, you can set a breakpoint with the break command, and once you reach the breakpoint you can print the contents of the struct with the print command. More specifically, you can compile with debugging data included (the -g flag in gcc), and then use
$ gdb debugging_executable
Some basic information about GDB gets printed here
> break main.c:100
> run
> print struct_variable
It's also worth looking into the step and continue commands.
In Visual Studio, you can set a breakpoint by double-clicking just to the left of the source line (there is a gray bar on the left side of the editor), and mouse over the variable name to inspect the contents once you reach the breakpoint.
I was figuring out a problem where starting the application from GDB results in a symbol lookup error, but starting it from the shell works.
It turns out that whenever you start a program from within GDB it will start a new shell and thus override all environment variables I had set before starting GDB (like LD_LIBRARY_PATH).
This is not really the behavior I want. Can someone explain the rationale behind this, or tell me how I can turn this off?
I am guessing that you unconditionally set LD_LIBRARY_PATH in your ~/.cshrc or the like. So if from a shell prompt you do this:
export LD_LIBRARY_PATH=foo # or for csh:
setenv LD_LIBRARY_PATH foo
$SHELL -c 'echo $LD_LIBRARY_PATH'
the result is something other than foo. Don't do that.
Usually this happens to CSH users, who neglected to protect their ~/.cshrc against non-interactive shells. It could also happen to BASH users who set their BASH_ENV.
I meet the same problem. I find that in inferior.h (source code of gdb gdb/inferior.h)
there is a macro STARTUP_WITH_SHELL, there is also a piece of comment as
/* If STARTUP_WITH_SHELL is set, GDB's "run"
will attempts to start up the debugee under a shell.
This is in order for argument-expansion to occur. E.g.,
(gdb) run *
The "*" gets expanded by the shell into a list of files.
While this is a nice feature, it turns out to interact badly
with some of the catch-fork/catch-exec features we have added.
In particular, if the shell does any fork/exec's before
the exec of the target program, that can confuse GDB.
To disable this feature, set STARTUP_WITH_SHELL to 0.
To enable this feature, set STARTUP_WITH_SHELL to 1.
The catch-exec traps expected during start-up will
be 1 if target is not started up with a shell, 2 if it is.
- RT
If you disable this, you need to decrement
START_INFERIOR_TRAPS_EXPECTED in tm.h. */
#define STARTUP_WITH_SHELL 1
#if !defined(START_INFERIOR_TRAPS_EXPECTED)
#define START_INFERIOR_TRAPS_EXPECTED 2
#endif
Then I set STARTUP_WITH_SHELL as 0 and decremented START_INFERIOR_TRAPS_EXPECTED
and recompiled my gdb. After that gdb didn't start from shell any more.
When you start gdb from the shell, you start it as a new process, there's no way around that. In Unix new processes inherit some of the environment of the parent.
To make sure a variable is inherited, if you're using a bourne-like shell, try exporting it:
export LD_LIBRARY_PATH=...
The debuggee (inferior in gdb parlance) is always started with a clean environment in order to get more reproducible results. In order to set a variable there, use the
set env VARNAME=VALUE
command before running.
How do I make gdb print functions of interest as they are called, indented according to how deep in the stack they are?
I want to be able to say something like (made up):
(gdb) trace Foo* Bar* printf
And have gdb print all functions which begin with Foo or Bar, as they are called. Kind of like gnu cflow, except using the debugging symbols and only printing functions which actually get called, not all possible call flows.
Tools which won't help include cachegrind, callgrind and oprofile, which order the results by which functions were called most often. I need the order of calling preserved.
The wildcarding (or equivalent) is essential, as there are a lot of Foo and Bar funcs. Although I would settle for recording absolutely every function. Or, perhaps telling gdb to record all functions in a particular library.
Some GDB wizard must have a script for this common job!
In your case I would turn to the define command in gdb, which allows you to define a function, which can take up to 10 arguments.
You can pass in the names of functions to "trace" as arguments to the function you define, or record them all in the function itself. I'd do something like the following
define functiontrace
if $arg0
break $arg0
commands
where
continue
end
end
if $arg1
...
Arguments to a user-defined function in gdb are referenced as $arg0-$arg9. Alternatively, you could just record every function you wanted to trace in the function, instead of using $arg0-9.
Note: this will not indent as to depth in the stack trace, but will print the stack trace every time the function is called. I find this approach more useful than strace etc... because it will log any function you want, system, library, local, or otherwise.
There's rbreak cmd accepting regular expression for setting breakpoints. You can use:
(gdb) rbreak Foo.*
(gdb) rbreak Bar.*
(gdb) break printf
See this for details on breakpoints.
Then use commands to print every function as it's called. E.g. let α = the number of the last breakpoint (you can check it with i br if you missed), then do:
(gdb) commands 1-α
Type commands for breakpoint(s) 1-α, one per line.
End with a line saying just "end".
>silent
>bt 1
>c
>end
(gdb)
Some elaboration: silent suppresses unnecessary informational messages, bt 1 prints the last frame of backtrace (i.e. it's the current function), c is a shortcut for continue, to continue execution, and end is just the delimiter of command list.
NB: if you trace library functions, you may want to wait for lib to get loaded. E.g. set a break to main or whatever function, run app until that point, and only then set breakpoints you wanted.
Use the right tool for the job ;)
How to print the next N executed lines automatically in GDB?
Did you see litb's excellent anwser to a similar post here ?
He uses readelf to get interesting symbols, gdb commands to get the trace, and awk to glue all that.
Basically what you have to change is to modify his gdb command script to remove the 1 depth from backtrace to see the stack and filter specific functions, and reformat the output with an awk/python/(...) script to present it as a tree. (I admit I'm too lazy to do it now...)
You may call gdb in batch mode (using -x option), break where you need and ask for backtrace (bt), then you filter the result using grep or egrep.
Indents are more difficult, however bt output is ordered so you have current function at the top of the trace and main at very bottom.
So you create file with commands:
br <function name where to break>
run
bt
kill
quit
then run gdb <program> -x<command file>
Filter strings that starts with #<digit> - you get stack trace.