| Re: [hatari-devel] Debugger features ideas/wishes |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
(Toni, there's a question on WinUAE CPU core
disassembly support for you below.)
On 5.9.2021 13.30, Miro Kropáček wrote:
As I have been using the debugger quite intensively the past few weeks, I
have noticed some patterns where I have been doing things quite
inefficiently (that came to my mind esp. after seeing Tat's debugger).
The most important thing -- I never know where I am in the code.
For example, I set up a breakpoint somewhere, it's hit. I press "d' which
shows me the current PC (i.e. where the breakpoint is). But that rarely
suffices, I need to look up a few instructions, so I type something as "d
'pc-16'" to see some context. Then I of course forget which address was the
actual BP (esp. when looking back as far as 32, 64, 128 bytes).
Would using 'history' command help?
It would be
much, much better if there was a way to show the disassembly output in the
way that the BP is in the middle, in bold/with an indicator/whatever and I
could see instructions around it in both directions automatically.
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.
Disassembling from PC means that it always starts
from correct instruction boundary. :-)
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.
(For now "address" command is just alias for
conditional breakpoints, so using that does not
help.)
While some of above information is in the
debugger history, that and dissassembler are
completely separate functionalities, and user
also needs to separately enable history tracking.
(All such debugger functionality is enabled
separately to minimize debugging overhead.)
Another thing is that "d" command. It works quite confusingly - when I hit
a BP, "d" is equal to "d pc". But when I type "d" again, it moves to the
next N instructions, depending on screen height.
[Debugger] section in Hatari config file has
variables to control how much output there is
in specific situations:
--------------------------
nBacktraceLines = 0
nDisasmLines = -1
nMemdumpLines = 4
nSymbolLines = -1
--------------------------
So you can limit it to smaller amount
("-1" is unlimited, i.e. until screen end).
And even more confusingly,
if I just press ENTER, it repeats "d", i.e. moves down further. It's a
useful feature but then I'm totally lost whether I'm still looking at PC or
PC+screen size, there's basically no indication (see the previous
paragraph) so what I do is that I always type "d pc", which seems like a
waste.
Would it be better if:
* "d" would always show disassembly from current
PC unless an address is specified?
* ENTER would still advance the disassembly?
This is related to stepping -- so "d" works with ENTER (which is sometimes
nice) but "n" and "s" do not? Why?
I think there were 2 reasons:
* Stepping requires exiting the debugger, so
extra global state is needed, to remember what
command was used on previous debugger entry
* Disassembly not changing emulation state, while
stepping does, and recovering from stepping
accidentally (too much)[1] is not really viable
for hard to reproduce bugs
I could look into providing some hack patch for
testing how usable it's to use ENTER for repeating
also those commands.
[1] In graphical / "fullscreen" debuggers,
there's a separate keyboard shortcut for this,
which reduces accidents. Unfortunately that's
not an option for line based debuggers, like
the one in Hatari.
> This would be much more helpful than n,
> enter, arrow up, n, enter, arrow up, ...
Is use of 'n <instruction type>' not of help,
e.g. "n return"?
Address / truth prediction - this is really, really misleading when looking
at disassembled code. I press "d" and I see all sorts of addresses and T/Fs
-- but only one kind is actually true and that is (d)bcc destination
address. All the others -- like (an,d) calculation and [content of such
address], condition code results -- is mostly a lie because it calculates
*current* content of registers and not the values when it will actually
reach the point in code (understandably). I would be much happier if there
was nothing rather than this misleading information. I bit myself numerous
times, especially if that's true for RECORDED history, here I absolutely
don't get it -- it's useful only for stored PC addresses/(d)bcc codes dump,
all the other information is garbage because it doesn't reflect reality! If
we have a limit of 64 instructions here, couldn't Hatari store also the
whole context (registers, content of the memory when reading/writeing
something etc) so one can actually see what *really* happened?
The problem is that disassembly is completely independent functionality,
which history, profiler
etc invoke. It's part of WinUAE CPU core and does
not currently provide option for skipping the
potentially obsolete reg value information.
Toni had mentioned earlier that he's not against
adding options to the disassembly output.
Toni?
I can't remember anything else for now, just some food for thought, maybe
others have similar problems?
Also, having all said that, Hatari & its debugger has been invaluable help,
these are just suggestions to make it even better! :)
Thanks for suggestions!
- Eero