Norcroft generating LDMDB that takes undefined instruction on ARMX6

A surprise this morning was an undefined instruction exception in a test program, on the instruction

LDMDB R2!,{R1,R2}

This disassembles without warning in DecAOF, but *MemoryI does show the warning ‘Rn in list’

This was generated by Norcroft v5.86 when loading a series of uint64_t’s onto the stack as args for a printf().

The ARMv7-A/R ARM C.d states “Instructions with the base register in the list and ! specified are only available in the ARM instruction set before ARMv7, and ARM deprecates the use of such instructions. The value of the base register after such an instruction is UNKNOWN.”

I guess the compiler should avoid generating these when moving 64-bit quantities around!

Is it just me, or does the Norcroft compiler of the last decade or two seem to add in spurious unnecessary writebacks for load/store single/multiple? It’s certainly the case with this example.

/* u64x - demonstrates undefined instruction exception taken     */
/*        on ARMv7 when Norcroft is marshalling 64-bit arguments */       

#include <stdio.h>
#include <stdint.h>
#include <inttypes.h>

static uint64_t test1_lower; static uint64_t test1_upper;
static uint64_t test2_lower; static uint64_t test2_upper;

static int g_n_loops = 42;
static int g_n_exact = 42;

static void
summary(const int i)
{
#if 0 /* newer style, avoiding generating undefined instruction */
    const uint64_t xhi = test1_upper;
    printf("my_little_pony" "(x in %" PRIu64 "..%" PRIu64 ", y in %" PRIu64 "..%" PRIu64 "): ",
        test1_lower, xhi,
        test2_lower, test2_upper);
    printf("%d/%d loops completed, %d exact\n", i, g_n_loops, g_n_exact);
#elif 1 /* newer style, but undefined instruction LDMDB R2!,{R1,R2} ; Rn in list */
    printf("my_little_pony" "(x in %" PRIu64 "..%" PRIu64 ", y in %" PRIu64 "..%" PRIu64 "): ",
        test1_lower, test1_upper,
        test2_lower, test2_upper);
    printf("%d/%d loops completed, %d exact\n", i, g_n_loops, g_n_exact);
#elif 1 /* older style, but works */
    printf("%d/%d loops completed, %d exact\n", i, g_n_loops, g_n_exact);
    printf("my_little_pony" "(x in %" PRIu64 "..%" PRIu64 ", y in %" PRIu64 "..%" PRIu64 ")\n",
        test1_lower, test1_upper,
        test2_lower, test2_upper);
#endif
}

/* cc 5.86 (no options specified) produces [DecAOF output, UAL syntax]

  0x000000:  6d6d7573  summ : STCLVS   p5,c7,[sp,#-0x1cc]!
  0x000004:  00797261  ary. : RSBSEQ   r7,r9,r1,ROR #4
  0x000008:  ff000008  .... : DCI      0xff000008 ; Undefined instruction
  0x00000c:  e1a0c00d  .... : MOV      r12,sp
  0x000010:  e92dd811  ..-. : PUSH     {r0,r4,r11,r12,lr,pc}
  0x000014:  e24cb004  ..L. : SUB      r11,r12,#4
  0x000018:  e15d000a  ..]. : CMP      sp,r10
  0x00001c:  4bfffff7  ...K : BLMI     __rt_stkovf_split_small
  0x000020:  e1a04000  .@.. : MOV      r4,r0
  0x000024:  e59f0050  P... : LDR      r0,0x7c
  0x000028:  e8900006  .... : LDM      r0,{r1,r2}
  0x00002c:  e92d0006  ..-. : PUSH     {r1,r2}
  0x000030:  e2403008  .0@. : SUB      r3,r0,#8
  0x000034:  e8930003  .... : LDM      r3,{r0,r1}
  0x000038:  e92d0003  ..-. : PUSH     {r0,r1}
  0x00003c:  e59f203c  < .. : LDR      r2,0x80
  0x000040:  e5920004  .... : LDR      r0,[r2,#4]
  0x000044:  e5923000  .0.. : LDR      r3,[r2]
  0x000048:  e9320006  ..2. : LDMDB    r2!,{r1,r2} ; <<< this is the offending instruction
  0x00004c:  e52d0004  ..-. : PUSH     {r0}
  0x000050:  e52d3004  .0-. : PUSH     {r3}
  0x000054:  e28f0f0a  .... : ADD      r0,pc,#0xa,#30 ; <<< and what's with this wacky ADR encoding for the format string?
  0x000058:  e28dd004  .... : ADD      sp,sp,#4
  0x00005c:  ebffffe7  .... : BL       _printf
  0x000060:  e59f0050  P... : LDR      r0,0xb8
  0x000064:  e1a01004  .... : MOV      r1,r4
  0x000068:  e280001c  .... : ADD      r0,r0,#0x1c
  0x00006c:  e9b0000c  .... : LDMIB    r0!,{r2,r3}
  0x000070:  e28f0f11  .... : ADD      r0,pc,#0x11,#30
  0x000074:  e91b6810  .h.. : LDMDB    r11,{r4,r11,sp,lr}
  0x000078:  eaffffe0  .... : B        _printf
*/

