As we know, during gdb debugging, command 'info reg' can be used to show register
status. But in some cases, if gdb start with x86 binary, which may jumped into a
memory block which contains X64-32 instructions, how can I get R9-R15 in step by
step debugging?
info register
set architecture i386:X64-32
I tried 'set architecture', but it doesn't work. Thanks in advance!
2 years later, I finally found that should set architecture i386:x64-32 BEFORE target program starting to run.
Related
I run qemu in command line by qemu -S -s -monitor stdio to figure out the first instruction to be executed by qemu and I find this problem.I want to know if it is about the 'vitual address' problem.if yes,can you explain it in detail？if not ,so why is it?enter image description here
in gdb terminal,it seems the $pc is different from $pc in qemu terminal because when I run x/10i $pcin the two terminals,it shows completely different?
could you please tell me how to run qemu in singlestep mode without the help of gdb?
thanks so much for helping me and bear my poor English...
1.I find someone said that " GDB can only access QEMU's memory by virtual address".But I don't know what it means exactly.
2.I know the first instruction in Intel 80386 is in 0xfffffff0,and when 80386 start up ,it is in real mode so it can only access 1M address space.I don't konw if this help to understand the question above.
I am using GDB to debug a running process using #gdb -p . Now I would like to set some break points and want to get leaks information. But I'm getting an error as below.
(gdb) info leaks
Leak detection is not enabled now.
If I try to set heap flags on, I'm getting error as mentioned below.
(gdb) set heap-check leaks on
librtc is not loaded: Either use -leaks command line option, set heap-check before starting the program, or link librtc explicitly
Hence please help me in a way to enable Leaks information.
Seems like you are on HP-UNIX,
If so try to use HP Wildebeest debugger.
There is a good documentation:
http://h20565.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=5060273&docId=emr_na-c02725289&docLocale=en_US
Refer PAGE number 8.
If you want very specific answer to your question:
Enable memleak option in gdb for linux
I am using GDB along with a JTAG device, an Abatron BDI2000, to debug a programs running on a Motorola M68332.
The 68332 does not have any hardware breakpoint registers. It has very primitive debugging features.
The build tools do not generate 'elf' files, so no symbols for GDB to use.
Also the program I'm debugging is running in Flash.
In fact the 68332 has only one debug instruction, ti. ti by itself steps to the next assembly instruction. ti xxx steps until the address xxx is reached. [Yes, this is caveman days, cold hammer and chisel :)]
I am able to use GDB with target remote to connect to the BDI2000 and issue the GDB commands 'nexti'. Due to the limitations of the 68332, 'stepi' is equivalent to 'nexti'.
Single stepping is only command available.
The monitor command 'monitor ti ' states change the program counter to and step.
If one uses a 'monitor' command that changes the registers, then GDB does not know about the command and its register cache become out of sync. I have created GDB functions which have the GDB command 'flushregs' at the end of each of them. This marks the register cache dirty. The GDB command will fetch a new set of registers.
I would like to create a symbol table file for debugging, but have not found any documentation on the GDB symbol file format.
Are there alternatives to what I have setup?
I do have a RAM overlay for the Flash area. Would this allow software breakpoints?
Thanks in advance for any advice.
I found I can use 'convenience' variables as a substitute for symbols, since I'm not using ever symbol in the program all at once.
set $Symbol=(unsigned int*)<address>
Each 'Symbol' is declared a pointer to an unsigned int at an address. One can put these statements in .gdbinit, and add to them over time.
One can then state
break $Symbol
I show a GDB command function that can be passed one of these 'convenience' variables in the question linked below.
How do I write a GDB function to make a comparison to the program counter
I am trying to extract the execution sequence of my program (something like a program counter) with gdb on my local computer (windows x86) and gdbserver on a remote target (arm-linux). The idea I had was to insert breakpoints at "important" lines of my source files (i.e.: at the beginning of a specific function, and more in general before and after a conditional statement) with a high ignore count for each breakpoint, and then check if a breakpoint was hit or not. I was actually able to receive the informations with this method, but there is a problem: the application behavior I am debugging depends on real-time, and this specific method slows down the program execution too much. Do you think I could use some other method with gdb? I stumbled upon tracepoints, wich seems the exact thing I am looking for, but I was not able to find some property like a "hit counter" for them. The gdb version I am currently using is 7.5.
Thanks a lot in advance.
If your program execution must not be slowed down, you will probably need some HW tool. See these:
Keil real time trace
Lauterbach PowerDebug
(probably other similar solutions)
To learn a bit more about FreeBSD and *nix systems in general, I'm starting to look at the binaries from the DEFCON 17 Capture The Flag game. Right now, I'm reversing the tucod binary. Here's some possibly useful information on tucod:
tucod: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.2, dynamically linked (uses shared libs), FreeBSD-style, stripped
Some other possibly useful information gained from some brief static analysis is that tucod binds on port 0xDEAD (cute, eh?) and if you give it a specific password ("HANGEMHIGH!") it will play a game of hang-man with you.
The problem that I'm encountering is that I'm not hitting my breakpoints in gdb. Specifically, the breakpoint that I'm trying to reach is in the code that handles the client connection. Without breakpoints, the code executes as expected. When I set a breakpoint on that code, the child exits (instead of breaking into gdb, as expected). If I set breakpoints before the server forks off the child, I can hit those fine but after hitting "continue" the child does not continue to process my connection (that is, it won't ask me for a password or play hang-man).
Since the daemon forks when it receives a new connection, I try to tell gdb to follow the child with this command:
(gdb) set follow-fork-mode child
But after single-stepping the instructions after the fork, it appears that this isn't working.
I've tried looking for calls to signal, thinking they implemented a custom SIGINT handler (or similar), but the only call to signal that I can see handles SIGCHLD.
My breakpoint in gdb currently looks like this:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x080497d0
And 0x080497d0 is the address I want to break on in the client processing code.
I'm sort of new to analyzing software on *nix systems and could use some pointers. How else should I go about troubleshooting why GDB will not hit my breakpoints? Or is there something major I'm just overlooking?
There's a torrent available with all of the game binaries for those interested in seeing the binary first-hand.
Look here for the answer. In short, it looks like GDB supports child debug mode only on HP-UX and Linux.