UAE debugger updates (executable debugging, segment tracking, symbols and more)

[Toni Wilen]

Exactly.

Added also break when new stack frame is added (BSR/JSR) or when removed.

It does both checks because without RTS check, it is possible to accidentally return from deep subroutine stack if it never does another BSR/JSR until after 5+ RTS instructions.

Also supervisor mode stack frames are now supported. (Exception/RTE)

I am running out of ideas. Feedback is needed.

[alpine9000]

Originally Posted by Toni Wilen

Exactly.

Added also break when new stack frame is added (BSR/JSR) or when removed.

It does both checks because without RTS check, it is possible to accidentally return from deep subroutine stack if it never does another BSR/JSR until after 5+ RTS instructions.

Also supervisor mode stack frames are now supported. (Exception/RTE)

I am running out of ideas. Feedback is needed.

I hacked my fs-uae debugger so I can configure a text file with symbol/address pairs for use on trackloaded programs that can’t have symbols. I generate the symbol file during the build processs.

[Toni Wilen]

Originally Posted by alpine9000

I hacked my fs-uae debugger so I can configure a text file with symbol/address pairs for use on trackloaded programs that can’t have symbols. I generate the symbol file during the build processs.

Sounds useful but i'd prefer to have symbols in some already existing format. Unfortunately hunk_debug does not have any extra fields to describe type of the symbol..

[alpine9000]

Originally Posted by Toni Wilen

Sounds useful but i'd prefer to have symbols in some already existing format. Unfortunately hunk_debug does not have any extra fields to describe type of the symbol..

I don't really mind which format is used as long as I can get the symbols into the debugger.

It's a bit of a hassle as in my case the symbols are for code loaded from a raw binary blob off the ADF that then gets relocated by my bootloader. So it only works if the symbols match the destination of the relocation.

[Toni Wilen]

What if symbols can be loaded on the fly? (By writing them to some magic address etc..)

[alpine9000]

Originally Posted by Toni Wilen

What if symbols can be loaded on the fly? (By writing them to some magic address etc..)

I guess for me it all depends where they come from. I have a system friendly version of my game I can use to debug 99% of bugs. It’s only the low level stuff I’d normally debug these days in my track loaded version (like the track loader itself). Most of this kind of stuff won’t have gcc compatible symbols any time during the build and will only briefly have vasm:vlink symbols when they are object files before they are converted to raw binary blobs during linking.

[alpine9000]

The other handy feature I added to my fs-uae debugger is gnu readline. I know we have command history in win-uae, but I added all the symbols to it’s tab-completion list. So you can start typing a symbol name then hit tab and either have it complete or get a list of matching symbols. Use it all the time,

[mark_k]

Not specifically related to recent debugger improvements, but...

Pressing Shift-F12 when in D3D11 full-screen mode isn't handled well.

The GUI debugger window can be maximised but not resized. There's a resizing handle at the bottom right, but you can't adjust window size.

It would be nice if the disassembly could be a little closer to "proper" M68K assembler syntax. So for example:
- JSR (-$19E,A6) instead of JSR (A6, -$019e)
- MOVEQ #0,D6 instead of MOVE.L #$00,D6 (same for ADDQ/SUBQ)
- BRA.B instead of BT .B

[alpine9000]

I just tested out the latest version (I was running a couple of versions behind), now I get a breakpoint on a word read from 00000000 (I think) each time an audio channel is used for the first time since reboot. I say this as the CPU has no instructions even close to accessing 0 and the time it breaks.

I get the breakpoint from the P61 playback routines as well as from my independent 4th channel sfx routines.

Once the breakpoint is hit once (and I am guessing that audio channel is primed or something), I can run the app again and it will not break.

Is this expected (ie: is there a bug in my code or the P61 replay routines)?

[Toni Wilen]

Originally Posted by mark_k

Pressing Shift-F12 when in D3D11 full-screen mode isn't handled well.