int main(int argc, const char * argv[])
{
    summary(argc);
    return 0;
}

Instructions with the base register in the list and ! specified are only available in the ARM instruction set before ARMv7, and ARM deprecates the use of such instructions. The value of the base register after such an instruction is UNKNOWN.

I never wrote that! It’s in an edition later than my retirement. I don’t know who wrote it, or why.

It’s such an imbecilic thing to try to do that it never occurred to me (or to any of the engineers involved) that it was necessary to mention it, and that any witless programmer who tries to do it deserves the obvious unpredictability that results.

Unless the standard phraseology of the ARM ARM has changed, UNKNOWN is an error, too – the standard phraseology would have been UNPREDICTABLE in my day.

ARMv8 ARM seems to have gone back to UNPREDICTABLE for behaviour (with qualifiers):

CONSTRAINED UNPREDICTABLE behavior

If wback && registers<n> == '1', then one of the following behaviors must occur:

• The instruction is UNDEFINED.

• The instruction executes as NOP.

• The instruction performs all of the loads using the specified addressing mode and the content of the register
that is written back is UNKNOWN. In addition, if an exception occurs during such an instruction, the base
address might be corrupted so that the instruction cannot be repeated.

any witless programmer who tries to do it

Many compilers can be described as ‘witless programmers’. Sometimes I am delighted to see what they produce, but most of the time am dismayed.

are only available in the ARM instruction set before ARMv7

What are they smoking? These instructions were never available, they just weren’t shot dead on sight.

I mean, think about it. You’re loading Rn from an address pointed to by Rn, with the new address to be written back to Rn.
At the end of that, what the hell is supposed to be in Rn? That instruction never made sense, and it’s weird/worrying that the compiler is generating such gibberish.

Is it just me, or does the Norcroft compiler of the last decade or two seem to add in spurious unnecessary writebacks for load/store single/multiple?

Yes, I removed quite a few of these when porting things to 32 bit, as ARMalyser warns about them.

What are they smoking? These instructions were never available, they just weren’t shot dead on sight.

Indeed it is crazy, but for a time ARM got round to defining it to work in what would probably be the safer of the two options where execution completes: ARM7 has “When writeback is specified the base written back at the end of the second cycle … A LDM will always overwrite the updated base if the base is in the list”. ARM2 documentation was, of course, silent on the matter, as we weren’t all idiots. [Edit: ARM2 appears to be documented in the Data Abort section as behaving as defined by ARM7.]

Hey, perhaps PatchSWP needs to be PatchCrazyShite?

[Edit: Thought it best to report this issue over here as more people are likely to look at this, and maybe have used int64_t and friends and might need to give their code the once-over (ARMalyser is your friend), than the obscure stuff I’ve been reporting recently over in the actual Bugs reporting section.]

Thought that it might be particular to marshalling args for variadic functions, but can demonstate that it’s not.

Someone will no doubt be along shortly to inform us of the error of our ways in using 64-bit values… ;-)

Many compilers can be described as ‘witless programmers’. Sometimes I am delighted to see what they produce, but most of the time am dismayed.

Surely any compiler that can be described as a witless programmer must have been written by a witless programmer? Assuming the “witless” means “stupid” of course, rather than literally “without a brain.”

That compilers might faithfully follow the witless creations of witless programmers is understandable, but generating their own stupidities is unforgiveable.

I had friends at ARM who wrote compilers; they were certainly very clever people, understood the instruction set(s) very well, and knew a lot about optimization. But they were – like the rest of us – always under the pressure of tight deadlines. Which might be a possible reason for apparent witlessnesses.

always under the pressure of tight deadlines.

It’s always depressing how marketing promises the earth without consulting anybody else (especially those who must deliver on the promises), and the beancounters only look at short term gains so seem institutionally incapable of understanding that a poor product now is not as good as a better product later (assuming a reasonable definition of later).

“We’ve already shipped it”

It’s always depressing how marketing promises the earth without consulting anybody else (especially those who must deliver on the promises)

Don’t forget the POs that at every decision like “ok you can either have (a) or (b)”, they systematically say “both” or the even more annoying “yes”, and then they come back with “but why do we have this problem?” and you have to tell them it’s because of the (ab) option that wasn’t in the list of feasible ones.

Oh and the “website” of the competitor X that states they can do “A,B,C and D”, and so that’s good enough to say “if they did it we have to do it too”! The problem is that the competitor “forgot” to mention that they can only do “(A OR B OR C) AND D” not all of them at the same time…