title: GCC arm instruction mode when compiling in thumb mode
body: <p>I'm wondering how GCC configured using <code>--with-mode=thumb</code> handles compiling/assembling code that makes use of ARM mode sections if the <code>-marm</code> flag is not specified. That is:</p>
  
  <ul>
  <li>GCC is compiled with <code>--with-mode=thumb</code></li>
  <li>A program is compiled without <code>-marm</code> (defaults to thumb mode)</li>
  <li>An assembly section of that program uses ARM mode</li>
  </ul>
  
  <p>I tried compiling a small test program on Raspberry Pi 4 with Ubuntu 18.04.4 kernel 5.3.0-1018-raspi2 and noticed that the <code>.arm</code> section is being executed in 16-bit thumb instruction mode which prompted me to investigate this. This naturally causes a segmentation fault as the program counter is increment by 2 bytes instead of 4.</p>
  
  <p>Here's what gdb in <code>layout asm</code> mode says when my program branches into the .arm assembly code and after I perform a single <code>stepi</code> command:</p>
  
  <pre><code>0x400900 &lt;asm_maxfilter&gt;        push   {r4, lr}
  0x400904 &lt;asm_maxfilter+4&gt;      mov    r3, #0
  0x400908 &lt;filter_loop&gt;          vld1.8 {d0-d1}, [r0]
  
  pc 0x400902 0x400902 &lt;asm_maxfilter+2&gt;
  ^ The program counter is between instructions
  </code></pre>
  
  <p>My code is as follows:</p>
  
  <pre><code>#include &lt;arm_neon.h&gt;
  #include &lt;stdlib.h&gt;
  #include &lt;string.h&gt;
  #include &lt;stdio.h&gt;
  
  void asm_maxfilter(unsigned char* upbuffer, unsigned char* longterm_buffer, int grid_size);
  
  int main(int argc, char** argv) {
  
      const int pixels_per = 16;
      const int grid_reso = 256;
      const int grid_size = grid_reso * grid_reso;
      const int remainder = grid_size % pixels_per;
      const int work_count = grid_size - remainder;
  
      unsigned char* longterm_up = (unsigned char*)malloc(grid_reso * grid_reso);
      memset(longterm_up, 0, grid_reso * grid_reso);
  
      unsigned char* up_buffers[60];
      int u;
      int i;
  
      for (u = 0; u &lt; 60; ++u) {
          up_buffers[u] = (unsigned char*)malloc(grid_reso * grid_reso);
  
          if (up_buffers[u] == NULL) {
              fprintf(stderr, "Failed mallocing\n");
              return 1;
          }
  
          memset(up_buffers[u], 0, grid_reso * grid_reso);
      }
  
      for (u = 0; u &lt; 60; ++u) {
  
          asm_maxfilter(up_buffers[u], longterm_up, work_count);
  
          // non-SIMD version handles the remainder that did not fit in NEON registers
          for (i = grid_size - remainder; i &lt; grid_size; ++i) {
              if (longterm_up[i] &lt; up_buffers[u][i]) {
                  longterm_up[i] = up_buffers[u][i];
              }
          }
      }
  
      for (u = 0; u &lt; 60; ++u) {
          free(up_buffers[u]);
      }
  
      free(longterm_up);
  
      return 0;
  }
  </code></pre>
  
  <p>Assembly:</p>
  
  <pre><code>@ ARM NEON version of a max filter. Performs the following operation:
  @
  @ for (int i = 0; i &lt; buf_size; ++i) {
  @   if (buf_b[i] &lt; buf_a[i]) {
  @       buf_b[i] = buf_a[i];
  @   }
  @ }
  
  .arm
  .section .text
  .align 4
  .globl asm_maxfilter
  
  @ parameters
  @ r0: buf_a
  @ r1: buf_b
  @ r2: buf_size, multiple of 16
  asm_maxfilter:
  
      @ Store register states in stack. They must be restored before returning
      push { r4, lr }
  
      @ Reset counter
      mov r3, #0
  
      filter_loop:
  
          @ Load 16 bytes into vectors
          vld1.u8 {q0}, [r0]
          vld1.u8 {q1}, [r1]
  
          @ Find greater values in each vector
          vcgt.u8 q2, q0, q1
  
          @ Bitselect the greater value into q2
          vbsl.u8 q2, q0, q1
  
          @ Store the larger value in output buffer
          vst1.u8 {q2}, [r1]
  
          @ Increment counter by 16
          add r3, r3, #16
  
          @ Increment pointers
          add r0, r0, #16
          add r1, r1, #16
  
          @ Check if loop is done
          cmp r3, r2
          blt filter_loop
  
      @ Restore registers to their original state
      pop { r4, lr }
  
      @ lr register contains return address
      bx lr
  
  .end
  </code></pre>
  
  <p>The code is compiled using:</p>
  
  <pre><code>gcc -Wall -Wpedantic -O0 -g -march=armv8-a -mfloat-abi=hard -mtune=cortex-a72 -mfpu=neon -c -o main.o main.c
  gcc -Wall -Wpedantic -O0 -g -march=armv8-a -mfloat-abi=hard -mtune=cortex-a72 -mfpu=neon -o neon_test ./main.o ./asm_test.s
  </code></pre>
  
  <p>Based on what the ARM documentation says, if the processor needs to switch between thumb/arm the program should perform a branch using the <code>BLX</code> or <code>BX</code> instruction:</p>
  
  <p><a href="https://developer.arm.com/docs/100076/0100/instruction-set-overview/overview-of-aarch32-state/changing-between-a32-and-t32-instruction-set-states" rel="noreferrer">https://developer.arm.com/docs/100076/0100/instruction-set-overview/overview-of-aarch32-state/changing-between-a32-and-t32-instruction-set-states</a></p>
  
  <p>Quoting:</p>
  
  <pre><code>To direct armasm to generate A32 or T32 instruction encodings, you must set the assembler mode using an ARM or THUMB directive. Assembly code using CODE32 and CODE16 directives can still be assembled, but Arm recommends you use the ARM and THUMB directives for new code.
  
  These directives do not change the instruction set state of the processor. To do this, you must use an appropriate instruction, for example BX or BLX to change between A32 and T32 states when performing a branch.
  </code></pre>
  
  <p>After disassembling my program, I noticed this mode switching is not done. Is this something that the programmer must do themselves in their assembly code (even though the branching happens from the C code), or should the compiler/assembler handle this?</p>
  
  <p>I also tried specifying <code>__attribute__((target("arm")))</code> in the C file function declaration, that is:</p>
  
  <pre><code>__attribute__((target("arm")))
  void asm_maxfilter(unsigned char* upbuffer, unsigned char* longterm_buffer, int grid_size);
  </code></pre>
  
  <p>However, this didn't seem to change anything. Everything works correctly as soon as I compile with <code>-marm</code> or use GCC that doesn't have <code>--with-mode=thumb</code></p>