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.
Related
Hi I had a little question.
I've been trying for hours to find a solution but I just do not get on.
I would like to use the gdb.attach function via pwntools.
But whenever I call this function also opens the gdb with the executable and also waits pwntools then on the gdb gives a feedback.
But in the GDB window goes then below only:
0x00007fbf014828be in __GI___libc_read (fd=0x0, buf=0x56139a7ee370, nbytes=0x1) at ../sysdeps/unix/sysv/linux/read.c:26
26 ../sysdeps/unix/sysv/linux/read.c: File or directory not found.
Breakpoint 1 at 0x7fbf0145f140: file ../sysdeps/unix/syscall-template.S, line 120.
When I use the gdb.debug function I have no problems but unfortunately I also need the gdb.attach function.
This is the test code I use:
from pwn import*
p = process('bash')
gdb.attach(p,
'''
directory /home/pentester/Downloads/glibc-2.32/
set follow-fork-mode child
break execve
continue
''')
p.interactiv()
I have already downloaded the glibc sources but I don't know where to put them exactly.
I had them in the sources in the gdbinit reingepackt but unfortunately the problem is still there :(
Does one of you maybe have an idea how I can get the whole thing running?
Edit:
What I forgot to say is that the debugger seems to hang and pwntools searches in vain for the gdb.
So I'm pretty new to gdb, and have just learned that you can save breakpoints with:
save breakpoints filename
and load them with
source filename
which is great, but because it's something I more or less plan on doing every time I enter/exit gdb, I'd like to get it down to a quick alias.
So, in my ~/.gdbinit I have the lines
alias savebps = save breakpoints .gdb_bps
alias loadbps = source .gdb_bps
loadbps
Unfortunately, every time I open gdb I get the error:
Invalid command to alias to: save breakpoints .gdb_bps
I know(/ strongly think) I have the syntax correct, as I've tested
alias savebps = help
and that alias works. So I think it's an issue with having a non-gdb command word (the filename) as part of an alias.
So, my questions are this:
Am I being totally stupid and there's already a great way to auto-save and maintain my list of breakpoints?
Can GDB have filenames in aliases? Or am I looking for something other than an 'alias'?
If they CAN have filenames in them, what am I doing wrong?
Oh and as a note the '.gdb_bps' is an arbitrary file name I just kinda came up with as it'd be a nice unobtrusive thing to easily .gitignore and stuff.
Thanks!
Can GDB have filenames in aliases?
Looks like no. It looks like aliases can't have any arguments to commands, not only filenames. This alias fails also:
(gdb) alias spe = set print elements 0
Invalid command to alias to: set print elements 0
Or am I looking for something other than an 'alias'?
Yes, you can use user-defined command instead:
(gdb) define savebps
Type commands for definition of "savebps".
End with a line saying just "end".
>save breakpoints .gdb_bps
>end
(gdb)
(gdb) define loadbps
Type commands for definition of "loadbps".
End with a line saying just "end".
>source .gdb_bps
>end
(gdb)
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.
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.
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.