Comment 18 for bug 810402

It looks like ARM code is being executed as Thumb.

The .s file assembled as ARM because that's always the default if there are no .thumb directives and no -mthumb command-line option. (It would need some minor changes to work in Thumb anyway). However, the CPSR value when we segfault indicates that the processor is executing in Thumb state ((cpsr & 0x20) == 0x20)

We end up in the wrong state because the call originating from caml_main() in the linked program calls caml_start_program with a "bl" instruction, so there is no switch from Thumb to ARM. As a result, we execute garbage at caml_start_program.

This may indicate a bug in the linker, but since none of the symbols in the startup .s file are marked as function symbols, it might be that the linker isn't absolutely required to perform the correct fixup in this case.

Can you try adding a ".type <function name>, %function" directive for each function in the startup .s file?

If assembling and linking the resulting object results in a working program, this suggests that the linker is sensitive to the symbol type when doing branch fixups.

If so, we can work around it my adding all the required .type directives for code symbols in ocaml, but we should still raise the issue as a possible linker bug.

(gdb) r
Starting program: /mnt/a.out

Program received signal SIGSEGV, Segmentation fault.
0x00014f94 in caml_start_program ()
(gdb) i r
r0 0x0 0
r1 0x0 0
r2 0xb8d7 47319
r3 0x0 0
r4 0xbefff9c4 3204446660
r5 0x4 4
r6 0xbefff8c4 3204446404
r7 0x0 0
r8 0x0 0
r9 0x0 0
r10 0x4001e000 1073864704
r11 0x0 0
r12 0x400b98c1 1074501825
sp 0xbefff748 0xbefff748
lr 0x153b1 86961
pc 0x14f94 0x14f94 <caml_start_program>
cpsr 0x40000030 1073741872
(gdb)