http://bugs.winehq.org/show_bug.cgi?id=30134
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
--- Comment #2 from André H. nerv@dawncrow.de 2012-03-27 12:03:02 CDT --- Help, why didn't someone CCed the ARM Guy on that bug???
Anyway, never expected the famous AF to try out my ARM port. The problem looks familiar: "On ARM-Ubuntu it most likely will not run because of compiler problems (if compiled on that platform)" from http://wiki.winehq.org/ARM?action=recall&rev=36
I gave up while debugging and thought it's a compiler bug as it works when compiling inside scratchbox.
--- scratchbox --- gcc -v Using built-in specs. Reading specs from /scratchbox/compilers/cs2007q3-glibc2.5-arm7/gcc.specs rename spec cpp to old_cpp rename spec cc1 to old_cc1 rename spec link to old_link rename spec mflib to old_mflib Target: arm-none-linux-gnueabi Configured with: /home/jhakala/cs2007q3-sb8/arm/src/gcc-4.2/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --enable-shared --enable-symvers=gnu --enable-__cxa_atexit --disable-nls --prefix=/opt/maemo --with-sysroot=/opt/maemo/arm-none-linux-gnueabi/libc --with-build-sysroot=/home/jhakala/cs2007q3-sb8/arm/install/arm-none-linux-gnueabi/libc --with-build-time-tools=/home/jhakala/cs2007q3-sb8/arm/install/arm-none-linux-gnueabi/bin Thread model: posix gcc version 4.2.1 --- /scratchbox ---
---> no --with-mode=... (seems to default to arm then)
--- linaro@pandaboard --- gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.5.2/lto-wrapper Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=arm-linux-gnueabi --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/arm-linux-gnueabi --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/arm-linux-gnueabi --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi Thread model: posix gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) --- /linaro@pandaboard ---
---> --with-mode=thumb
So what we are doing is --- spec32.c --- output( "\tb 1f\n" ); --- /spec32.c --- which places "b 1f" into an assembler file. The question is why the hell the assembler places that as arm32 instruction directly behind thumb instructions??? it should know better (that's why i still think that might be a compiler/assembler bug)! Aside that we should really change our code to be more foolproof. Now we can - after that really good analysis. I'll have a look a that and further on the import thunk thing, but i don't fully understand:
--- quote --- It seems the import thunks are now considered thumb (same .s spec file) but the actual function code was generated as separate .o with 32 bit ARM code through C compiler (-marm). --- /quote ---
spec file? thumb?
Thanks for the bug report, the analysis and further explanations :) For the future: Be free to CC me on ARM related bugs.