English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   support.WinUAE (http://eab.abime.net/forumdisplay.php?f=5)
-   -   UAE debugger updates (executable debugging, segment tracking, symbols and more) (http://eab.abime.net/showthread.php?t=91321)

bernd roesch 04 April 2018 19:32

Quote:

Originally Posted by Toni Wilen (Post 1232143)
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 04 April 2018 19:51

Quote:

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

Quote:

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 04 April 2018 21:03

Quote:

Originally Posted by Toni Wilen (Post 1230882)
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 04 April 2018 21:06

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 :sad

Tomislav 05 April 2018 11:16

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

DamienD 05 April 2018 11:46

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

Toni Wilen 05 April 2018 11:49

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

Tomislav 06 April 2018 15:15

Quote:

Originally Posted by DamienD (Post 1232363)
Thanks man, no sure why I never tried that standard Windows key combination before :crazy

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

Quote:

Originally Posted by Toni Wilen (Post 1232364)
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 07 April 2018 15:38

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 07 April 2018 19:40

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 07 April 2018 20:42

Quote:

Originally Posted by bernd roesch (Post 1232926)
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 08 April 2018 10:02

Quote:

Originally Posted by Toni Wilen (Post 1232143)
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 19 April 2018 17:00

Crash with uaedbg
 
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 19 April 2018 18:04

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

alpine9000 20 April 2018 14:26

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 20 April 2018 17:41

1 Attachment(s)
Quote:

Originally Posted by Toni Wilen (Post 1235747)
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 20 April 2018 18:09

Quote:

Originally Posted by alpine9000 (Post 1235935)
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.

Quote:

Originally Posted by sigma63 (Post 1235984)
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 21 April 2018 01:39

Quote:

Originally Posted by Toni Wilen (Post 1235991)
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:

Code:

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


Toni Wilen 21 April 2018 10:13

Quote:

Originally Posted by alpine9000 (Post 1236106)
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:

Code:

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


Yes. Comment text should explain it.

alpine9000 21 April 2018 10:16

Quote:

Originally Posted by Toni Wilen (Post 1236122)
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...


All times are GMT +2. The time now is 12:04.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.

Page generated in 0.05093 seconds with 11 queries