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.
Related
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.
I am using GDB in remote configuration. So I have gdbserver running on a ARM HW running linux, I connect to remote gdbserver from local gdb, I am able to put breakpoints in initial part of code and ensure that basically GDB works. However when I let my SW run for a while and break to see threads, I don't get useful stack traces for threads. All stack frames are hex addressed none resolving to symbols present in my binaries. Most of them also look the same with gdb also hinting with "same stack frames, corrupted stack ??"
Since SW runs fine with or without debugger I don't doubt my SW. Anybody seen this issue or any idea what might be going on here.
Thanks
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
[b77d0424] open("etc/shadow",0_RDONLY) = -1 EACCESS (Permission denied)
every time i run [b77d0424] changed to another address
i can not use gdb b *0xb77d0424 and then c to find lib64/libc.so.6
it seems not the same mentioned in a linux programming book
after running ubuntu 13.04 in virtual box
every time i run [b77d0424] changed to another address
This is happening because of address space layout randomization, which you can disable with setarch -R command.
GDB also disables address randomization by default, but the chance that the same address you'll get in GDB and under strace is quite small, as the execution environment under the two tools is quite different. You don't actually need to find the address under strace, you can find it in GDB:
catch syscall open
run
You are now looking at one of the open system calls your program does. Use continue until you stop at the one you are interested in. Now use info registers to find the address of the first parameter, and set a watchpoint on that address.
im using GDB to debug a C code in eclipse, and i wanted to ask a question about the GDB handling multiple commands.
if i send the GDB multiple commands through an external software for example:
im sending 'bt', and 'p counter', and than 'help'.
is it possible that the 'bt' command is taking too long to process and return an answer that the GDB will suspend the 'bt' command handling and will try to handle the next command?
it doe'snt make sense to me if it did, but it is important for me to know if it is possible.
i checked in google and i have read the gdb tutorial but never found explanation about the GDB handling commands that are sent to it.
thanks.
Check GDB Internals which talks about many important GDB operations and algorithms. If you have time it is good to dig deeper by looking at GDB source code to understand well.