http://bugs.winehq.org/show_bug.cgi?id=30134
--- Comment #10 from Anastasius Focht focht@gmx.net 2012-04-12 18:44:54 CDT --- Hello André,
--- quote --- small step --- quote ---
for man ... one giant leap for mankind ;-)
Not sure if it's worth to pursue full Thumb1 compatibility for all "generated" code passed to assembler. Everything else will be Thumb2 anyway when built with modern toolchains using Cortex-A profiles.
From what I've read, native Windows-on-ARM apps/code will make use of Thumb2
instruction set which actually makes sense if you look at the required minimum specs for Windows on ARM (ARMv7 and above). Not taking advantage of the instruction set just wastes lots of potential (code density).
Some links:
http://blogs.msdn.com/b/b8/archive/2012/02/09/building-windows-for-the-arm-p...
http://www.bitcrazed.com/post/2011/09/20/Visual-Studio-11-Developer-Preview-...
(disassembly screenshot indicates Thumb2).
--- quote --- i played a bit with: case CPU_ARM: output( "\tldr r0,[pc,#0]\n" ); output( "\tmov pc, r0\n" ); output( "\t.long 1f\n" );
and forcing "as" to -mthumb (that code can be compiled to arm and thumb) without good results... maybe you can debug that further... --- quote ---
You need something that gets it right for ARM, "old" Thumb1 and Thumb2 without mode switching.
You could make use of "ADR" pseudo instruction. Something like this might work:
--- snip --- adr r0, 2f ldr r0, [r0] mov pc, r0 .align 2: .long 1f __wine_spec_pe_header: .skip xxx 1: ... --- snip ---
Regards