Re: [hatari-devel] Debugger features ideas/wishes

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

This is a multi-part message in MIME format.

Hi,

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?
> Not really.
....
> 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.


> Default
> 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
system.

You could just run hatari always with
"--parse options.ini" and put the settings
you like to that file.  For example:
	profile on
	trace os_base
	history cpu 1024
	cd /my/debugger/files/
	symbols etos512k.sym
	lock registers

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
> its window.

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.


> Or,
> 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

Please test.

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
bugs.

(This feature of "next" command should
now also repeat.)


	- Eero