Assembler debugging advice

Hi all.

Ive dabbled with assembler for quite a while but never really gone anywhere with it, but recently ive given it a go with regards to coding a game, elbeit a rather simple game, as an exercise to see how far i get. Then if i am somewhat successfull i may have a crack at doing something more elaborate.

My problem however is my code is crashing but i cannot identify anything to give me a clue as to whats causing it.

Does anybody have any advice on debugging techniques

Thanks very much for any feedback

Greg

Assembler is unforgiving. ;-)

If you can see text on the screen (not running in the desktop), it is useful to remember that:

   SWI  256 + 'A'

will print A on the screen. Drop these in, working your way through the alphabet, and run the program. If it outputs ABCD and crashes, the problem is occuring between D and E. But as I said, assembler is unforgiving, so if you narrow it down to something seemingly innocuous (like STRB R0,[R2]) you’ll need to work backwards to check that R2 was set correctly and no system call or subroutine messed it up, that all stack saves and restores match up, that you don’t BL within a BL’d bit of code without doing something with the first R14…

(I speak from experience and lots of prods of the reset button! ;-) )

PS: It is common practice to write stuff in BASIC or C (as per preference) and use assembler for the bits that need speed. It helps keep the code maintainable, and makes it easier to write and debug. It can be fun to write something entirely in assembler…if your idea of fun is beating your head off the desk in frustration because an off-by-one array write in some remote part of the program trashed a data structure that makes the whole thing collapse like a house of cards half an hour later. Yup, more experience. I went out and bought myself a cake when I finally tracked that down, and yes, I ate the whole damn thing. <oink!><oink!>

Hey there Rick. Thanks for the reply.

Yes i agree that assembler is unforgiving but when things come together the joy is greater. I use something similar to your ABCD method but this issue is very elusive. It seems like it has something to do with a comment ( and believe me i know how that sounds ) as when i delete some code that has been commented out it crashes. Undo my deletes and the code runs. Very strange

Strange indeed. Time dump both lots of memory to disc and examine them side by side. Something is different. Question is, what?

Which assembler are you using?
With the Basic assembler, if you have several instructions on a line and comment out the first, I believe the rest of the instructions on the line are still assembled. This is unlike Basic REMs, which always comment the whole of the line. If you are not using a syntax colouring editor it can be confusing. You can also set OPT so the instructions are listed during assembly.

As Rick suggests, regardless of the assembler, if you dump both working and non-working code, then compare to see what is different.

A Time dump ? I dont understand. I agree there must be something different but what ?

I am using BBC Basic assembler with StrongEd. I am also using semi-colons to comment out but I never have more than 1 instruction per line.

Thanks guys i’ll take a look at the assembler listing using OPT

The joy of writing on a mobile phone: Time to dump…

In other words, build your working code and then save it to disc. Then build the non-working code and save that to disc. Load them into an editor (such as Zap) side by side and compare.

Oh i see :-). Yes the joys of typing on Mobile phones. Gonna be busy for a couple of days at work. So will get back asap

I have done a dump of both versions of code, working and crashing.
It seems that there are 2 differences and neither makes any sense. The first difference is a piece of data used as a random seed which would make no difference if it was changing, it would be a good thing. The second difference is the location where I have a breakpoint set which isnt used in the current iteration of my code so also not making any sense.

However when I compared the working and crashing versions of dumped code with the output of BASICs assembler the BASIC assembler was reporting everything as should be and was different to the 2 dump versions. IE the 2 locations looked normal in the BASIC assembler output which doesnt make sense as I would of expected it to be the same as the working version !!

My conclusion is that possibly I have an issue with my memory OR there may be a bug in BASIC / BASIC assembler.

I have repeated everything in both StrongED and Zap with the same results so therefore conclude these editors are fine.

There is also some other commented out code and when I delete these I get exactly the same crash even though the commented out code seemingly would of had no bearing on the result of the crash.

At this moment I see that it would make sense to manually type out a new file copying the old file without the comments unless anybody has any brilliant ideas :-). I will of course do a code dump and compare it again.

Thanks again for everyones input

Greg

Do you know how to use the Debugger module?

The most useful commands for diagnosing a crash will be *ShowRegs and *MemoryI.

You might also want to have the DebugButton module running (available from the bonus binaries download), which will give you a ‘debug’ button on error boxes when a serious error occurs. This will drop you into a (single-tasking) command line so that you can debug things. If your game is a Wimp task you’ll probably want to use this to help debug it. If the game’s single-tasking then you should just be able to run it from the command line – so that when it crashes you’ll be at the command line still and can use the debugger commands or stuff like *Save to access the tasks memory.

So the method of using the debugger to get some useful info would be:

1. Run the game somewhere where you’ll be left at the command line after it crashes (e.g. run from the command line, or have DebugButton loaded. If it’s a text-only game or program you could run it from a taskwindow).
2. Make it crash, and get to the command line afterwards
3. (If not running from a taskwindow) use *Spool <somefilename> to save a log file of what you’re about to do next
4. Use *ShowRegs to get a register dump at the time of the crash
5. Use *MemoryI to get a dump of the code near to the PC at the time of the crash. You’ll need to tell it what address range to dump, I usually start with “*MemoryI PC-40 + 80” (addresses/offsets are in hex)
6. Issue whatever other commands you think would be useful, maybe use *Save to grab a copy of application space so you don’t have to worry about missing out something important (although you would need to have a rough idea of how much memory the game is using)
7. Issue *Spool with no arguments to close the spool log file
8. Get back to the desktop and fix your bug!

