CDVDBurn RPi 3 undefined instruction error
Pages: 1 2
Steffen Huber (91) 1958 posts |
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! |
Chris Hall (132) 3567 posts |
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. |
Rick Murray (539) 13870 posts |
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? |
Steffen Huber (91) 1958 posts |
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 :-)):
|
Jeffrey Lee (213) 6048 posts |
Because of the pipeline, the reported address is actually two instructions on from where the error occurred. Go back a tad. ;-) The pipeline length of the CPU is irrelevant, the offsets that are applied to LR are the same for all ARM architectures:
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 :-)
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. |
Rick Murray (539) 13870 posts |
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. |
Steffen Huber (91) 1958 posts |
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. |
Chris Hall (132) 3567 posts |
Not sure r11,..r11 is OK (even without the !)? |
Steffen Huber (91) 1958 posts |
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. |
Rick Murray (539) 13870 posts |
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:
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…
Would it not be part of this? http://www.riscos.info/index.php/GCCSDK
Might have just been an instruction that got missed. Been there, done that… ;-) |
Steffen Huber (91) 1958 posts |
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. |
Steffen Huber (91) 1958 posts |
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! |
David Feugey (2125) 2709 posts |
Very good news. It was one of the last software (I use) not compatible with my Pi3 :) |
David Feugey (2125) 2709 posts |
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. |
Raik (463) 2062 posts |
The only Pi3 I have aviable is in my Pi-Top. Can anyone try CDVDBurn with a Pi3 Pi-Top? |
David Feugey (2125) 2709 posts |
As soon as I will have the new version :) |
Steffen Huber (91) 1958 posts |
Raik, your email seems dead – two tries, both not delivered: “Message content not allowed OX_604”. Plain text content, no attachment…strange. |
Raik (463) 2062 posts |
Ask Steffen ;-)
Was direct attached from the “killed stick” I wrote. Have made a backup and send second times… |
Steffen Huber (91) 1958 posts |
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”. |
Raik (463) 2062 posts |
Wer lesen kann ist klar im Vorteil und wer versteht was er liest… (ich meine mich) ;-) |
David Feugey (2125) 2709 posts |
Steffen? (no hurry)
Was ist denn los? :) |
Raik (463) 2062 posts |
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. |
Clive Semmens (2335) 3276 posts |
Just as a matter of interest (me being a bit of a language nut) – what IS your native language, Raik? |
Raik (463) 2062 posts |
The language of an engineer are drawings… 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? |
Clive Semmens (2335) 3276 posts |
Dass ist wahr. Ich bin auch Ingenieur. Google findet nicht zu unangemessene Wörter. Verständlich. |
Pages: 1 2