How Does a C Debugger Work? (2014)
blog.0x972.info
How Does a C Debugger Work? (2014)
1–10 of 32 posts
Re: How Does a C Debugger Work? (2014)
#2Re: How Does a C Debugger Work? (2014)
#3Re: How Does a C Debugger Work? (2014)
#4On x86 at least, it is a valid instruction. INT3, or CC in hex. There are also the debug registers which implement breakpoints without modifying any code, although it's limited to a maximum of 4 at once.
Characterising gdb as a "C debugger" is quite appropriate --- try to debug the Asm directly with it is an excruciating experience.
Re: How Does a C Debugger Work? (2014)
#5It writes an invalid instruction at this location. What ever this instruction, it just has to be invalid. On x86 at least, it is a valid instruction. INT3, or CC in hex. There are also the debug registers which implement breakpoints without modifying any code, although it's limited to a maximum of 4 at once. Characterising gdb as a "C debugger" is quite appropriate --- try to debug the Asm directly with it is an excr…
Re: How Does a C Debugger Work? (2014)
#6It writes an invalid instruction at this location. What ever this instruction, it just has to be invalid. On x86 at least, it is a valid instruction. INT3, or CC in hex. There are also the debug registers which implement breakpoints without modifying any code, although it's limited to a maximum of 4 at once. Characterising gdb as a "C debugger" is quite appropriate --- try to debug the Asm directly with it is an excr…
One tool that I started exploring is https://pernos.co/, the ability to do dataflow analysis is super cool. Let's you easily answer the question "How did this value get into this register".
Re: How Does a C Debugger Work? (2014)
#7It writes an invalid instruction at this location. What ever this instruction, it just has to be invalid. On x86 at least, it is a valid instruction. INT3, or CC in hex. There are also the debug registers which implement breakpoints without modifying any code, although it's limited to a maximum of 4 at once. Characterising gdb as a "C debugger" is quite appropriate --- try to debug the Asm directly with it is an excr…
Re: How Does a C Debugger Work? (2014)
#8RISC-V actually did this in a special instruction called ebreak. It can change the CPU privileged mode into Debug Mode.
Re: How Does a C Debugger Work? (2014)
#9It writes an invalid instruction at this location. What ever this instruction, it just has to be invalid. On x86 at least, it is a valid instruction. INT3, or CC in hex. There are also the debug registers which implement breakpoints without modifying any code, although it's limited to a maximum of 4 at once. Characterising gdb as a "C debugger" is quite appropriate --- try to debug the Asm directly with it is an excr…
Really? I use GDB all the time to debug assembly, it's quite good at it. Perhaps there's something much better that I'm not aware of?
WinDbg also lets you set the default base to 16, a feature whose usefulness is greatly appreciated when working with Asm: https://docs.microsoft.com/en-us/windows-hardware/drivers/de... GDB... makes an attempt: https://sourceware.org/bugzilla/show_bug.cgi?id=23390
Re: How Does a C Debugger Work? (2014)
#10Earlier quoted context omitted.
Really? I use GDB all the time to debug assembly, it's quite good at it. Perhaps there's something much better that I'm not aware of?
Having come from a background of WinDbg (Windows) and DEBUG (DOS) before it, GDB feels very "unergonomic" in comparison. The general verbosity (why do you need an asterisk in front of an address when writing a breakpoint --- as the title of this site so prominently reminds?), lack of a regular hexdump command (16-byte hex+ASCII format) and the rather perplexing behaviour of the "disassemble" command ( https://stackov…
what does this mean? watch when the value at the address given by my_ptr changes, or watch when the value of my_ptr changes (i.e. it is modified to point to a different location) ?
gdb) watch * my_ptr
Ah ... now it's clear what is meant.
gdb) watch 0xfeedface
hmm, now 0xfeedface is not a variable but literally an address. But wait, is it? What does this mean? Watch the value at memory location 0xfeedface? But that's totally inconsistent with the semantics of "watch my_ptr". So,
gdb) watch * 0xfeedface
and once again, no ambiguity over what is going on and consistent syntax.
As for you other complaints, I've been programming for about 33 years in C and C++, and I don't recall ever needing to use a hexdump inside the debugger or the disassemble command. Which is not to say that they're not important for some work, but they are also not important for all work.