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

[bernd roesch]

Originally Posted by Toni Wilen

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.

there is good disassembler library http://aminet.net/package/util/libs/DisLib maybe it is possible to run 68k code from the debugger to disassemble correct all

[Toni Wilen]

where can get amiga.lib and where i need put this ?. amiga.lib is a linker library.

Read the first post carefully, it explains the purpose of amiga.lib.

EDIT: 3F1 error makes no sense because it is debug hunk and they are supported..

there is good disassembler library http://aminet.net/package/util/libs/DisLib maybe it is possible to run 68k code from the debugger to disassemble correct all

Absolute not! It needs to be based on CPU emulator structures. It is only way to enable debugger to do all kinds of nice tricks. (like future plan to actually emulate code internally when disassembling, to get real register contents and correct branches without actually tracing)

[mark_k]

Originally Posted by Toni Wilen

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

If pressing Shift-F12 in full-screen mode causes WinUAE to crash, I think it would be better to just disable/ignore that key combination when in full-screen mode.

[DamienD]

That's a good point mark_k.

...sometimes I accidently press <Shift> + <F12> when is fullscreen mode and then have to bring up Task Manager to kill WinUAE as I'm stuck

[Tomislav]

If you accidentally press <Shift>+<F12> try to exit debugger with <Alt>+<F4>.

[DamienD]

Thanks man, no sure why I never tried that standard Windows key combination before

[Toni Wilen]

Ctrl+C should work. (when debugger window has focus)

[Tomislav]

Originally Posted by DamienD

Thanks man, no sure why I never tried that standard Windows key combination before

No problem.
Anyway, Alt+F4 works only with GUI debugger.
x+<Enter> works for both

Originally Posted by Toni Wilen

Ctrl+C should work. (when debugger window has focus)

Ctrl+C only work when you are in console debugger and (to me) it was by default in GUI debugger. Alt+F4 works only with GUI debugger.

When I switched from GUI to console debugger (xx command) I saw just blank debugger window without text and without prompt. I could only use Ctrl+C to exit emulation.

Next time when I used WinUAE it was console debugger as default. Now when emulation is in fullscreen and I press Shift+F12 it put down emulation screen and switch to console debugger.

When you going to use debugger I think that is better when emulation is in window mode because you can see what is happening in both debugger and emulation.

[bernd roesch]

thanks for upload new version. lawbreaker work now and show symbol info

I use often t or z key. maybe it is possible when use t or z key that this can work so instead of 2 key presses need only one. this can do when press return to execute t or z, the t or z command is written again in input line. so when want do a step, need only press return. if want another command, then can del the z or t

in the disasm output there can with cursor up down move a box. maybe it is easy possible that with the cursor keys the disasm address can change so can scroll thru disasm output and can see previous instructions or later instructions. older dissasemble adresses can keep in a line buffer, so it is possible to look to older adresses again.

[bernd roesch]

Is it possible that there can add an unused opcode in a program with(define with dc.w) that it jump to debugger when this opcode appear ?(when program is start with uaedbg) ?. it is also possible to use 68k illegal instruction to jump into debugger.

[Toni Wilen]

Originally Posted by bernd roesch

Is it possible that there can add an unused opcode in a program with(define with dc.w) that it jump to debugger when this opcode appear ?(when program is start with uaedbg) ?. it is also possible to use 68k illegal instruction to jump into debugger.

$4afc (official illegal instruction) probably is best option.

[demoniac]

Originally Posted by Toni Wilen

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)

...

Thanks for the explanation. Interesting to learn about the internals of the program.

[sigma63]

Hello Guys,

i have problems with this new debug-feature.
With latest v4.0.0 ß 3 (and ß 2, others not tested), i start with Quickstart A3000, 3.1 ROM w/ 2MB Chip+8MB Fast. The only addition is my normal hdf.
Now i open a CLI/Shell und type "uaedbg c:LawBreaker". I immediately get a Crash wich produces a MiniDump-File.
I tested with amiga.lib in plugins\debugger and without -same result.

Is there something missing?

Invoking the non-GUI-debugger with Shift-F12 works OK, with amiga.lib also.
(Loaded 'amiga.lib', 78 libraries, 1342 LVOs.)

Should i attach the Dump and/or logs?

[Toni Wilen]

GUI debugger is not supported in this mode but it still shouldn't crash so attach dump, thanks.

[alpine9000]

In a similar theme to invalid memory accesses causing a debugger break, would it be possible to break if I try and step a floppy drive out of range?

I’m sure this feature would be useful for the 2-3 people that mess around with track loader code each decade ;-)

I’d also be interested if any old track loaders ever try to do this.

[sigma63]

Originally Posted by Toni Wilen

GUI debugger is not supported in this mode but it still shouldn't crash so attach dump, thanks.

Hello Toni,
i think you have mistaken me. I don't expected the GUI Debugger to start.
I thought if i start "uaedbg c:LawBreaker" on amiga-side from Initial CLI would bring up the non-gui-debugger but i get an crash wich generates a minidump.
Its included together with winuae[boot]log.txt
Hope it helps

[Toni Wilen]

Originally Posted by alpine9000

In a similar theme to invalid memory accesses causing a debugger break, would it be possible to break if I try and step a floppy drive out of range?

I’m sure this feature would be useful for the 2-3 people that mess around with track loader code each decade ;-)

I’d also be interested if any old track loaders ever try to do this.

No. Soon there would be hundreds of different breakpoint trigger conditions...

There is already log message, I'll add current PC to message, it should be enough information to find where and when it happens.

I have seen that message ("program tried to step over track 80") few times, some loaders do extra useless step after last track has been read and causes this message if last track was 79.

Originally Posted by sigma63

Hello Toni,
i think you have mistaken me. I don't expected the GUI Debugger to start.
I thought if i start "uaedbg c:LawBreaker" on amiga-side from Initial CLI would bring up the non-gui-debugger but i get an crash wich generates a minidump.
Its included together with winuae[boot]log.txt
Hope it helps

Looks like you are running out of memory. (Windows XP = small per process memory space availability, best case is slightly over 512M or so).

Manually adding smaller debugmem space may help:

debugmem_start=0x70000000
debugmem_size=0x08000000 (or 0x04000000 or even smaller, default is very large)

If it does not work: sorry, XP is unsupported. This debug method by design requires lots of RAM. (hundreds of megabytes). 64-bit OS is recommended.

[alpine9000]

Originally Posted by Toni Wilen

No. Soon there would be hundreds of different breakpoint trigger conditions...

There is already log message, I'll add current PC to message, it should be enough information to find where and when it happens.

I have seen that message ("program tried to step over track 80") few times, some loaders do extra useless step after last track has been read and causes this message if last track was 79.

Actually I think a log message is probably more appropriate for this kind of thing anyway.

I noticed that the check for stepping out beyond zero is commented out:

   /*	else
   write_log (_T("program tried to step beyond track zero\n"));
   "no-click" programs does that
   */

[Toni Wilen]

Originally Posted by alpine9000

Actually I think a log message is probably more appropriate for this kind of thing anyway.

I noticed that the check for stepping out beyond zero is commented out:

   /*	else
   write_log (_T("program tried to step beyond track zero\n"));
   "no-click" programs does that
   */

Yes. Comment text should explain it.

[alpine9000]

Originally Posted by Toni Wilen

Yes. Comment text should explain it.

Yeah, I saw that, was just wondering what the actual deal is with this. HRM says to never do that as it might cause alignment issues, yet it then goes on to say that new drives should ignore this command.

I ran no-click for years on my original A500 and had no issues ;-)

Guess this is getting a bit off topic...