02 February 2021, 19:33 | #21 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
To be honest I'd be happy if you got rid of the gui because I sometimes type 'xx' by accident and it goes into it.
I find the cli absolutely fine and appreciate it very very much. The only thing that slightly annoys me about it is that it breaks into a huge window sometimes and I have to keep resizing it. |
02 February 2021, 19:36 | #22 | |
Registered User
Join Date: Jun 2020
Location: Druidia
Posts: 386
|
Quote:
Unlike garbage like the Qt library. I've used a branch that allows panes to be pealed off the main window. It's pretty amazing how it all works without needing to add any extra code. Anyway, I highly recommend it for any game dev UI work. |
|
02 February 2021, 20:27 | #23 |
Registered User
Join Date: Jan 2011
Location: -
Posts: 728
|
|
02 February 2021, 21:17 | #24 |
Registered User
Join Date: Jul 2005
Location: -
Posts: 1,686
|
|
02 February 2021, 21:38 | #25 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,406
|
For some reason, I've always found the text debugger to be harder to work with than the GUI one. It's probably because the GUI debugger shows several handy bits of information at the same time in the same window.
It's not the actual commands, I can work with text based commands no problem. Then again, I probably should somehow transfer over to something like MonAm for debugging. Just not too sure how that would work if you kill the entire system in your program. Is there a main/big thread about generic debuggers or MonAm? Don't want to get too far off-topic here |
02 February 2021, 22:10 | #26 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
it doesn't help, the system dies. What I do is have a directive which switches off all the system killing assembler. Then I can freely debug the routines - a lot of the stuff I do doesn't actually do any screen stuff anyway.
|
02 February 2021, 23:34 | #27 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,160
|
I used HRTmon on the A1200, and also used the built-in hrtmon in winuae, but I found the Winuae text debugger more powerful.
At first it was horrible because I didn't know the command syntax, and if you make a mistake, the parsing just ignores the command... But I'm using windows 10 with a proper console, fast copy/paste, and that's pretty good actually. I can pre-record / generate debug commands (breakpoint / print value / go ...) to automate some debugging, then feed the output to a python script that generates code for me (did that for TFX emulated FPU instructions). One annoying issue is that CTRL+C copies text ok, but if you haven't selected any text it breaks and quits WinUAE... argh... Another issue is when debugging keyboard interrupts, if you type "g"+RETURN, the return key is intercepted by the amiga program... grrrr. To workaround that, I just copy/paste g+a linefeed from a windows console or a previous "g" command. Entering without pressing any key is easier: end+F12. Also turn off JIT to be able to use memwatches. A 100% reference guide would be handy. There are a lot of undocumented commands and options that I often forget. Only Toni knows them... Best features: - read/write/change memwatches. You can have this with whdload+hrtmon but it's limited and slows down the machine - breakpoints that check program counter, not with illegal opcodes: means that you can put your breakpoint anytime, even if the code isn't already loaded there (also helps with on-the-fly decrypt routines that also check trace vector!!) - trace without trace vector - deep trainer, which requires a lot of memory but we have a lot of memory Invaluable. - copper debug: you always know where the copper points to. You can also trace the copper (never used it) - comprehensive disassembly, showing the values of the memory held/pointed by registers - assembler too (a command) Last edited by jotd; 02 February 2021 at 23:40. |
03 February 2021, 01:23 | #28 | |
Registered User
Join Date: Jan 2011
Location: -
Posts: 728
|
Quote:
Time consuming to read through trying to figure out exactly what each option is though. Still better than nothing. It doesn't have to be only Toni that knows |
|
03 February 2021, 09:15 | #29 |
Registered User
Join Date: Nov 2015
Location: Italy
Posts: 191
|
Btw debug feature idea:
Have a "flag array" for each emulated RAM address. A command in the debugger shall then tell the emulator that from then on it should flag each address that is being executed (whenever instruction is read from PC). Another command to tell the emulator that is should un-flag each address that is being execute. Another command to show the flagged addresses in debugger (or visually in GUI). So then for example in a game you could play a level, use the flag-command in the debugger, scroll and play around in a level for some time, go to debugger and use the unflag-command, keep playing around in the level but this time without causing scrolling. After some time go into debugger and make it show the flagged addresses. Then you should get a quick hint where the code is that handles scrolling of the game. |
03 February 2021, 09:58 | #30 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
|
|
03 February 2021, 14:39 | #31 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,160
|
for code in chipmem there is a heatmap feature (vh). But the results are pretty obscure
What I would like would be a feature to show the number of times a location is executed, using blocks/grouping. I think that's heat map does but I really can't interpret the figures. |
03 February 2021, 17:57 | #32 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
First off I'd just like to say that I very much appreciate the work Toni does on the debugger, WinUAE is simply an awesome emulator and I love it.
If there's a feature request that I would like it would be for the ability to run a stack trace, especially useful for when symbols are available. Even if it just reported which function it's going to land back into would be a huge benefit (at least for me). |
03 February 2021, 19:19 | #33 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,160
|
stack trace is a fake easy thing to do. If you use stack to pass parameters, or LINK instruction, or saved registers, you have to know the stack frame structure (debuggers like gdb do that but I must admit I find that slightly magical) to know the callers.
you can dump raw stack, but saved registers will mix with calling addresses (+4 or +6 depending on BSR/JSR, this is also another issue) |
03 February 2021, 23:18 | #34 |
WinUAE 4000/40, V4SA
Join Date: Apr 2020
Location: East of Oshawa
Posts: 538
|
Why not just have some debugger wire protocol that can be used by another app for people who don't like the console? That way the debugger GUI can also just be removed entirely from WinUAE as well. That's how gdb frontends work. If anyone decides they do want to maintain the existing debugger GUI it can be done as an external project out of Toni's way.
|
04 February 2021, 13:46 | #35 | |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
Quote:
For other ABIs, like the PPC V.4 or PowerOpen ABI, this would be no problem, as the stack frame has a fixed format and each frame is linked by a pointer. |
|
04 February 2021, 13:59 | #36 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
i may be missing the point here but all the stack frame has to determine is which routine it is coming back to (call back from bsr/jsr). if one cant be determined then it’s assumed to be a parameter pushed onto the stack. Even that would be helpful for me.
|
04 February 2021, 17:24 | #37 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
It's not that easy. There may be anything on the stack when you have a breakpoint somewhere inside a function. Parameters, saved registers, local variables, huge data arrays. In such a situation you have often no way to find the caller's return address by just looking at the stack.
The only solution would be when the 68k emulator tracks all sub routine calls in its own list and make them available to the debugger. (This still doesn't explain how the backtrace in native debuggers works.) |
04 February 2021, 18:52 | #38 | ||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,502
|
Quote:
b) Having stable API in emulator's debugger (that can do all kinds of weird things) is impossible. Quote:
|
||
04 February 2021, 20:08 | #39 |
Joy Division
Join Date: Nov 2006
Location: East Yorkshire
Age: 60
Posts: 239
|
uaedbg
Download link from http://eab.abime.net/showthread.php?t=91321 doesn't appear to work any more.
|
04 February 2021, 21:07 | #40 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,160
|
@phx you can "guess" the stacktrace by first filtering out odd addresses, or invalid addresses (define "invalid" on a 32 bit system with a lot of memory banks enabled), custom chip locations, etc... That is something that I've implemented in some addition I made to a monitor plugged to Basilisk. But the app I was debugging was located in a given RAM area (8 MB) so it was easy to filter other addresses out
Note that it doesn't fix the case where a pointer on data is on the stack either. I guess that Toni doesn't want to implement some heuristic stuff that will never be right. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
native x86 code in WinUAE? | Falk | support.WinUAE | 20 | 21 January 2023 18:30 |
Profiling code under WinUAE? | deimos | Coders. General | 8 | 08 October 2018 17:55 |
Investigating Guru message | selco | support.WinUAE | 2 | 17 March 2016 12:03 |
Calling Windows code from WinUAE is risky! | Leandro Jardim | support.WinUAE | 2 | 22 January 2012 10:09 |
editing winuae source code | petee1979 | Coders. General | 2 | 22 April 2008 04:19 |
|
|