I often find it useful to walk the stack when I'm debugging a program and get the symbols for any properly aligned, pointer-sized value I encounter. I've gotten sick of doing this manually and so I tried writing a command that does it for me. The problem is that "info symbol" doesn't seem to like using a convenience variable as its parameter when its parameter was set via pointer dereference. IE:
(gdb) info symbol 0xb6ca4d28
[Useful Symbol Information]
(gdb) set $pointer = $esp
(gdb) while ( *(int*)$pointer != 0xb6ca4d28)
>set $pointer += 4
>end
(gdb) x/x $pointer
0x6ebee064: 0xb6ca4d28
(gdb) set $dereferencePointer = *(int *)$pointer
(gdb) p/x $dereferencePointer
$103 = 0xb6ca4d28
(gdb) info symbol $dereferencePointer
No symbol matches $dereferencePointer.
(gdb) set $dereferencePointer = 0xb6ca4d28
(gdb) p/x $dereferencePointer
$104 = 0xb6ca4d28
(gdb) info symbol $dereferencePointer
[Useful symbol information]
(gdb)
Why is this? Is this a bug? Is there a different way to do this?
Thanks!
Luc
PS: Using vanilla GDB 7.5
Update from list:
This is most likely a bug.
Bug or not, I recommend using the /a format specifier with p and x commands. This always works for me, and is faster to type, too.
Related
I would like to do use a variable from my bash/ gdb environment and set it as a convenience variable in gdb.
(gdb) show environment
bar=1
(gdb) set $foo = (show environment bar)
(gdb) show convenience
foo=1
Of course, my second (gdb) command returns an error. I have looked quite a bit to see if something like this is possible. But perhaps I am looking in the wrong direction. Could anyone be of help?
You could do it using builtin Python, like so:
(gdb) py import os
(gdb) py gdb.set_convenience_variable("home", os.environ["HOME"])
(gdb) p $home
$1 = "/home/me"
I am writing a GDB macro to analyze the core and print a string. The output of string from core is "sp-4/0/2". Now I need to print only "sp", excluding others. I am not sure how to achieve this in GDB. Any pointers of this would be a great help.
Thanks in advance.
See, argv[1] is "sp-4/0/2"
(gdb) p argv[1]
$4 = 0x7fffffffe3fa "sp-4/0/2"
And this is only two first chars:
(gdb) printf "%.2s\n", argv[1]
sp
Or
(gdb) printf "%c%c\n", argv[1][0],argv[1][1]
sp
The following alternative works even when the size isn't known statically:
(gdb) p {char} argv[1]#2
I.e. you can replace the 2 by a variable or register value. This is useful when you are adding a breakpoint in e.g. write and don't have debug symbols available:
(gdb) b -qualified write # only match write, don't do globbing
(gdb) cond 1 $rdi == 2 # only when writing to stderr
(gdb) command 1
bt
p {char} $rsi#$rdx # print (partial) buffer
cont
The above works when the System V AMD64 calling convention is used, but can be easily adopted to the arm calling conventions by adapting the registers.
I found a suspicious deadlock at address myfile.exe+0x144c7 (from list of threads in ProcessExplorer). Now, I want to know which function it is.
info symbol addr
requires that addr is absolute. Is there a command that takes the relative address given by ProcessExplorer. I can add 0x400000 but it would be better if GDB could do it for me.
gdb accepts an expression for the symbol address, so you can do something like this:
info symbol 0x40000000 + 0x144c7
If you check "info variables" (or use nm on the executable) there's probably a symbolic name for the text segment containing your code, so you can also do something like:
info symbol _init + 0x144c7
Note that symbol might not work as expected if your problem is in a DLL or other text segment.
I'm writing a little BASIC compiler using LLVM, everything works fine. I'm trying to get debugging to work, and it's going fine, but I have a weird issue with variable names and GDB's print statement.
A little background on BASIC for those not familiar:
In BASIC, variable names use a symbol on the end to determine their type. So a variable x% would be integer, and variable x$ would be a string, and both can co-exist.
The statement DEFINT A-Z means that any variable starting with any letter from A to Z will be type INT, even without the trailing %. But, internally, my compiler will store the name mangled with the trailing % to avoid overlap with another variable with a trailing $.
Here is my little test program:
defint a-z
x = 5
y = 100
z = x + y
if x = 5 then
print "z=";z
else
print "z!=";z
end if
So 'x' is actually stored internally and put into the symbol table as x%.
OK, so I load my compiled EXE into GDB...
D:\dev\BasicParser>gdb t.exe
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from D:\dev\BasicParser\t.exe...done.
(gdb) b _jbc_main
Breakpoint 1 at 0x401000: file t.bas, line 1.
(gdb) r
Starting program: D:\dev\BasicParser\t.exe
[New Thread 1532.0x25b8]
Breakpoint 1, _jbc_main () at t.bas:1
1 defint a-z
(gdb) n
4 x = 5
(gdb) info address x%
Symbol "x%" is static storage at address 0x4263c4.
At this point, you can see that GDB recognizes the symbol x% because it recognizes and display it's address. But the following "print" fails:
(gdb) print x%
No symbol "x" in current context.
Hmmm... that's interesting ... it dropped the % symbol.
But I can look at the memory location where x% is stored and this looks correct:
(gdb) x 0x4263c4
0x4263c4 <x%>: 0x00000000
If I show all symbols I get this as expected:
(gdb) info variables
All defined variables:
File t.bas:
static i32 x%;
static i32 y%;
static i32 z%;
Continuing on, to show that x% does get modified by the code:
(gdb) n
5 y = 100
(gdb) print x%
No symbol "x" in current context.
(gdb) x 0x4263c4
0x4263c4 <x%>: 0x00000005
(gdb)
And as you can see, the memory that GDB thinks x% is at is definitely updated.
For some reason, the "print" command doesn't like the % symbol.
Here is the "info source" results on this module, you can see I didn't specify C as the language:
(gdb) info source
Current source file is t.bas
Compilation directory is D:\dev\BasicParser
Located in D:\dev\BasicParser\t.bas
Contains 18 lines.
Source language is minimal.
Compiled with DWARF 2 debugging format.
Does not include preprocessor macro info.
Any ideas for workarounds? I've been searching and searching and can't find a solution.
Thanks!
gdb simply interprets your command as modulo operation. It is not an error in gdb.
See, info source shows minimal for your file. This is from gdb's doc: http://sourceware.org/gdb/current/onlinedocs/gdb/Unsupported-Languages.html#Unsupported-Languages
In addition to the other fully-supported programming languages, GDB
also provides a pseudo-language, called minimal. It does not represent
a real programming language, but provides a set of capabilities close
to what the C or assembly languages provide.
So, what does this warning in your debugging session mean?
(gdb) print x%
No symbol "x" in current context.
Since minimal is a set of capabilities close C then gdb must iterpret this as trying to get remainder of division (http://en.wikipedia.org/wiki/Modulo_operation) - according to C programming language rules. So x is left arg, % is operation and the right arg is missing.
Let me show you example. This is a test C++ program that shows the minimal debugging session:
D:\src-c++\tests\test.vars>cat minimal.cpp
int main()
{
int k;
k = 1;
k = 2;
return 0;
}
And this is a debugging session:
D:\src-c++\tests\test.vars>gdb -q minimal.exe
Reading symbols from D:\src-c++\tests\test.vars\minimal.exe...done.
(gdb) start
Temporary breakpoint 1 at 0x4016be: file minimal.cpp, line 5.
Starting program: D:\src-c++\tests\test.vars/minimal.exe
[New Thread 2872.0x8c0]
Temporary breakpoint 1, main () at minimal.cpp:5
5 k = 1;
(gdb) show language
The current source language is "auto; currently c++".
(gdb) set language minimal
Warning: the current language does not match this frame.
(gdb) show language
The current source language is "minimal".
Warning: the current language does not match this frame.
(gdb) n
6 k = 2;
(gdb) print k
$1 = 1
(gdb) print k%
A syntax error in expression, near `'.
(gdb) print kk%
No symbol "kk" in current context.
Look -- No symbol "kk" in current context, the same error that you have.
Just a cross-reference, in case anybody else like me that might need help with this: I found this answer
In GDB, how to print the content of a symbol which has special characters?
where they indicate that you can quote names by starting with ampersand (&) and quote the name with single ticks ('), that is use something like
p &'my#complex.symbol%name'
x &'my#complex.symbol%name'
to inspect symbols with names beyond the usual C-style naming convention. I'm not completely clear what characters you can use at that point, but it seems like a good improvement.
As the other answer also points out, the GDB manual often refers to escaping symbol names just using single ticks (say something like p 'foo.c'). After some further reading I found in the GDB manual that this use of & seems to be an extension added for Windows support (see section titled "Features for Debugging MS Windows PE Executables", numbered 21.1.4 in the current edition), so I'm not sure if this may work outside of the Windows environment
In GDB, I can use "info line func_name" to get the memory address of func_name, and then use "set $PC=memory_address" to start debugging this function. How do I do the same within lldb? Thanks in advance!
The command in lldb is "image lookup". I think an example of "info func" <-> "image lookup" was recently added to the lldb/gdb command page - http://lldb.llvm.org/lldb-gdb.html
e.g.
(lldb) im loo -n puts
1 match found in /usr/lib/system/libsystem_c.dylib:
Address: libsystem_c.dylib[0x0000000000011d9a] (libsystem_c.dylib.__TEXT.__text + 69850)
Summary: libsystem_c.dylib`puts
(lldb)
although this is only showing you the offset in libsystem_c.dylib here (0x11d9a) -- to see the actual load address you would need to use the "-v" option to image lookup which will show the range of addresses that puts covers. Or you could do this more directly with the back tick notation in lldb,
(lldb) reg read pc
rip = 0x0000000100000f2b a.out`main + 11 at a.c:3
(lldb) reg write pc `(void(*)())puts`
(lldb) reg read pc
rip = 0x00007fff99ce1d9a libsystem_c.dylib`puts
OK I had to cast puts() because lldb needed a function prototype here - not super convenient, but if it's one of your own functions that isn't needed:
(lldb) reg write pc `main`
(lldb) reg read pc
rip = 0x0000000100000f20 a.out`main at a.c:2