I'm writing a kernel which is compiled as a PIE. After boot the kernel maps itself into 64-bit high mem, specifically the NULL page moves to 0x1FFFF << 0x2F, and then jumps there however in doing so GDB loses track of the code that accompanies the assembly. I lose the ability to set breakpoints(doing so triggers my breakpoint ISR instead of GDB) and am forced to step one instruction at a time through my C with nothing but assembly showing in GDB. Is there some way I can change the base address of my kernel executable in GDB at runtime. I'm connecting to QEMU's GDB server for debugging.
Is there some way I can change the base address of my kernel executable in GDB at runtime
This should work:
(gdb) add-symbol-file kernel_exe 0x.... # where 0x... is the relocated address of .text
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 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
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
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.