bob_fossil wrote: ↑Mon Dec 25, 2017 4:27 pm
... we are talking about emulators here not fully blown C IDEs.
From my perspective I don't see how this is easier for me or less work for an emulator developer to provide me with the option to treat a specific opcode sequence as a command to break into the debugger than it would be to have to load in and parse generated compiler symbol files to achieve the same thing?
I believe you need a bit of the 80's spirit, and not expect to have everything, because as you say, these are emulators and not IDEs.
The benefit here, is when the emulators accept the symbol as a variable, or a variable + something.
- breakpoint at MY_FUNCTION
- breakpoint at MY_LABEL (you can defined LABELS anywhere in your code, including before the line you want to test or pause execution at)
Another real advantage, is that you do not need to stop on that line every single time, when you have a defined breakpoint, you can disabled it, during debugging, or use breakpoint counting (in some emulators), where you only stop at the Nth time you go over it, or even better, when a specific condition is true.
However, if you have a specific opcode instruction in your code to call debugger and interrupt execution, it will force you to stop everytime it executes that instruction.
If the emulator allows it, and supports code rewrite by user, you can overwrite the opcode with NOPs, but that is not super simple either, since it requires some manual input again.
An emulator that supports symbols, typically will also support using those symbols directly, in breakpoints, setting values or similar inputs.
Note however, that most do not save the setting by name, so that it will stick on your next launch of the Emulator.
Alternatively (I use this trick a lot), I keep my emulator open, with breakpoints defined, during my entire debugging session, which keeps all breakpoints in the correct spot (given the correct care). I then open, re-open or drag & drop the new compiled app, into the running emulator.
If you know which code you are changing while debugging, the function location will be kept in the exact same spot, as long, as you do not alter any other code that comes before it in memory.