Symbol listing in Hatari debugger?

[simonsunnyboy]

Is it possible to list the loaded symbols inside Hatari's debugger? I get a "Loaded xxxx symbols from xxx.prg message"

It is is nice to see it loads symbols but if I don't remember some of them, it is tedious to make use of them.

Is it possible to implement some sort of "list symbols" command?

[explorer]

Use 'v' command.

[simonsunnyboy]

Code: Select all

> symbols conio.sym
Reading 'nm' style ASCII symbols from 'conio.sym'...
WARNING: syntax error on line 106, skipping.
WARNING: symbols '_basepage' & '__bss_start' have the same 0x115c address.
WARNING: symbols '_assert_init.part.0' & 'CMakeFiles' have the same 0x4d0 address.
WARNING: symbols '_basepage' & '_edata' have the same 0x115c address.
WARNING: symbols '__bss_start' & '_edata' have the same 0x115c address.
WARNING: symbols '_end' & '__end' have the same 0x11cc address.
WARNING: symbols '_etext' & '__etext' have the same 0x115c address.
WARNING: symbols '__edata' & '_etext' have the same 0x115c address.
WARNING: symbols '_basepage' & '__edata' have the same 0x115c address.
WARNING: symbols '__bss_start' & '__edata' have the same 0x115c address.
WARNING: symbols '_edata' & '__edata' have the same 0x115c address.
WARNING: symbols 'CMakeFiles' & '.LC0' have the same 0x124 address.
WARNING: addresses 0x4d0 & 0x124 have the same 'CMakeFiles' name.
WARNING: addresses 0x17c & 0x570 have the same '.L2' name.
WARNING: addresses 0x124 & 0x1038 have the same '.LC0' name.
Loaded 108 symbols from 'conio.sym'.
> v
Hatari debugger builtin symbols and their values are:
  - AesOpcode: $FFFF / #65535 -- $FFFF when not on AES trap
  - Basepage: $14964 / #84324 -- invalid before Desktop is up
  - BiosOpcode: $FFFF / #65535 -- $FFFF when not on BIOS trap
  - BSS: $15BC0 / #89024 -- invalid before Desktop is up
  - CpuInstr: $0 / #0 -- CPU instructions count
  - CpuOpcodeType: $1 / #1 -- internal CPU instruction type
  - CycleCounter: $9516BEC / #156330988 -- global cycles counter (lower 32-bits)
  - DATA: $15BC0 / #89024 -- invalid before Desktop is up
  - DspInstr: $0 / #0 -- DSP instructions count
  - DspOpcodeType: $1 / #1 -- internal DSP instruction type
  - FrameCycles: $27244 / #160324
  - GemdosOpcode: $FFFF / #65535 -- $FFFF when not on GEMDOS trap
  - HBL: $139 / #313
  - LineAOpcode: $FFFF / #65535 -- $FFFF when not on Line-A opcode
  - LineCycles: $44 / #68 -- is always divisable by 4
  - LineFOpcode: $FFFF / #65535 -- $FFFF when not on Line-F opcode
  - NextPC: $E0FB28 / #14744360
  - TEXT: $14A64 / #84580 -- invalid before Desktop is up
  - TEXTEnd: $15BBF / #89023 -- invalid before Desktop is up
  - VBL: $3CF / #975
  - VdiOpcode: $FFFF / #65535 -- $FFFF when not on VDI trap
  - XbiosOpcode: $FFFF / #65535 -- $FFFF when not on XBIOS trap
>

