|Re: [hatari-devel] Debugger features ideas/wishes|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
This is a multi-part message in MIME format.
On 6.9.2021 9.54, Miro Kropáček wrote:
On Mon, 6 Sept 2021 at 01:46, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
Would using 'history' command help?
One problem is some instructions have different
sizes, so disassembly output is potentially wrong
in the beginning when it's started from fixed
negative PC offset.
I could totally live with that (as I do now when doing "pc-16").
While you can, problem is that it could totally
confuse debugger newbies, but I could add an
option for the disassembly PC offset which
defaults to zero.
history enabled could help here a bit, too (IMHO it is better to have a
slightly worse debugger performance when gains are so big).
Default enabled debugger features slow down things
for everybody, even for people who never use it,
and who try to use Hatari on totally underpowered
You could just run hatari always with
"--parse options.ini" and put the settings
you like to that file. For example:
history cpu 1024
Last one shows all CPU registers when entering
debugger, instead of the default info.
When profiling is enabled and symbols are present, you get also
backtrace to where you are in code
(this is especially useful when debugging monster
code bases like Linux kernel or BadMood).
Another problem is that debugger does not actually
know at which address breakpoints are, because
they are for all kinds of conditions, not just
(or even mostly) for PC addresses.
I suspected that much -- but I think at one point a decision has to be made
that the disassembly output can't be just blindly taken from the WinUAE
code but it needs to be "smarter". That reminds me, how is this solved in
WinUAE itself? It surely doesn't show just raw disassembly from the core in
I haven't used that. Toni, or maybe Nicolas
needs to answer this.
SHIFT+ENTER isn't a possibility? (not sure how that parsing works)
Nope. Readline library is called to provide
the line, and it implements all line editing.
again, make it configurable. For me the price of an accidental step is much
lower than the annoyance of repeating two key presses again and again (one
can argue that I can press the up arrow more than once by accident and
execute a totally different command so it's not fool-proof either).
Attached patch set implements:
* repeating "step" & "next" commands
* debugger config option for disassembly offset
* Marking PC address in disassembly output
Nicolas, as you probably use the related
debugger features more that I, maybe you could
also comment on them?
Is use of 'n <instruction type>' not of help,
e.g. "n return"?
Not always but thanks for reminding me about this feature! :)
Note that this feature is not very
extensively tested, so there may be
(This feature of "next" command should
now also repeat.)