Debugger console enhancements

[eToThePi-i]

Potentially relevant to the UI debugger

• Add a command (multiple commands?) to see a list of active watchpoints and breakpoints. Possible syntax: list <watchpoints|breakpoints>, list <w|b>.
  • (The GUI could definitely allow for the best management.)
• Add a mode for watchpoints to see writes where the value is actually changed (as opposed to a preservation of the previous value, like 0x00000000 -> 0x00000000).
• Indicate register changes during instruction-by-instruction debugging.
• Maybe yellow highlight register that's about to be changed by the current instruction, and red highlight a register that was changed in the previous instruction.
• Watching a byte that is already being watched doesn't return an output. A more desirable set of behaviors would be:
  • If the new watch command is using the same mode return the output "Byte 0xXXXXXXXX is already being watched"
  • If the new watch command is using a different mode, the watch mode for that byte should be updated to the new mode (e.g. going from read to write)
• Capitalization of alphabetical hex values should be consistent between reported byte changes.
  • e.g., currently it displays (new value = 0x003e006a, old value = 0x003E006A), but it should either display:
    • (new value = 0x003E006A, old value = 0x003E006A)
    • (new value = 0x003e006a, old value = 0x003e006a)
    • (Capitalized probably looks better than lowercase, because then all the characters are the same height.)
• Watchpoints: Allow watching for register changes.
• Watchpoints: Allow watching for changes to a specific value.
• Add the ability to configure a cached queue of traced commands of size N, so that one can backtrace from the current command.

Only relevant to the (current) CLI debugger console

• Allow up/down scrolling through previous commands
• Allow tab completion of command names, allowing multiple consecutive tabs to cycle through the options if the desired command is ambiguous. This could eliminate the necessity for all of the shortened aliases, since any command would be 2-3 command presses away. If the aliases remain, it would be preferable not to include the shortened ones in the tab completion.
• Group command aliases under the same line in the help command, and mention them when requesting the help for a specific command. I'm also unclear why break/X and disassemble/X are grouped under ARM commands instead of just grouped with break and disassemble command Aliases:
  • b, break
    • b/a, break/a
    • b/t, break/t
  • c, continue
  • d, delete
  • dis, disasm, and disassemble
    • dis/a, disasm/a, and disassemble/a
    • dis/t, disasm/t, and disassemble/t
  • h, help
  • i, info
  • n, next
  • p, print
    • p/t, print/t
    • p/x, print/x
  • w, watch
    • Inconsistency: watch has the /r and /w variants, but they are missing from w. This is because there is an already existing command for writing registers, w/r, which should probably be renamed to wr with aliases writereg and writeregister.
• The help description of d, delete should be updated to "Delete a breakpoint or watchpoint"

[endrift]

Whether or not I do this depends on if I remove this feature after adding the UI. I thought I'd done this in 0.6 but I guess I missed it.

[endrift]

Whether or not I do this depends on if I remove this feature after adding the UI. I thought I'd done this in 0.6 but I guess I missed it.

[eToThePi-i]

It might not be worth maintaining the command line, but I've started listed some possible enhancements for it here anyway. It's worth noting that some of these are not only applicable to the CLI, but also to the design and usability of the planned GUI debugger. I've included all the ones that are applicable to both near the top of the list.

[eToThePi-i]

It might not be worth maintaining the command line, but I've started listed some possible enhancements for it here anyway. It's worth noting that some of these are not only applicable to the CLI, but also to the design and usability of the planned GUI debugger. I've included all the ones that are applicable to both near the top of the list.

[eToThePi-i]

@endrift So I'm still unclear: if I have more suggested improvements for the debugger console, do you want me to add them to this issue? Or would you prefer I make new issues? Or is there some discretionary line by which certain issues should be separate, but others could be grouped?

Because you said: "I actually do want things split out (for this at least) so I can close them one by one.", but then you said "So, many of them apply to the SDL debugger too... so I want to keep the list even if I remove it from the Qt version." Also, I note that in a previous thread in 2015, you said "Moreover, it's good to separate logically distinct items as separate bugs instead of clumping them into meta-bugs like this." and I'm not sure if these should be classified as logically distinct bugs or not.

[eToThePi-i]

@endrift So I'm still unclear: if I have more suggested improvements for the debugger console, do you want me to add them to this issue? Or would you prefer I make new issues? Or is there some discretionary line by which certain issues should be separate, but others could be grouped?

Because you said: "I actually do want things split out (for this at least) so I can close them one by one.", but then you said "So, many of them apply to the SDL debugger too... so I want to keep the list even if I remove it from the Qt version." Also, I note that in a previous thread in 2015, you said "Moreover, it's good to separate logically distinct items as separate bugs instead of clumping them into meta-bugs like this." and I'm not sure if these should be classified as logically distinct bugs or not.

[eToThePi-i]

I'm pinging you, @endrift, I hope you don't mind. I suppose Github probably automatically informs you when new comments are added to issues in the project, but I just want to ensure this gets to you

So, I'm still unsure whether you want these issues separate or combined. Since I just added another one (Indicate register changes during instruction-by-instruction debugging.), I thought now might be a good opportunity to ask again. This is particularly a special case, since some of these suggestions concern a component you're actively developing, which could be useless if you are currently planning to add things on this list or have already added them. Thoughts?

[eToThePi-i]

I'm pinging you, @endrift, I hope you don't mind. I suppose Github probably automatically informs you when new comments are added to issues in the project, but I just want to ensure this gets to you

So, I'm still unsure whether you want these issues separate or combined. Since I just added another one (Indicate register changes during instruction-by-instruction debugging.), I thought now might be a good opportunity to ask again. This is particularly a special case, since some of these suggestions concern a component you're actively developing, which could be useless if you are currently planning to add things on this list or have already added them. Thoughts?

[endrift]

That's a good thing to add to the list.

[endrift]

That's a good thing to add to the list.