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.
Related
I am debugging my c++ program with gdb. I am having difficulties to set a simple double variable because of the German locale.
gdb won't accept values with decimal point. Typed with German decimal point (comma), gdb ignores everything after the comma.
(gdb) p this->foodSupply
$1 = 1
(gdb) set this->foodSupply = 4.3
Ungültige Nummer »4.3«.
(gdb) p this->foodSupply
$1 = 1
(gdb) set this->foodSupply = 4,3
(gdb) p this->foodSupply
$3 = 4
I figured I can avoid the problem by running gdb with LC_ALL=EN gdb ....
But since it's not as easy when working out of my IDE, I want to know if there is another way.
How can a German user type a decimal point in gdb?
Have a look at this bug:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1341125
There it is maybe explained, why it does not work like you want it to.
You can try a workaround like
(gdb) set this->foodSupply = (double) 43/10
if your numbers are as simple as 4.3.
I am trying to match the gdb disassemble output (disas [address]) against the source code. I know that such mapping can be done using (gdb) info line *address to find the matching line. However I do not quite understand the format of the output of disassemble. Specifically, what do the following numbers, +4722, and +4281, mean ?
0x00002ad61e45bd02 <+4722>: jmpq 0x2ad61e45bb49 <MsgManager::ForwardMsg(boost::shared_ptr<Channel>, boost::shared_ptr<Msg>, boost::shared_ptr<Context>)+4281>
I am using GNU gdb (GDB) 7.4.1.
Specifically, what do the following numbers, +4722, and +4281, mean
The instruction at address 0x00002ad61e45bd02, which is 4722 bytes from the start of current function (most likely MsgManager::ForwardMsg()) is a jump to address 0x2ad61e45bb49, which is 4281 bytes from the start of MsgManager::ForwardMsg().
You may also find (gdb) disas/m command handy.
I executed following commands in gdb and console output is as follows:
Rohan_gdb$ set $var = 15
Rohan_gdb$ p $var
$5 = 0xf
Rohan_gdb$ set $var = (int *)10
Rohan_gdb$ p $var
$6 = (int *) 0xa
Rohan_gdb$ set $char = "abc"
Rohan_gdb$ p $char
$7 = "abc"
Rohan_gdb$ set $char = (char *)"xyz"
evaluation of this expression requires the program to have a function "malloc".
(here I got error)
Rohan_gdb$ p $char
$8 = "abc"
Rohan_gdb$
Here I am debugging with target and not native debugging. I am using GNU gdb (GDB) 7.2 version. Is it possible to solve using scripts.
I don't know how to solve your specific problem, but I ran across something similar. Given the age of the question, maybe this'll provide a clue.
The problem is that your script is trying to store away a value in a buffer and it must allocated a new buffer for that storage. The storage requirement is likely the result of the cast or because that second string is not in the constant strings within your binary.
To fix, either change your code to not require a malloc (which is a bit of hit or miss, as far as I can tell). Or make the malloc symbol available; load a symbol table that allows gdb to resolve the "_malloc" symbol.
All values are interpreted in the current language. This means, for example, that if the current source language is C/C++ then searching for the string “hello” includes the trailing \0. The null terminator can be removed from searching by using casts, e.g.: {char[5]}"hello".
https://sourceware.org/gdb/onlinedocs/gdb/Searching-Memory.html
Example:
https://github.com/PhoenixInteractiveNL/emuDownloadCenter/wiki/Emulator-wincpc <-> WinCPC is the Borland Delphi port of an Amstrad CPC emulator called vbCPC.
F:\flynns_WinCPC>gdb wincpc.exe<br>
GNU gdb (GDB) 7.6<br>
...<br>
This GDB was configured as "i686-pc-mingw32".<br>
...<br>
Reading symbols from F:\flynns_WinCPC\wincpc.exe...(no debugging symbols found)...done.<br>
(gdb) info files<br>
Symbols from "F:\flynns_WinCPC\wincpc.exe".<br>
Local exec file:<br>
`F:\flynns_WinCPC\wincpc.exe', file type pei-i386.<br>
Entry point: 0x558448<br>
0x00401000 - 0x005587ec is CODE<br>
0x00559000 - 0x0055f7f8 is DATA<br>
0x007bf000 - 0x007c1b88 is .idata<br>
0x007c3000 - 0x007c301f is .rdata<br>
0x007c4000 - 0x007db530 is .reloc<br>
0x007dc000 - 0x00861c00 is .rsrc<br>
(gdb) find 0x00401000,0x00861c00,'m','e','m','o','r','y'<br>
0x48b224<br>
0x48b2e8<br>
0x48b312<br>
0x48b33a<br>
0x48b354<br>
0x48c2cc<br>
0x48cfcb<br>
0x82d910<br>
0x841484<br>
0x8456f9<br>
10 patterns found.<br>
(gdb) find 0x00401000,0x00861c00, <strong>{char[6]}</strong> "memory"<br>
evaluation of this expression requires the program to have a function "malloc".<br>
I tried b but seem not:
(gdb) p/b 0x0000000000400398
Size letters are meaningless in "print" command.
Is there such a switch?
You need the /t switch which works with both p and x:
(gdb) p /t 0x0000000000400398
$1 = 10000000000001110011000
See help x for more info on the FMT (format) switches.
x/4tb 0x0000000000400398 will let you analyze the Memory Address with Binary Values.
Can any 1 please tell or show the difference in the behaviour of any program before and after I "set endian little" in gdb on solaris machine?
I want to know the effect of changing it.
Thanks!
You should never have to set endianness when doing native (as opposed to remote) debugging.
You can however observe the ill effects of doing that:
(This is on Linux/x86 machine, but I expect you'll get similar results on Solaris/x86 and Solaris/SPARC).
int main()
{
int x = 0x1020304;
return x;
}
gdb -q a.out
Reading symbols from /tmp/a.out...done.
(gdb) b 4
Breakpoint 1 at 0x804835c: file t.c, line 4.
(gdb) r
Breakpoint 1, main () at t.c:4
4 return x;
(gdb) show endian
The target endianness is set automatically (currently little endian)
(gdb) p &x
$1 = (int *) 0xffffce60
(gdb) p/x *(int*)0xffffce60
$2 = 0x1020304
(gdb) set endian big
The target is assumed to be big endian
(gdb) p/x *(int*)0xffffce60
$3 = 0x4030201
To fully answer your question, this setting will have absolutely no effect whatsoever on the debugged program, only on gdb output as Employed Russian already stated.