[armel] gcc computes wrong address for main() at build time

Amendment: Also occurs on amd64

mcasadevall@daybreak:/tmp$ uname -a
Linux daybreak 2.6.38-2-generic #29-Ubuntu SMP Fri Feb 4 13:03:04 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
mcasadevall@daybreak:/tmp$ gcc -O2 test.c
test.c: In function ‘main’:
test.c:3:13: warning: cast from pointer to integer of different size
test.c:3:25: warning: incompatible implicit declaration of built-in function ‘printf’

Disregard it affecting on x86, false-positive as it also still occurs with -O0 on that platform.

Here's what gdb shows:

Breakpoint 1, main () at testcase.c:4
4 void *p = main;
(gdb) disas
Dump of assembler code for function main:
   0x00008390 <+0>: push {r7, lr}
   0x00008392 <+2>: sub sp, #8
   0x00008394 <+4>: add r7, sp, #0
=> 0x00008396 <+6>: movw r3, #33681 ; 0x8391
   0x0000839a <+10>: movt r3, #0
   0x0000839e <+14>: str r3, [r7, #4]
   0x000083a0 <+16>: ldr r3, [r7, #4]
   0x000083a2 <+18>: and.w r3, r3, #1
   0x000083a6 <+22>: uxtb r3, r3
   0x000083a8 <+24>: cmp r3, #0
   0x000083aa <+26>: beq.n 0x83b8 <main+40>
   0x000083ac <+28>: movw r0, #33808 ; 0x8410
   0x000083b0 <+32>: movt r0, #0
   0x000083b4 <+36>: blx 0x8304 <puts>
   0x000083b8 <+40>: add.w r7, r7, #8
   0x000083bc <+44>: mov sp, r7
   0x000083be <+46>: pop {r7, pc}
End of assembler dump.

So the issue isn't that & is working incorrectly, the issue is that the address of main according to gcc is given as 0x8391 and this seems to not be what we want. (gdb has a different idea of main's address, for instance - 0x8396.)

This is reproducible with gcc-4.5 4.5.1-8ubuntu2, the version being used at natty open. So it seems to be a longstanding bug.

Not reproducible when building with -O1 or -O2 because gcc optimizes the code out completely (getting the right answer for the address of main in this case... or at least the right parity).

Not reproducible when building with -marm.

Not sure if this is relevant, but I seem to be seeing something slightly different. I also added a printf to see what it thinks the value of p is, and tested this with gcc-4.3, 4.4, 4.5:

gcc version 4.3.5 (Ubuntu 4.3.5-3ubuntu1)
without -O2:
p=0x83e0
with -O2:
p=0x83e0

gcc version 4.4.5 (Ubuntu/Linaro 4.4.5-11ubuntu1)
without -O2:
HIT!
p=0x83c1
with -O2:
HIT!
p=0x83c5

gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-3ubuntu1)
without -O2:
HIT!
p=0x83c1
with -O2:
p=0x8399

gcc-4.3 was the only consistent one, but it did not have -mthumb enabled by default.
with gcc-4.3 -mthumb, I get the same thing with or without using -O2:
HIT!
p=0x83e1

@paul: the address will be changing due to the code before it changing at different optimisation levels. The important thing is that in ARM mode the LSB is clear, while in Thumb mode the LSB is set in all situations.

@steve: GDB has set the breakpoint at the first interesting instruction after the prologue, which is fine. GCC seems to be correct - if you want to jump to main, you want to jump to address 0x8390 in Thumb mode (i.e. LSB set).

Confirmed in Linaro GCC 4.5-2011.02-0. I assume that GCC is looking at the type, checking the expected alignment, and then inferring what the value of the LSB should be. This code:

extern int foo;

void main()
{
           void *p = &foo;
           if ((int)p & 1) printf ("HIT!\n");
}

gets optimised away into a bx lr as an int should be word aligned, so the lower two bits should be zero. This code:

extern char foo;

void main()
{
           void *p = &foo;
           if ((int)p & 1) printf ("HIT!\n");
}

doesn't get optimised away as foo could be at an odd address.

I can't remember if casting a function pointer to an int is undefined behaviour. I think it is, so this code is invalid. However it is very useful so I think we should support it.

@Steve: if you want GDB to give the true function address use '*main' - 'main' will give the first address after the prologue (at least when setting breakpoints, it does).

@Michael: I think casting pointers from one pointer type to another (type punning) is deeply dodgy due to strict-aliasing rules, but I don't think converting them to integers is a problem (provided they are the same width).

The bug here appears to be that GCC assumes that function pointer are always aligned, but fails to realise that thumb function pointers are always aligned+1, so to speak. I don't think it will be too hard to fix it.