This lists only intenal symbols (where they are sourced from but none from by debugee "contio.tos" in this case.

[npomarede]

Funny, I just asked myself the same question a few minutes ago on one of my program
Type "symbols name"

[simonsunnyboy]

I would have expected that one on "symbols" without any further arguments...but that seems to be working ok.

Thanks

[npomarede]

Yes, I also tried "symbols" alone without success, could be an alias to "symbols name" indeed

[Eero Tamminen]

Done: https://hg.tuxfamily.org/mercurialroot/ ... d0dfa775f2

I just wonder why listing them in name order instead of address order is more expected.

[npomarede]

Done: https://hg.tuxfamily.org/mercurialroot/ ... d0dfa775f2

I just wonder why listing them in name order instead of address order is more expected.

Because it's easier to find a symbol in an alphabetical-sorted list
Most of the time, you know you're looking for a particular symbol (variable name, function name) and you want to show memory/disasm, so looking for the name in a sorted name-list is the natural way to go.

[Eero Tamminen]

If you're looking just for the name of a symbol, why not just press <TAB> instead?

Readline TAB-completion gives you much more condensed list of (alpha-sorted) symbols:

Code: Select all

> address _<TAB>
Display all 451 possibilities? (y or n)
_Getcookie                    ___mpn_mul_n                  _atof                         _mt_appl_find
___PRETTY_FUNCTION__.3476     ___mpn_rshift                 _atoi                         _mt_appl_init
___PRETTY_FUNCTION__.3649     ___mpn_sub_n                  _base_table                   _mt_appl_write
___access                     ___mpn_submul_1               _bcopy                        _mt_evnt_button
___adddf3                     ___muldf3                     _binops                       _mt_evnt_multi
___addxf3                     ___muldi3                     _blanks                       _mt_evnt_timer
___assert_fail                ___mulsi3                     _bzero                        _mt_form_alert
...
--More--


[npomarede]

People have their own habits If you're used to monst (which can display the list of symbol with the "l" key), then having a list sorted by name is fine.

[simonsunnyboy]

Done: https://hg.tuxfamily.org/mercurialroot/ ... d0dfa775f2

I just wonder why listing them in name order instead of address order is more expected.

Because it's easier to find a symbol in an alphabetical-sorted list
Most of the time, you know you're looking for a particular symbol (variable name, function name) and you want to show memory/disasm, so looking for the name in a sorted name-list is the natural way to go.

+1 for alphabetical sort

Tab completion is certainly not taste for a debugger. I still hope for a graphical ui to the Hatari debugger anyway.

[ThorstenOtto]

I still hope for a graphical ui to the Hatari debugger anyway.

No one will stop you from writing one

[simonsunnyboy]

I know but my skills for GUI coding are not so good. A reason why I do not write GEM applications...the proper idea would be to expand what hatariui already offers.

Sadly I am no Python wizard either

[Eero Tamminen]

The reason why Hatari Python UI debugger part is so rudimentary is that I soon found out that making out-of-process GUI debugger which gets ASCII output through FIFO and parses that, isn't performant enough, and keeping changes on Hatari side in sync with Python GUI is too error prone. Supporting even simplest breakpoints through that would have been way too painful.

I.e. proper debugger GUI needs need to be in-process. And it needs real GUI toolkit, SDL isn't enough for that. There were some mails about writing Qt GUI for Hatari on hatari-devel, but one of the problems with that would be how to integrate e.g. Qt & SDL input handling together. And in general, breakpoint functionality would have needed to be simplified quite a lot to support GUI (doc/todo.txt in Hatari sources has some notes about that).

All of that would be a really large rewrite, I think at least half a year of full time work if one wants to support most of current debugger functionality.

[ThorstenOtto]

And it needs real GUI toolkit, SDL isn't enough for that.

Of course a real GUI would be nicer, but you can do also a lot by using SDL. Look at Steems debugger, which does exactly that. And it has the benefit that you don't have to care about two systems fighting your input events.

All of that would be a really large rewrite, I think at least half a year of full time work

Maybe. But you could start with some basic functionality, then implementing other features that are currently supported.

[npomarede]

And it needs real GUI toolkit, SDL isn't enough for that.

Of course a real GUI would be nicer, but you can do also a lot by using SDL. Look at Steems debugger, which does exactly that. And it has the benefit that you don't have to care about two systems fighting your input events.

Hi, I agree GUI would need a revamp, but there's a difference between Hatari's UI and Steem's X UI : Hatari's UI is mainly character based (ie you can only put char or put line on a fixed character position), while Steem's dev used their own toolkit, which is X11 based, and can really do gfx/txt on a pixel level.
In the end, it makes it rather more complicated to improve Hatari's UI at the moment, better rewrite a new one from scratch using QT (have a look at FS-UAE to see that QT + SDL can get great results), but as already said, it takes a lot of time.
Nicolas

[ThorstenOtto]

while Steem's dev used their own toolkit, which is X11 based, and can really do gfx/txt on a pixel level.

You can do the same using SDL. The builtin SDL gui for configuration does that already, using a compiled-in font.

better rewrite a new one from scratch using QT (have a look at FS-UAE to see that QT + SDL can get great results)

The problem with Qt and/or Gtk is that is it mostly unix based. You will have a hard time to deliver a working Qt stack for Win32 and/or MacOS, not to speak about a development environment.

but as already said, it takes a lot of time.Nicolas

Shouldn't be too hard to get a simple frame working, that just displays some assembly lines, cpu registers etc. From there you can start adding features from the current debugger.

[npomarede]

The problem with Qt and/or Gtk is that is it mostly unix based. You will have a hard time to deliver a working Qt stack for Win32 and/or MacOS, not to speak about a development environment.

Not sure about that, as far as I know FS-UAE users on Windows/OSX are quite happy with the result
GTK might not be WIN32/OSX "compliant" but QT certainly works quite nicely under all 3 OSes, there're several applications that work on all 3 OSes using QT and result is certainly good enough for what Hatari would need.
I think there's no point in developping further our own toolkit and to add new functions to it (but of course, anyone is welcome to spend time on it if he wants )

Nicolas

[Eero Tamminen]

Shouldn't be too hard to get a simple frame working, that just displays some assembly lines, cpu registers etc. From there you can start adding features from the current debugger.

What your patch for implementing that to Hatari would look like? Would you implement it with a window separate from Hatari window, or draw it to the already existing Hatari window?

[ThorstenOtto]

Would you implement it with a window separate from Hatari window, or draw it to the already existing Hatari window?

When using SDL, you could only use the existing window (unless you plan to drop support for SDL 1.x, but setting up a separate window in SDL for the debugger would make things a bit more complicated).

Actually, it wasn't steems debugger that i had in mind, i mixed that up with something i had seen in an Apple ][ emulator, which looks like

[Eero Tamminen]

Yes, I was wondering whether you were considering doing it SDL2-only. Anyway, I'm interest to see your prototype code.

(Your screenshot of the other emulator looks really bare bones, I'm not really sure whether something that primitive would be any kind of improvement over current console debugger.)

[ThorstenOtto]

Anyway, I'm interest to see your prototype code.

Hm, did i say i'm going to implement that?

I'm not really sure whether something that primitive would be any kind of improvement over current console debugger.

I'm not sure how others think about this, i myself don't use the hatari debugger too often, but for me it already looks much better than the current console output. You have all important information constantly at hand, without having to type any command. Most commands like step over/step into etc are single keystrokes. Whats also nice is that it already does address decoding, the third column shows the memory that is accessed by the instruction.
Ok, it does not have all those nice looking icons, and looks more like an ascii terminal, but do we really need that in a debugger? And it adds a bit to the retro feeling

[Eero Tamminen]

Hm, did i say i'm going to implement that?

<atari-forum-hypnosis>
No, but you're having an irresistible itch about it that you cannot help scratching, aren't you?
</atari-forum-hypnosis>

[ThorstenOtto]

No, but you're having an irresistible itch about it that you cannot help scratching, aren't you?

I already wondered where that is from.

[Eero Tamminen]

Dang, the forum SW is acting again, it's revealing the "secret" tags. I'm pretty sure I've been targeted by them too, based on few programming itches I had earlier.

Anyway... If you really happen to take a look at the visual debugger, one of the problems of using the same window is that Hatari's SDL frame buffer size can be anything between 320x200 (unzoomed ST-low) and 2048x1280 (max VDI res), and the size can change at any moment, e.g. because user toggled ST/STE borders or emulated Falcon code changed Videl registers. Separate window would be nicer because then window size can be based on debugger content, instead of content needing to adapt to changing framebuffer size.