When looking at the *MemoryI output, there’ll be a marker next to the address that corresponds to the PC value in the register dump. But this typically isn’t the instruction that caused the crash. If it’s a data abort then the actual instruction that caused the crash will be 8 bytes (2 instructions) earlier. From looking at the instruction and the register dump you should be able to get a good idea of why it’s crashed (e.g. an unaligned or obviously bad pointer), and from looking at the code in general you should hopefully be able to recognise which bit of source code corresponds to that area. Then you can add some debug output or manual error checks to that area of the code to try and track down exactly where it’s going wrong.

If you’re writing a game which uses multiple screen banks and it crashes, you may either want to temporarily disable the screen bank switching, or have the game install an error handler which resets the standard screen banks if an error occurs.

Another common cause of a crash is if you have a stack imbalance which causes the wrong return address to be popped from the stack. In this case you’ll usually find that the code around the PC isn’t code at all. To find the cause of such a crash you can try looking at the code around R14 – e.g.

.function1
STMFD R13!,{R0-R5,R14}
; Do stuff
BL function2
; Do more stuff
LDMFD R13!,{R0-R4,PC}

Function1 has a stack imbalance and will end up trying to return to the wrong address (and hopefully crash before it messes up the register dump too much). But because it called function2, if you look at R14 you’ll see that it’s pointing to the code within function1 that’s directly after the call to function2. From there you should be able to spot that function1 is the problem because it failed to pop R5 on exit.

If that doesn’t work you can also look at R13 to see if you can spot any obvious return addresses on the stack – check both above and below the R13 value because until you find the cause you don’t know if you’ve popped too many or too few registers.

Thanks Jeffrey. Thats a lot for me to get my head around so might take a while for me to get back.

I know a little bit about the Debugger hence my use of a breakpoint in my code. So i’ll have a look at what you have suggested and see what i come up with.

Thank you for your time and input, its much appreciated.

Greg

Back again after long wkend at work.

Checked for stack imbalances and everything present and correct.

*RUNed code from *prompt and code ran perfect no crashes. That is until i exited and the machine hung. Had to do power of reset. Strange, never done that before. Then i started deleting other pieces of commented out code and with each one was getting different failings. Sometimes the code would crash, sometimes something strange would happen but code would keep running.

So ended up removing all commented out code and doesnt crash anymore. Code runs fine. This is very weird.

So just want to say thanks to all for the very usefull tips on debugging. Im sure these will come in usefull in the future.

Greg

It sounds like you might have some uninitialised memory somewhere which the assembler code is using. There’s an *InitStore command which will fill application space with the specified value (defaults to an undefined instruction) – you might find that using that before running the code will make the results a bit more predictable.

Ill keep that in mind Jeffrey but right now the code is running fine. However, after reffering to Martins comments above bout using ; or REM to comment out code ( ive been using the first one ) curiosity got the better of me and i decided to try using REMs instead. So i added some code and commented it out with REMs and hey presto, BANG, the code crashed. I removed commented out code and all ran perfectly. I cant help but think that there is an issue with BASIC / StrongEd.

Greg

Are you willing to share the faulty code?

I cant help but think that there is an issue with BASIC / StrongEd.

I’m not aware of any issues with StrongED that might cause this. How are you running the code, directly from StrongED or by doubleclicking the file?

If you want I’d be happy to try the code out here to see if it’s a StrongED problem.

This is unlike Basic REMs, which always comment the whole of the line.

I am not sure that this is true in the assembler. I did once think it, because I always have Basic$Crunch set and the REMs are removed, but I just did a quick check and it seems to be the same as ;.

My BASIC StrongHelp manual says REM and ; are the same and also warns about putting colons in assembler comments. ;-)

My suspicion is that there are either multiple instructions in the commented lines or that there is a colon in the comments.

deleted

Sorry about long delay before replying. Its been a long busy day. Anyhow !!!

@Steve

I never use multiple instructions per line. I think it looks untidy and I learnt a long time ago about putting colons in comments, so this is not the case, but thanks.

@Fred

I am running from StrongEd. Is there a difference between this and double clicking ?

@Rick & Fred

No problems sharing the source. But my problem is I have no archiver so you will have to build my directory structure if I send the files in Email. It shouldnt take long though. I will have to make sure that I can definately make it crash again before committing, obviously.

But my problem is I have no archiver

I tend to use the one I bought years ago (SparkFS) but there’s a perfectly good free offering here:

http://www.starfighter.acornarcade.com/mysite/utilities.htm#infozip

I am running from StrongEd. Is there a difference between this and double clicking ?

Yes, running it from StrongED directly (by clicking on the running man) involves tokenising it in memory and then passing the tokenised block to the BASIC module. In this case StrongED is more involved and hence there’s a greater chance of being hit by a bug in StrongED.

If you run a saved file then StrongED is only responsible for the tokenisation prior to saving so less likely to cause problems.

Finally work out of the way for weekend.

@ Steve

Thanks for the link. It works a treat :-)

@ Fred & Rick

Ive got my code zipped ready to send if you are both still interested I just need an address to send to. You will need a screen size of 1920 × 1080 as the app opens some windows and you may lose these if the screen size is too small

Thanks again in advance

Greg

You will need a screen size of 1920 × 1080 as the app opens some windows and you may lose these if the screen size is too small

Tip: If you ever end up with a window/s off the screen, change screen mode to a smaller than current and all(?) windows will be redrawn on screen, you can then change back to your original mode. I quite often drag windows to the edge and find it quicker to do the above than try and click on the two or three pixels still on screen

Thank you Chris. Decent tip