CDVDBurn RPi 3 undefined instruction error

After adding preliminary Titanium support to CDVDBurn (if someone likes to test drive it, contact me), I tried to run CDVDBurn on a RPi 3.

However, it immediately runs into the error “undefined instruction”. CDVDBurn is written in Ada and compiled with a very old compiler (based on GCC 2.7.2.1) and some hand-patched stuff to connect it to CLib, so it is entirely likely that there is some questionable code being produced. I tried a few different CDVDBurn versions and it looks like all versions run into the same problem.

Now, I write code in Ada because I am a high level programmer. So I am looking for someone knowing low level stuff and could have a look at the asm code. The instruction at the address reported is “MOV R14,PC”, and I can’t believe that this is now undefined!

I can test drive CDVDBurn on Titanium, any model of Pi, Beagleboard Xm, Pandaboard ES, ARM X6, Iyonix or Risc PC. chris (at) svrsig (dot) org.

The instruction at the address reported is “MOV R14,PC”, and I can’t believe that this is now undefined!

Because of the pipeline, the reported address is actually two instructions on from where the error occurred. Go back a tad. ;-)

Is it an SWP, by any chance?

Because of the pipeline, the reported address is actually two instructions on from where the error occurred. Go back a tad. ;-)

Hmmm. But all CPUs have different pipeline lengths. I would have hoped that a knowledgable gizmo in the exception handler would know and correct?

Anyway, no SWP in sight. The SWP would have been the only instruction I actually know that is now invalid in ARMv8!

And it is not really a CDVDBurn problem, I tried the minimal application yesterday, and it also exhibits the problem. Here’s the instructions (and I would bet on the LDM to be the problem, just because it looks like the most complicated one :-)):

0000AE80 : .@Rт : E2524000 : SUBS    R4,R2,#0

0000AE84 : 0и[. : 095BA830 : LDMEQDB R11,{R4,R5,R11,R13,PC}^

0000AE88 : .рас : E1A0E00F : MOV     R14,PC

Because of the pipeline, the reported address is actually two instructions on from where the error occurred. Go back a tad. ;-)

Hmmm. But all CPUs have different pipeline lengths. I would have hoped that a knowledgable gizmo in the exception handler would know and correct?

The pipeline length of the CPU is irrelevant, the offsets that are applied to LR are the same for all ARM architectures:

• Undefined instruction & SWI will be 2 or 4 bytes head depending on whether the exception was in Thumb or ARM mode
• Prefetch aborts, IRQ, FIQ will be 4 bytes ahead
• Data aborts will be 8 bytes ahead

When the OS reports a data abort/undefined instruction/etc. error it always quotes the LR value that the CPU gave it (and it’s that same address which will be highlighted in Debugger’s disassembly output). If we were to fix that now then it would probably result in more confusion than if we just left it alone :-)

Here’s the instructions (and I would bet on the LDM to be the problem, just because it looks like the most complicated one :-))

Yes, it’ll be the LDM. For 26bit modes that code is perfectly fine (returns from function restoring the combined PC+PSR from the stack), but for 32bit modes it’s classed as an “exception return” LDM which restores the PC from the stack and the PSR from the (mode-specific) SPSR. However user mode has no SPSR register, and ARM class the behaviour of the instruction in user mode as being “unpredictable”. I.e. you’re at the mercy of whoever designed the CPU. Luckily for the Cortex-A53/Pi 3 they came to their senses and made it so that unpredictable instructions will always trigger an abort, instead of allowing them to cause memory corruption or other hard to track down bugs.

It’s not the actual pipeline length, it’s where the PC is relative to the current instruction being executed (think – decode fetch execute). It’s plus 8 on everything except the StrongARM (plus 12) if I recall. There’s an OS info call to get the offset. ReadSysInfo?

The fault is there, the LDM followed by ^. That’s a 26 bit flags restore and shouldn’t be used on anything 32 bit. The spec in ARMv8 is tighter so it’ll be thrown out as an invalid instruction now.

Oh that low level stuff. The last time I could (partly) follow ARM code was with ARMv2…

So I now understand the problem, thanks for the explanation. And why this cannot be possibly 32bit compatible. And why it nevertheless ran on some 32bit cpus.

Now for the solution. If the software ran fine on some 32bit cpus, it seems to be a strong indicator that just removing the ^ would be a valid solution, no? Because it cannot possibly have relied on restoring the flags on 32bit cpus? Previously undetected strange behaviour (bugs) aside.

Not sure r11,..r11 is OK (even without the !)?

Still not sure about a solution, but I seem to have found (with the help of ARMalyser – thanks, David!) the culprit, and thankfully it is not the old code generator, but inside libgcc in bin.lib.o.main which in theory should be 32bit clean.

When linking, GNAT lumps together the compiled o files along with libgnat (which provides stuff to connect Ada to the SharedCLibrary and seems to be 32bit clean – another piece of Martin Würthner quality work) and libgcc. IIRC, the libgcc stuff came from an early 32bit GCC 2.95 before the release of the IYONIX pc.

