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

[jotd]

I'll have another go and will create a video if it's useful. Thanks for following that issue!

[Toni Wilen]

Originally Posted by jotd

I'll have another go and will create a video if it's useful. Thanks for following that issue!

Videos are almost always useless. It hangs, seeing what it is supposed to do won't help anyone.

[jotd]

Okay, anyway dropped that project for now, and tested on a new project.

non-zero VBR is supported here. But uaedbg complains about read at 0, 8, C, ... forever when my program doesn't read at those locations.

Zoned the program (galaxian.zip). Just start it, and see that uaedbg has hallucinations in memory violations.

[Toni Wilen]

Originally Posted by jotd

Okay, anyway dropped that project for now, and tested on a new project.

non-zero VBR is supported here. But uaedbg complains about read at 0, 8, C, ... forever when my program doesn't read at those locations.

Zoned the program (galaxian.zip). Just start it, and see that uaedbg has hallucinations in memory violations.

It is bitplane DMA doing those accesses. 6 planes enabled but only 2 first planes have valid pointer. Unfortunately it currently can't report which kind of access caused the "fault". Only way is to manually check all DMA pointer registers (e command).

Any chip RAM access below address $0400 are always reported. (except long aligned, long sized exception vector reads)

[jotd]

Zoned a new exe.

Now when I get the read in 0 all 6 bitplane pointers are valid. Still the issue continues.

[Toni Wilen]

Originally Posted by jotd

Zoned a new exe.

Now when I get the read in 0 all 6 bitplane pointers are valid. Still the issue continues.

Sprite DMA this time. 1 to 7 point to address zero.

[jotd]

yes! fixed. Now sound library is giving me zero read only once per sample. I'll pass on that one, and after moving some ram variables after some read only variables, game is now running with uaedbg. Thanks!

[paraj]

Hi Toni,

Been using this more recently, great work as always, but I noticed a couple of issues:

1. WinUAE crashes if you trying to allocate a very large amount of memory (e.g. $40000000, but I think in general more than fits into debug memory). Repro in attached "alloc.exe"
I also think that trying to allocate an "abnormally" large amount of memory (say >=64MB) should cause a debug break, since it's going to be an error in 99.9% of cases. In the case I was looking at the upper word of D0 was junk when AllocMem was called.

2. It seems like something can go awry after reporting an error. I think it might be related to interrupts, but I'm not sure. In attached "test.exe" I continue with "g<enter>" a couple of times and it ends up executing "val" as an instruction. (Might relate to my next point)

3. Code like:

func:
    addq.w  #1,val
    rts
val:    dc.w 0

is extremely common, even if it makes your job harder . It would be nice if the SMC warnings could be inhibited on their own without affecting other memory warnings (i.e. a separate bit in inhibit_break for SMC). It seems like you get a hit for both the instruction fetch from modified memory, and an invalid access when updating "val".

4. HUNK_DREL32 (1015) doesn't seem to be supported - vasm will output these when not assembling with -kick1hunks. "drel32.exe" attached.

I'm testing by running

winuae64.exe -cfgparam=quickstart=A1200,3 -s filesystem2=rw,DH0:DH0:c:\Temp\uaedbg\hd,0 -s uaehf0=dir,rw,DH0:DH0:c:\Temp\uaedbg\hd,0 -cfgparam=debug_mem=true -G

Where the HD directory just contains the attached files.

Once again thanks for your hard work, and obviously this is not any kind of priority. It's still super useful.

[Toni Wilen]

Originally Posted by paraj

1. WinUAE crashes if you trying to allocate a very large amount of memory (e.g. $40000000, but I think in general more than fits into debug memory). Repro in attached "alloc.exe"

Fixed

I also think that trying to allocate an "abnormally" large amount of memory (say >=64MB) should cause a debug break, since it's going to be an error in 99.9% of cases. In the case I was looking at the upper word of D0 was junk when AllocMem was called.

Unfortunately someone's abnormal can be someone else's normal

2. It seems like something can go awry after reporting an error.

This has been mentioned previously. CPU emulator can't detect this situation because CPU always prefetches at least one word after last instruction and it gets detected as self-modifying code.

Maybe some instructions can be special cased (RTS etc) but it gets difficult with jump instructions because they can have different addressing modes and this kind of hack shouldn't be part of CPU emulator anyway.

Switch of CPU prefetch emulation ("more compatible") to get rid of it. (Or change the structure of the data, mixing non-static data and code is ugly in my opinion and also makes executable larger. Address register relative is usually most optimal)

4. HUNK_DREL32 (1015) doesn't seem to be supported - vasm will output these when not assembling with -kick1hunks. "drel32.exe" attached.

Implemented.

[AlexBruger]

Hi Toni, some questions regarding the new features:

You mention in the first post:
"Other new debugger features:
- Early boot segtracker-like feature for loadable libraries and others, enable in misc panel."

Is this still implemented? I can't find this option in the Misc. Panel.

--

Also you say
"- tse/tsd = enable/disable full stack frame tracking. Can be used when no debugmem debugging is active."

I can't seem to get this to work without debug memory.

--

And finally browsing through the WinUAE code I saw the file "enforcer.cpp", which seems to have some useful features, escpecially for programs that require a KS before 2.0 and hence can't use debug memory.
But it seems there is no option to activate this anymore, except through the AHI sound drivers.
The debugger command "fen" can only activate to break when a hit is detected, but since it can't be enabled that won't do anything.
Is this intentional?
Was this replaced by the "Log illegal memory access" in the Misc. Panel?

Thanks, Alex

[AlexBruger]

I have found the answer to the last of my 3 questions.
The enforcer can, as stated, only be enabled through the AHI sound files, but they are exposed through the uae.resource.
So the enforcer can be activated using the winuaeenforcer program bundled with WinUAE.
Unfortunately it seems to require KS 2.0 as well.

[Trigger58]

Hi, i tried to load my A570/CDTV config and the public beta 9 don't work with it. I can't get the A570/CDTV to work.

Any ideas?

EDIT:

All fine now. Got it to work. I made a mistake in chipset configuration. I had to set it as CDTV not A500.