Comment 22 for bug 774175

Observation (which may or may not be relevant):
It doesn't seem to get anywhere near main or libc startup (gdb break on main or __start or anything like that just doesn't stop).
Break'ing on _GLOBAL__sub_I_error.cc does stop and is an initialisation routine from the error.cc which is known to be broken.
objdump of the error.opic misdisasembles the first word of this function as:

00000000 <_GLOBAL__sub_I_error.cc>:
   0: 4d08b538 .word 0x4d08b538 <<<<<<<<<<<!!!
   4: 4c08 ldr r4, [pc, #32] ; (28 <_GLOBAL__sub_I_error.cc+0x28>)
   6: 447d add r5, pc
   8: 3508 adds r5, #8
   a: 447c add r4, pc
   c: 4628 mov r0, r5
   e: f7ff fffe bl 0 <_ZNSt8ios_base4InitC1Ev>
  12: 4b06 ldr r3, [pc, #24] ; (2c <_GLOBAL__sub_I_error.cc+0x2c>)
  14: 4628 mov r0, r5
  16: 58e1 ldr r1, [r4, r3]
  18: 4b05 ldr r3, [pc, #20] ; (30 <_GLOBAL__sub_I_error.cc+0x30>)
  1a: 58e2 ldr r2, [r4, r3]
  1c: e8bd 4038 ldmia.w sp!, {r3, r4, r5, lr}
  20: f7ff bffe b.w 0 <__aeabi_atexit>
  24: 0000001a .word 0x0000001a
  28: 0000001a .word 0x0000001a

That's actually a push and ldr; in gdb the instruction actually seems to be there, but when you break on _GLOBAL__sub_I_error you seem to be left at the 1st instruction after the push.

Dave