Not going to be changed. Fullscreen mode has always been unsupported. Debugger has special requirements and it won't automatically fix any of them. You are on your own.

The GUI debugger window can be maximised but not resized. There's a resizing handle at the bottom right, but you can't adjust window size.

I said don't mention GUI debugger! This is final warning! (GUI debugger is not done by me and 100% unsupported by me. I have never used it. It needs total rewrite.)

It would be nice if the disassembly could be a little closer to "proper" M68K assembler syntax. So for example:

Most likely not going to happen.

Originally Posted by alpine9000

I just tested out the latest version (I was running a couple of versions behind), now I get a breakpoint on a word read from 00000000 (I think) each time an audio channel is used for the first time since reboot. I say this as the CPU has no instructions even close to accessing 0 and the time it breaks.

I get the breakpoint from the P61 playback routines as well as from my independent 4th channel sfx routines.

Once the breakpoint is hit once (and I am guessing that audio channel is primed or something), I can run the app again and it will not break.

Is this expected (ie: is there a bug in my code or the P61 replay routines)?

First fetched audio word when audio DMA gets enabled comes from previously played sample's end address (which is zero after power up) which Paula ignores, following word is first real sample word. Paula still needs to see it (AUDxDAT write) because it advances channel's audio state machine, which finally tells Agnus to do AUDxPT to internal register copy (=pointing to beginning of sample).

Basically it is same (but not exactly same) as copper jump side-effect, DMA pointer reset is delayed by one DMA access.

I'll filter out those kind of "invalid" accesses soon..

[alpine9000]

Originally Posted by Toni Wilen

First fetched audio word when audio DMA gets enabled comes from previously played sample's end address (which is zero after power up) which Paula ignores, following word is first real sample word. Paula still needs to see it (AUDxDAT write) because it advances channel's audio state machine, which finally tells Agnus to do AUDxPT to internal register copy (=pointing to beginning of sample).

Basically it is same (but not exactly same) as copper jump side-effect, DMA pointer reset is delayed by one DMA access.

I'll filter out those kind of "invalid" accesses soon..

Great! I suspected it was something like this, as long as it's not a bug in my game I am happy

Slightly OT, I use the serial port for outputting debug prints, is it possible with the TCP option to configure it to use a higher port ? At the moment I have to run WinUAE as admin to get this to work ?

[bernd roesch]

Originally Posted by Toni Wilen

- Does other popular compilers also generate useful HUNK_DEBUG data?

the new debugger look interesting. I like GUI, as an alternate, what do you think, to add features that when double click with mouse on a address in the shell window, with CTRL key press, it list asm dissasamble at this address. with shift it list memory dump ?. when only double click with mouse on a adress it copy the address. so can avoid to type in adresses.

amiblitz and gcc can create amiga os standard debug hunks too. I like test how that work, but please can you give a step by step example how can load in a amiga program and debug it ?

I read JIt must be off, thats no problem when have later a ryzen 2 i tink. it only should work at least in 68020 with FPU in fastest possible mode. does this the new debug code ?.

[Toni Wilen]

Originally Posted by bernd roesch

the new debugger look interesting. I like GUI, as an alternate, what do you think, to add features that when double click with mouse on a address in the shell window, with CTRL key press, it list asm dissasamble at this address. with shift it list memory dump ?. when only double click with mouse on a adress it copy the address. so can avoid to type in adresses.

Console should be able to do that, later.. GUI stuff really needs some proper text based windowing system. There is nothing usable in current one.

amiblitz and gcc can create amiga os standard debug hunks too. I like test how that work, but please can you give a step by step example how can load in a amiga program and debug it ?

AmigaDOS only defines debug hunk as a block of compiler/linker specific data. GCC debug hunk is supported (match source lines to disassembly and more), others most likely generate different debug hunks. Debug hunk information description required.

