Dynamic Areas Location

Is there a cmdline way to find the address of a dynamic area while it’s in use? I’ve got a couple of strange bugs and was wondering if it’s caused by pointer arithmetic. Or if there is any way to see if an app is accesing memory outside its area.

Or if anyone has any ideas how to debug – I’m using an Iyionix 5.18 26 bit app under aemulor.

You can get a DA address via OS_ReadDynamicArea

SYS "OS_ReadDynamicArea", <area no> TO A% : PRINT ~A%

You’d have to debug the app to find out if it was accessing memory outside of what’s expected. It will generate an Abort if it’s going to an unmapped or restricted range. Page zero access will however succeed.

Debugging will very much depend on the app, source availability, if it’s running under the WIMP or single tasking or if there are Modules involved.

Is it your own app? If you provide some more detail on what the app is and what the symptoms are, someone may be able to assist or already be aware of the issue.

Hi the app in question is Impression-X – I have the sources my two dev machines are both 32bit the sources are not 32bit clean are so running under Aemulor – I have found some internal CC documentation yesterday that implies the software is clean to bit 29, maybe to bit 30 (ie there may still be flags in bit 30) and defiantly not to bit 31. I have two issues [compile contents & create/modify master page] both of which seam impossible – one appears to depend upon how much other software is running and how long the machine has been running the other is just wrong – but i have no 26 machine to test on yet (im building up a virtual rpc but its not running yet) but repeat the same action 10 times and it will work 1-9 times – looking at the sources for both problems I cannot see any obvious issues in the code that is going wrong the only explanation for the two failures are that the memory it’s accessing is not correct ie invalid address. I notice from the RISCOS 6 dynamic area notes (http://www.riscos.com/support/developers/riscos6/memory/dynamicareas/dynamicchnages.html) that all dynamic areas are allocated bellow 1gb is this case in RISCOS 5? I have also tried reverting the code in question to a version pre any 32bit-ing and any of my changes but the problems still exist. Unfortunately none of the original debug infrastructure works under Aemulor – so I’m a bit at a loss on what I can do easily.

In a vaguely related concept – I was looking through the documentation for Norcroft C v3, I noticed that ASD had a mode where it would communicate with a serial device. Has any of this sort of functionality been retained anywhere within DDT? Sometimes it is a lot easier to run code on one machine and perform the debugging on another.

I have the sources my two dev machines are both 32bit the sources are not 32bit clean are so running under Aemulor – I have found some internal CC documentation yesterday that implies the software is clean to bit 29, maybe to bit 30 (ie there may still be flags in bit 30) and defiantly not to bit 31

As you have the source, provided there’s no legal issues I can assist in making it fully 32bit. Drop me an eMail: jon at jaspp dot org dot uk

I have a full suite of old Arc’s if you need testing done on physical 26bit.

I notice from the RISCOS 6 dynamic area notes (http://www.riscos.com/support/developers/riscos6/memory/dynamicareas/dynamicchnages.html) that all dynamic areas are allocated bellow 1gb is this case in RISCOS 5?

I wouldn’t rely on DA’s being below 1GB, any memory addressing should support the full 32bits.

I notice from the RISCOS 6 dynamic area notes (http://www.riscos.com/support/developers/riscos6/memory/dynamicareas/dynamicchnages.html) that all dynamic areas are allocated bellow 1gb is this case in RISCOS 5?

I wouldn’t rely on DA’s being below 1GB, any memory addressing should support the full 32bits.

Indeed. RISC OS 5 does allocate dynamic areas starting from the lowest possible address, but because we have a 512MB wimpslot limit, and because the free pool is (a) a dynamic area which (b) is the size of the machines RAM (with most machines now having 1-2GB), any dynamic areas you create are likely to be at 2GB or above.

I can recommend having a copy of the MemInfo module hanging around to quickly list dynamic area information from the command line.

The ROL fork of the OS had some funny ideas about the memory map, including even encouraging the squandering of global address space by advocating using lots of dynamic areas instead of application slots. I’d definitely advise against assuming dynamic areas are at a low address. In fact, long term, the only way a 32-bit OS can use lots of RAM (> 4GB) is by re-using the same logical addresses over and over again – which is what the application slot is for – so ultimately I expect dynamic areas to be squeezed into an ever-smaller patch of memory at the top of the memory map.

The MemInfo module was most helpfully it reports my dynamic area address as 0×80000000. Have looked further into the old debug infrastructure and impression fails to build (now builds) but fails to run. Need new fast 32bit safe code that I can record register / address values.

It may of course be that I’m reading from page zero then rather than 0×8000000 the minimal dynamic area is only 24k? In all the zero page protection changes was there an option to see if address bellow 0×8000 were being read ( or even logged)?

In all the zero page protection changes was there an option to see if address bellow 0×8000 were being read ( or even logged)?

No, page zero only has write protection from User mode. If the code is running as User you could remove Read access from page zero whilst you’re debugging (alter the access bits in the first word in L2PT). You’d probably want to do this on a clean boot with no other software loaded, as anything could potentially be hitting page zero inadvertently.

You’re other alternative is to put vectors high – I’m not sure if there’s a publicly available ROM build for it though, perhaps someone here could build one for you.

None of this will work under Aemulor though (at least I don’t believe it will), you’d have to test it as a native 32bit app.

(None of this will work under Aemulor though (at least I don’t believe it will), you’d have to test it as a native 32bit app.)

In fact, both are fine with Aemulor. Many, many years ago I wrote and uploaded:
http://sendiri.co.uk/downloads/raisepvec.zip
http://sendiri.co.uk/downloads/workusr.zip

The first is a module which will move the processor vectors to high addresses for the lifetime of the module. It is apt to work only on the IYONIX pc having not been updated for later architectures. The second is a simple BASIC program that can be used to change the protection of page zero, including making it accessible only from SVC mode, ie. blocking all USR mode accesses. Be warned that this is known to take out the ShareFSFiler and possibly other bits of software too. I don’t recall ever seeing anything fail from having the RaiseProcVecs module loaded. You will need to start it before loading Aemulor, because Aemulor does employ a cheat for performance reasons, falling back to the documented API if the cheat is unsafe; but it does this check only on startup and does not expect the vectors to move whilst it is running.

Just a few suggestions – !DeskDebug 26/32bit is written with ARM Wimp progs in mind – a demo version is available.
If you require help with Imp modules – ask – you may find some have been already 32bitted.
It might be easier if you don’t use 26bit only instructions – it makes the code easier to follow – unless you want the program to run on A5000/A310s etc.

Hi Adrian – thanks for the info and modules I will give them a try I just hope there aren’t hundreds of null accesses.

Does DeskDebug work inside Aemulor? Or can it only be used to debug 32bit apps from a 32bit os?

Hmm, and interesting question. I don’t know very much about DeskDebug and have never used it seriously, but I suspect the simple answer to whether they can sensibly be used together is “no.” If Aemulor’s interpreter is being used then the code that DeskDebug thinks it’s debugging is never actually executed by the CPU directly, and I’m really not at all sure what would happen if you were using the breakpointing engine. One of the possible applications for my ARM emulator, which eventually became Aemulor, was in fact debugging software, although I’d had an interest in CPU design for some time and had pretty much implemented an ARM2 at logic gate level before building an emulator in software.

What would be really useful is an instruction log ala J-trace. Enabled and Disabled by software (swi).