(Of course, fixing GCC so it's consistent probably won't help mono - that'll still need a fix. In my experience, this concept of off-by-one pointers breaks many, many things in 'interesting' ways.)

I'm fairly sure this exists in FSF 4.5 but will confirm. FSF bugs are are lower priority to us and we're a bit swamped at the moment so I'm afraid this may not be fixed soon.

A work around would be to break GCC's knowledge of the alignment of the variable. Passing it through another function would do it, but there's probably a better way too.

Changing bug to Won't Fix for Natty and retargetting to Oneiric. If this can not be worked around, please update status back to confirmed, and will work with teams to see what options are possible.

I see a very similar issue even with -O0 when using GCC 4.5.2-8ubuntu1 on my ARM board.

Here is a simple test:
<snip>
$ cat test.c && gcc -O0 -Wall -Winline test.c -o test.bin && echo "O0:" && ./test.bin && gcc -O2 -Wall -Winline test.c -o test.bin && echo "O2:" && ./test.bin

#include <stdio.h>

static long __attribute__ ((noinline))
getfp (void *p)
{
  return (long) p;
}

static void __attribute__ ((noinline))
myfunc(long fp, long foo, long bar, long code, long thumb, long thumb2)
{
  printf ("\tfp: 0x%lx\n", fp);
  printf ("\tfoo: 0x%lx\n", foo);
  printf ("\tbar: 0x%lx\n", bar);
  printf ("\tcode: 0x%lx\n", code);
  printf ("\tthumb: 0x%lx\n", thumb);
  printf ("\tthumb2: 0x%lx\n", thumb2);
}

int main()
{
  long fp = (long) myfunc;
  long foo = fp & 0x1L;
  long bar = getfp (myfunc);
  long code = (long) myfunc & ~0x1L;
  long thumb = (long) myfunc & 0x1L;
  long thumb2 = getfp (myfunc) & 0x1L;
  myfunc(fp, foo, bar, code, thumb, thumb2);
  return 0;
}

O0:
        fp: 0x83b1
        foo: 0x1
        bar: 0x83b1
        code: 0x83b0
        thumb: 0x0
        thumb2: 0x1
O2:
        fp: 0x83a1
        foo: 0x0
        bar: 0x83a1
        code: 0x83a0
        thumb: 0x0
        thumb2: 0x1
</snip>

The interesting thing is the " (long) myfunc & 0x1L".

As shown above this bug makes it a bit difficult to obtain the thumb marker.

Hi Ken. I'm not surprised by the results above. At all optimisation levels, GCC knows the alignment of a variable and therefore knows the value of the lower bits. At -O0 'foo' works as this information isn't propagated to the next line. 'thumb' fails as the value and alignment are available right there in the expression.

-O2 is as expected. 'foo' is different as the value propagates to the fp & 0x1L expression.

Note that the work-around of pushing the value through the getfp() function works correctly.

GCC is still wrong though...

Is this still an issue with 4.6? Need to understand implications of this for the release please.

This fault exists in all upstream versions from 4.5 onwards including recent trunk:

michaelh@ursa2:~/linaro/bugs$ uname -a
Linux ursa2 2.6.35.3-cbuild2+ #8 SMP Mon Apr 4 12:46:46 NZST 2011 armv7l GNU/Linux

michaelh@ursa2:~/linaro/bugs$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.10
Release: 10.10
Codename: maverick

michaelh@ursa2:~/linaro/bugs$ /tools/toolchains/gcc-4.4.5-armv7l-maverick-cbuild93-ursa2-cortexa8r1/bin/gcc -O2 align.c ; ./a.out
HIT!

michaelh@ursa2:~/linaro/bugs$ /tools/toolchains/gcc-4.5.2-armv7l-maverick-cbuild93-ursa1-cortexa8r1/bin/gcc -O2 align.c ; ./a.out
(nothing)

michaelh@ursa2:~/linaro/bugs$ /tools/toolchains/gcc-4.6.0-armv7l-maverick-cbuild93-ursa1-cortexa8r1/bin/gcc -O2 align.c ; ./a.out
(nothing)

michaelh@ursa2:~/linaro/bugs$ ~/linaro/toolchains/gcc-4.7~svn174044-armv7l-maverick-cbuild120-ursa4-cortexa9r1/bin/gcc -O2 align.c ; ./a.out
(nothing)

I've logged this in GCC bugzilla. We'll get it fixed up there.

This bug was fixed in the package gcc-4.6 - 4.6.1-4ubuntu1

---------------
gcc-4.6 (4.6.1-4ubuntu1) oneiric; urgency=low

  * Merge with Debian.

gcc-4.6 (4.6.1-4) unstable; urgency=low

  * Update to SVN 20110714 (r176280) from the gcc-4_6-branch.
    - Fix PR tree-optimization/49094, PR target/39633, PR c++/49672,
      PR fortran/49698, PR fortran/49690, PR fortran/49562, PR libfortran/49296,
      PR target/49487, PR tree-optimization/49651, PR ada/48711.

  [ Matthias Klose ]
  * Build Go on alpha for gcc-snapshot builds.
  * For multicore ARM, clear both caches, not just the dcache (proposed
    patch by Andrew Haley).
  * Fix for PR rtl-optimization/{48830,48808,48792}, taken from the trunk.
    LP: #807573.
  * Fix PR tree-optimization/49169, optimisations strip the Thumb/ARM mode bit
    off function pointers (Richard Sandiford). LP: #721531.

  [ Marcin Juszkiewicz ]
  * Define DEB_TARGET_MULTIARCH macro.
  * debian/rules2: Macro and configuration consolidation.

gcc-4.6 (4.6.1-3) unstable; urgency=medium

  * Update to SVN 20110709 (r176108) from the gcc-4_6-branch.
    - Fix PR target/49335, PR tree-optimization/49618, PR c++/49598,
      PR fortran/49479, PR target/49621, PR target/46779, PR target/49660,
      PR c/49644, PR debug/49522, PR debug/49522, PR middle-end/49640,
      PR c++/48157, PR c/49644, PR fortran/48926.
    - Apparently fixes a boost issue. Closes: #632938.
  * Apply proposed patch for PR fortran/49690. Closes: #631204.

  * README.Debian: New section 'Former and/or inactive maintainers'.
 -- Matthias Klose <email address hidden> Thu, 14 Jul 2011 20:18:27 +0200

fixed in oneiric in gcc-4.5

For the record, this bites QEMU compiled on Natty as well (and results in an immediate crash on startup).