uaedbg <program name> <program params> (note that there is still something wrong with parameter passing, some programs don't get correct parameters)

Debugger will break automatically when program's first instruction is going to be executed.

I read JIt must be off, thats no problem when have later a ryzen 2 i tink. it only should work at least in 68020 with FPU in fastest possible mode. does this the new debug code ?.

Currently requirement is KS 2.0+, any CPU. JIT should be off.

[bernd roesch]

Originally Posted by Toni Wilen

Console should be able to do that, later.. GUI stuff really needs some proper text based windowing system. There is nothing usable in current one.

I think a gui is not need in the form as it is in current winuae GUI debugger. to avoid type commands there can be add another window that have buttons to click and the commands are add in the main console window. and when a memory or disasm dump want do, this can output to another console window so the main console window can show always the trace instruction display and for insert debugger commands. also register output can do to another console window

[bernd roesch]

I test this version and i notice that CTRL+F12 switch from fullscreen to window mode not work, it quit winiae. only I boot with a Full HD monitor and full HD resolution with Full Window Mode. no uaedbg use for trest. when then press the hotkey it quit winuae. use the winuae gue and change full window to window mode, work ok. when in window mode press CTRL+F12 to switch back to full window, too quit winuae. I use newest win 10 64

[Toni Wilen]

Originally Posted by bernd roesch

I test this version and i notice that CTRL+F12 switch from fullscreen to window mode not work, it quit winiae. only I boot with a Full HD monitor and full HD resolution with Full Window Mode. no uaedbg use for trest. when then press the hotkey it quit winuae. use the winuae gue and change full window to window mode, work ok. when in window mode press CTRL+F12 to switch back to full window, too quit winuae. I use newest win 10 64

If it only happens with winuae.7z: you have to live with it (and it works for me) until official betas appear (which won't be too soon)

[bernd roesch]

with offical newest winuae in 64 bit CTRL+F12 quit screen and reopen it and do nothing change or sometimes crash. only when i switch to window mode in GUI then a window with borders come at position half X half Y full from HD resolution. i can send dmp file from offical version, if you think its usefull

[demoniac]

Originally Posted by Toni Wilen

Most likely not going to happen.

I'm curious on the history of the disassembly syntax. How come it deviated from MC68000 syntax?

[Toni Wilen]

Originally Posted by demoniac

I'm curious on the history of the disassembly syntax. How come it deviated from MC68000 syntax?

I don't know, Bernd did that

But some of the differences are due to not doing extra any conversions, simple direct decoding it, for example BT is technically correct (Bcc + True condition = BT, BRA is only a nice alias)

I already "translated" most useless variants, for example MOVEM which was originally something like MVMEL and MVMLE #value,.. Which was done most likely because MOVEM to memory and MOVEM from memory are actually different op codes (from UAE emulation point of view because they don't implement same addressing modes) and registers are encoded as immediate word, same as MOVE.W #xxxx uses)

Same with other special instructions, instructions that only implement very limited addressing modes or have side-effects and have different "from" and "to" opcode variants (MOVEP, MOVE SR/CCR etc..), UAE disassembler requires them to have different "internal" unique opcode because disassembler opcode is same as instruction emulation opcode function name. Unless extra translation is added.

MMU/FPU instructions (that aren't properly supported in debugger) are even worse because they don't use normal addressing/register bits.

[bernd roesch]

JIT off and window mode. I do somne tests with uaedbg. first i start uaedbg amiblitz and winuae open a windows shell window that fast close and reopen around 30 sec. it is notice as flickering. then the debugger window come. when i press t the flicker happen again

now i try a simple program it is the amiga enforcer testprogram lawbreaker(contain symbols). then winuae opens a windows shell window once and show cant load amiga.lib and unknown hunk id $3f1

winuae continue to work. seem because of hunk id $3f1 uaedbg is not start. what can do ? where can get amiga.lib and where i need put this ?. amiga.lib is a linker library.