I just started using gdb for basic debugging of active processes. I know I can use disassemble or diassemble(memory address) or disassemble (start), (end). However, I want to disassemble the whole program at once. Is there any way to get the end address of a process I've attached to?
Edit: And I would like to do so without using layout asm
Related
I'm currently playing around with GDB and want to debug a native processor in Android, specifically /system/bin/lmkd.
But I'm having trouble on how to stop GDB once that processor is invoked.
This is what I've tried so far:
Android-side:
./gdbserver tcp:5039 /system/bin/lmkd
Client-side:
gdb
target remote localhost:5039
From here, I typed in info shared, so I could get the base address of the native processor, set the breakpoint, continue, invoke the processor, then it would stop.
But info shared only shows address for shared object files.
Any recommendation on how to set breakpoint on the processor that I don't know the address to?
You should be able to find where the executable itself is mapped in the process's address space with info proc mappings in gdb. If you know the relative offset where you need a breakpoint, you can probably add it to something in there to get the final virtual address to break at.
But it sounds like you might be barking up the wrong tree with respect to getting breakpoints in this process; can't you set breakpoints by symbol name? Can you rebuild the binary with debugging symbols?
I am trying to write a Python script for GDB to trace a function.
The idea is to set a breakpoint on an address location, let the program run and then, when it breaks, log to file registers, vectors and stack and find out what address the next instruction will be, set a breakpoint on that location and rinse and repeat.
I read through the documentation and I'm pretty confident registers, vectors and memory locations can be easily dumped. The actual problem is finding what the next instruction location will be as it requires to analyze the disassembly of the current instruction to determine where the next breakpoint should be placed.
Update
I am doing all this without using stepi or nexti because the target I'm debugging works only with hardware breakpoints and as far as I know those commands use software breakpoints to break at the next instruction
Is there anything like that in GDB?
Yes, you can do this in gdb. Rather than trying to set a breakpoint on the next instruction, you can instead use the si command to single-step to the next instruction.
I have a freescale mpc565 powerpc, I have a copy of the raw firmware I have read from the device and I have decompiled it within Ida pro.
Is it now possible to debug the assembly using trace32 and a bdm without the original elf file and none of the symbol information?
I would like to step through the assembly and view the ram contents.
I could possibly use the trace32 api to write something that will achieve this however I don't know hurdles I will need to jump due to not having the original source of symbol tables.
Any help much appreciated.
Stepping through the assembly and debugging the assembler code (so setting breakpoints etc) is no problem.
But: without the symbol information/original elf file, you are limited to only assembly. Meaning: If you for example try "Break.Set main" (so set a breakpoint onto the entry of the main function), this will not work, because the debugger does not know what address the "main" function has.
The debugger will report "symbol not found" in this example (because it does not know anything about the "main" function).
Additionally the debugger will not be able to display the source code matching to a bunch of assembler instructions.
I hope this helps.
I'm trying to execute print *((int*)0x00401000) command on Kmines(a minesweeper game) with gdb and gdb/mi. While using gdb the command works and returns the output $1=0. But while using same command with gdb/mi it returns the ^error,msg="Cannot access memory at address 0x400000" error. Gdb can definitely access that location, there's no doubt for it. But why gdb/mi can't while gdb can?
I forgot to mention that I use non-stop mode. So because of it, gdb lets the debuggee run while it executes commands and gdb has to stop the process to access proc/pid/mem and read values from it.So gdb won't be able to access the memory if no thread has been stopped.
Edit: Some memory-examination functions such as disas works while some others such as print and x does not. So unfortunately, this answer is partially true.
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