I’ll investigate further if I can find the sources for that stuff to allow recompilation.

Now for the solution. If the software ran fine on some 32bit cpus, it seems to be a strong indicator that just removing the ^ would be a valid solution, no? Because it cannot possibly have relied on restoring the flags on 32bit cpus? Previously undetected strange behaviour (bugs) aside.

Well, maybe. :-)

Firstly, as Chris points out, reloading R11 with R11 being used as the index register is unpredictable. I vaguely recall a test between my Pi and Beagle xM that one of them correctly updated the register as expected, while the other left the register as-is. In other words, if an LDM Rx,{} has Rx within the braces, one cannot rely upon Rx being any specific known value.

Secondly, while it is rare, it would be possible for the calling function to do something with flags and then perform a test afterwards, because the 26 bit APCS specified that flags would be preserved; so this would have worked:

  MOV   R0, #1         ; load 1 into R0
  CMP   R0, #1         ; see if R0 is equal to 1
  BL    do_something   ; call a function
  MOVEQ PC, R14        ; exit function if EQual (R0 was 1)

Horrible, but it would have worked.

On the 32 bit APCS, flags are not preserved, so the processor flags after “do_something” returns are undefined. About the only flag specification made anywhere now is that one should return back to the OS with V set to flag an error else clear…

but inside libgcc

Would it not be part of this? http://www.riscos.info/index.php/GCCSDK

the libgcc stuff came from an early 32bit GCC 2.95 before the release of the IYONIX pc.

Might have just been an instruction that got missed. Been there, done that… ;-)

I failed to find sources for the stuff that comprises libgcc for GCC 2.7.2.1 (RISC OS). I’ll try to patch the binary to see if this fixes things.

Strangely, ARMalyser hangs when analysing libgcc from GCC 2.95, and libfile (from current DDE27) cannot list the files inside.

Had a go at patching the libgcc binary after wading through the old Risc PC development stuff without finding anything relevant apart from a text file hinting at the process that produced the current not-really-32bit libgcc for GNAT.

The good news is: CDVDBurn now starts on the RPi 3 without problems. A quick test of the new Extractor feature showed no problems. Now I hope and pray that this solution keeps running again for the next 15 years (original 32bit patched version was done in 2002).

So thanks to Jeffrey, Rick and Chris for their assistance!

CDVDBurn now starts on the RPi 3 without problems.

Very good news. It was one of the last software (I use) not compatible with my Pi3 :)

I’ll be very happy to get & test the new version as Windows 10 decides this morning to see my burner as a reading-only device. Things are going worse and worse with Windows. It’s time to migrate (back) one more task to RISC OS.

CDVDBurn now starts on the RPi 3 without problems.

The only Pi3 I have aviable is in my Pi-Top.
Have try. CDVDBurn starts but I have any “display problems”…

Can anyone try CDVDBurn with a Pi3 Pi-Top?

Can anyone try CDVDBurn with a Pi3 Pi-Top?

As soon as I will have the new version :)

Raik, your email seems dead – two tries, both not delivered: “Message content not allowed OX_604”. Plain text content, no attachment…strange.

As soon as I will have the new version :)

Ask Steffen ;-)

Raik, your email seems dead – two tries, both not delivered: “Message content not allowed OX_604”. Plain text content, no attachment…strange.

Was direct attached from the “killed stick” I wrote. Have made a backup and send second times…

Raik, nein, das ist ein Missverständnis (und ich würde es dir per Mail direkt schreiben, aber es geht ja nicht): ich kann derzeit keine EMails an Dich verschicken, weil Arcor/Vodafone diese nicht ausliefern will mit dem Hinweis “Message content not allowed OX_604”.

Wer lesen kann ist klar im Vorteil und wer versteht was er liest… (ich meine mich) ;-)
Nimm den gleichen Anfang und als Ende t-online… sollte klappen.

Ask Steffen ;-)

Steffen? (no hurry)

Wer lesen kann ist klar…

Was ist denn los? :)

Was ist denn los? :)

Some misunderstandings. Not my native language. ;-)

Have found the “error”. To get the error message of the older !CDVDBurn I have made the !Run to a TaskObey. I forget. Change back to Obey… all things fine.
If I try any things I do often. No problems. Only with CDVDBurn.
What the reason. Made a TaskObey is a easy way to copy the error messages to a textfile. Can use *spool but why I should? ;-)

Just as a matter of interest (me being a bit of a language nut) – what IS your native language, Raik?

The language of an engineer are drawings…
Otherwise Berlin dialect with rudeness, unkindness and ignorance
Somehow German. But I am not a language talent (also for programming), rather the opposite.

P.S.: I hope google find the right words but I know not ever.

Back to the problem…

Have try !CDVDBurn + the !Run taskobey with other hardware. The same display problems with a additional “Internal error: branch through zero”. Should I jump to “Bugs”? Is it a OS problem?

The language of an engineer are drawings…

Dass ist wahr. Ich bin auch Ingenieur.

Google findet nicht zu unangemessene Wörter. Verständlich.