[Bug 33349] New: Use Thumb binaries on ARM?

Bug #: 33349 Summary: Use Thumb binaries on ARM? Product: Wine Version: 1.5.27 Platform: arm OS/Version: Linux Status: NEW Keywords: patch Severity: enhancement Priority: P2 Component: build-env AssignedTo: wine-bugs@winehq.org ReportedBy: nerv@dawncrow.de CC: focht@gmx.net Classification: Unclassified

Created attachment 44115 --> http://bugs.winehq.org/attachment.cgi?id=44115 -mthumb -mthumb-interwork

We currently compile with "-marm", maybe we should use "-mthumb -mthumb-interwork", or even without -mthumb-interwork?

@Anastasius: Would you mind testing the attached patch with some ARM apps, especially with apps/msi that originate from MS, to see if it's the same behaviour as with -marm? Bonus would be to try the same without -mthumb-interwork. make clean should be needed i guess.

I had a quick look at ELF sizes. it seems around 20% reduction in size with "-mthumb -mthumb-interwork" is possible without "-g".

-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Show replies by date

wine-bugs＠winehq.org

12 Apr 12 Apr

9:50 p.m.

New subject: [Bug 33349] Use Thumb binaries on ARM?

--- Comment #1 from Anastasius Focht focht@gmx.net 2013-04-12 16:50:51 CDT --- Hello André,

as I told in earlier Wine/ARM bugs, Thumb-2 is the default for Win32 ARM PE binaries. Most ARM Linux distros (Debian, Ubuntu, Fedora?) use ARMv7-A + VFPv3-D16 + Thumb-2 profile (Cortex-A). So forcing Wine code to be compiled for ARM mode on these systems is not optimal.

For the compiler flags, yes "-mthumb" would be sufficient, no need for "-mthumb-interwork". My toolchains have Thumb-2 as default profile, so there would be no need for any CFLAGS override.

Building Wine as thumb code causes issues for "naked" functions with explicit ".arm" directive because the linker won't insert ARM-Thumb interworking veneers automatically. Raising "unimplemented API" exception currently fails because of that:

--- snip --- Wine-gdb> bt #0 0x4016970a in RtlRaiseException (rec=0x40c99310) at /home/linaro/wine/wine-git/dlls/ntdll/signal_arm.c:1081 #1 0x401421b2 in stub_entry_point (dll=0x4ea2c4 "KERNEL32.dll", name=0x4eb05a "InitOnceExecuteOnce", ret_addr=0x49c9b7) at /home/linaro/wine/wine-git/dlls/ntdll/loader.c:197 #2 0x0049c9b6 in ?? () #3 0x0049c9b6 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) Wine-gdb> p *rec $1 = {ExceptionCode = 2147483904, ExceptionFlags = 1, ExceptionRecord = 0x0, ExceptionAddress = 0x49c9b7, NumberParameters = 2, ExceptionInformation = {5153476, 5156954, 1082964736, 5209840, 1075310241, 1075567040, 1082964736, 5209840, 1075310241, 4294967295, 1082642532, 1082642576, 0, 1086952288, 1074973151}} --- snip ---

RtlRaiseException as Thumb-2 code:

--- snip --- Wine-gdb> disas Dump of assembler code for function RtlRaiseException: 0x401696fc <+0>: push {r7, lr} 0x401696fe <+2>: sub sp, #88 ; 0x58 0x40169700 <+4>: add r7, sp, #0 0x40169702 <+6>: str r0, [r7, #4] 0x40169704 <+8>: add.w r3, r7, #12 0x40169708 <+12>: mov r0, r3 => 0x4016970a <+14>: bl 0x40168050 <RtlCaptureContext> 0x4016970e <+18>: ldr r3, [r7, #76] ; 0x4c 0x40169710 <+20>: mov r2, r3 0x40169712 <+22>: ldr r3, [r7, #4] 0x40169714 <+24>: str r2, [r3, #12] 0x40169716 <+26>: add.w r3, r7, #12 0x4016971a <+30>: ldr r0, [r7, #4] 0x4016971c <+32>: mov r1, r3 0x4016971e <+34>: mov.w r2, #1 0x40169722 <+38>: bl 0x40168668 <raise_exception> ... --- snip ---

RtlCaptureContext is forced ARM code (naked, explicit ".arm" directive -> no veneer to switch to arm mode):

--- snip --- Wine-gdb> disas Dump of assembler code for function RtlCaptureContext: => 0x40168050 <+0>: push {r1} 0x40168054 <+4>: mov r1, #64 ; 0x40 0x40168058 <+8>: add r1, r1, #3 0x4016805c <+12>: str r1, [r0] 0x40168060 <+16>: pop {r1} 0x40168064 <+20>: str r0, [r0, #4] 0x40168068 <+24>: str r1, [r0, #8] 0x4016806c <+28>: str r2, [r0, #12] 0x40168070 <+32>: str r3, [r0, #16] 0x40168074 <+36>: str r4, [r0, #20] --- snip ---

T-bit set in CPSR (thumb mode):

--- snip --- Wine-gdb> info reg r0 0x40c992ac 1086952108 r1 0x4eb05a 5156954 r2 0x49c9b7 4835767 r3 0x40c992ac 1086952108 r4 0x415e0048 1096679496 r5 0x0 0 r6 0x0 0 r7 0x40c992a0 1086952096 r8 0x1 1 r9 0x0 0 r10 0x40 64 r11 0x40c99370 1086952304 r12 0x401a200c 1075453964 sp 0x40c992a0 0x40c992a0 lr 0x4016970f 1075222287 pc 0x40168050 0x40168050 <RtlCaptureContext> cpsr 0x400f0030 1074724912 --- snip ---

Wine source: http://source.winehq.org/git/wine.git/blob/3c04958b8a47f56a6dfc9ac067ca88f34...

Removing ".arm" directive correctly raises the exception.

Regards

wine-bugs＠winehq.org

13 Apr 13 Apr

3:20 p.m.

New subject: [Bug 33349] Use Thumb binaries on ARM?

--- Comment #2 from André H. nerv@dawncrow.de 2013-04-13 10:20:40 CDT --- (In reply to comment #1)

Hello André,

as I told in earlier Wine/ARM bugs, Thumb-2 is the default for Win32 ARM PE binaries. Most ARM Linux distros (Debian, Ubuntu, Fedora?) use ARMv7-A + VFPv3-D16 + Thumb-2 profile (Cortex-A). So forcing Wine code to be compiled for ARM mode on these systems is not optimal.

For the compiler flags, yes "-mthumb" would be sufficient, no need for "-mthumb-interwork". My toolchains have Thumb-2 as default profile, so there would be no need for any CFLAGS override.

Building Wine as thumb code causes issues for "naked" functions with explicit ".arm" directive because the linker won't insert ARM-Thumb interworking veneers automatically. Raising "unimplemented API" exception currently fails because of that:

That's one of those things -mthumb-interwork is for and it doesn't increase the size of the binaries, so to be sure i'd rather use it. Further RtlCaptureContext needs to be ARM or Thumb-2 because of the instructions used, but as long as possible i also want to support older ARM chips at least for winelib. So i choose to use ARM assembler for such functions (same for relay logging, which actually only works with -marm)

wine-bugs＠winehq.org

14 Apr 14 Apr

3:47 p.m.

New subject: [Bug 33349] Use Thumb binaries on ARM?

--- Comment #3 from Anastasius Focht focht@gmx.net 2013-04-14 10:47:40 CDT --- Hello André,

--- quote --- That's one of those things -mthumb-interwork is for and it doesn't increase the size of the binaries, so to be sure i'd rather use it. --- quote ---

Adding "-mthumb-interwork" to CFLAGS (CFLAGS="$CFLAGS -mthumb -mthumb-interwork") doesn't change anything (clean rebuild), there is no veneer inserted to switch to arm mode.

--- snip --- $ winedbg --gdb ./miranda32.exe ... Program received signal SIGSEGV, Segmentation fault. 0x404dc7ac in raise_exception (rec=0x0, context=0x0, first_chance=1087831368) at /home/linaro/wine/wine-git/dlls/ntdll/signal_arm.c:530 530 TRACE(" r4:%04x r5:%04x r6:%04x r7:%04x r8:%04x r9:%04x r10:%04x Fp:%04x Ip:%04x\n", Wine-gdb> bt #0 0x404dc7ac in raise_exception (rec=0x0, context=0x0, first_chance=1087831368) at /home/linaro/wine/wine-git/dlls/ntdll/signal_arm.c:530 #1 0x40a81b76 in RaiseException (code=2147483904, flags=1, nbargs=2, args=0x40d6fda8) at /home/linaro/wine/wine-git/dlls/kernel32/except.c:84 #2 0x4185a02e in __wine_spec_unimplemented_stub (module=0x4185a036 "msvcr110.dll", function=0x4185db3d "__crtGetShowWindowMode") at /home/linaro/wine/wine-git/dlls/winecrt0/stub.c:34 #3 0x41857e5c in __wine_stub___crtGetShowWindowMode () from /home/linaro/wine/wine-install/bin/../lib/wine/msvcr110.dll.so #4 0x41857e5c in __wine_stub___crtGetShowWindowMode () from /home/linaro/wine/wine-install/bin/../lib/wine/msvcr110.dll.so --- snip ---

Disassembly is the same as posted in my comment #1

--- quote --- Further RtlCaptureContext needs to be ARM or Thumb-2 because of the instructions used, but as long as possible i also want to support older ARM chips at least for winelib. So i choose to use ARM assembler for such functions (same for relay logging, which actually only works with -marm) --- quote ---

Exactly, older pre-ARMv7 (not counting ARMv6-T2) will only run winelib apps. No Win32 ARM PE applications created by Microsoft compilers will ever run on these (ARMv7 + Thumb-2 is minimum profile for target). Well, maybe if mingw-w64-arm catches up someday and open source applications are recompiled to arm code - though the usefulness remains doubtful.

I don't see a problem here with RtlCaptureContext() being Thumb-2. The assembly instructions you used are valid for Thumb-2.

Removing ".arm" directive results in following Thumb-2 code:

--- snip --- Wine-gdb> disas RtlCaptureContext 0x40291050 <+0>: str.w r1, [sp, #-4]! 0x40291054 <+4>: mov.w r1, #64 ; 0x40 0x40291058 <+8>: add.w r1, r1, #3 0x4029105c <+12>: str r1, [r0, #0] 0x4029105e <+14>: pop {r1} 0x40291060 <+16>: str r0, [r0, #4] 0x40291062 <+18>: str r1, [r0, #8] 0x40291064 <+20>: str r2, [r0, #12] 0x40291066 <+22>: str r3, [r0, #16] 0x40291068 <+24>: str r4, [r0, #20] 0x4029106a <+26>: str r5, [r0, #24] 0x4029106c <+28>: str r6, [r0, #28] 0x4029106e <+30>: str r7, [r0, #32] 0x40291070 <+32>: str.w r8, [r0, #36] ; 0x24 0x40291074 <+36>: str.w r9, [r0, #40] ; 0x28 0x40291078 <+40>: str.w r10, [r0, #44] ; 0x2c 0x4029107c <+44>: str.w r11, [r0, #48] ; 0x30 0x40291080 <+48>: str.w r12, [r0, #52] ; 0x34 0x40291084 <+52>: str.w sp, [r0, #56] ; 0x38 0x40291088 <+56>: str.w lr, [r0, #60] ; 0x3c 0x4029108c <+60>: str.w lr, [r0, #64] ; 0x40 0x40291090 <+64>: mrs r1, CPSR 0x40291094 <+68>: str r1, [r0, #68] ; 0x44 0x40291096 <+70>: mov pc, lr 0x40291098 <+72>: nop.w 0x4029109c <+76>: nop.w --- snip ---

The exception is properly raised:

--- snip --- $ wine ./miranda32.exe wine: Call from 0x403956ff to unimplemented function msvcr110.dll.__crtGetShowWindowMode, aborting wine: Unimplemented function msvcr110.dll.__crtGetShowWindowMode called at address 0x403956ff (thread 002a), starting debugger... --- snip ---

Regards

wine-bugs＠winehq.org

7:59 p.m.

New subject: [Bug 33349] Use Thumb binaries on ARM?

--- Comment #4 from André H. nerv@dawncrow.de 2013-04-14 14:59:16 CDT --- (In reply to comment #3)

Hello André,

--- quote --- That's one of those things -mthumb-interwork is for and it doesn't increase the size of the binaries, so to be sure i'd rather use it. --- quote ---

Adding "-mthumb-interwork" to CFLAGS (CFLAGS="$CFLAGS -mthumb -mthumb-interwork") doesn't change anything (clean rebuild), there is no veneer inserted to switch to arm mode.

Oh, you're right. i guess it's more for veneers between object files? anyway, that doesn't help us here.

--- quote --- Further RtlCaptureContext needs to be ARM or Thumb-2 because of the instructions used, but as long as possible i also want to support older ARM chips at least for winelib. So i choose to use ARM assembler for such functions (same for relay logging, which actually only works with -marm) --- quote ---

Exactly, older pre-ARMv7 (not counting ARMv6-T2) will only run winelib apps. No Win32 ARM PE applications created by Microsoft compilers will ever run on these (ARMv7 + Thumb-2 is minimum profile for target). Well, maybe if mingw-w64-arm catches up someday and open source applications are recompiled to arm code - though the usefulness remains doubtful.

I don't see a problem here with RtlCaptureContext() being Thumb-2. The assembly instructions you used are valid for Thumb-2.

Removing ".arm" directive results in following Thumb-2 code:

Sure, but it can't be compiled on e.g. ARMv5 anymore, i really want to avoid loosing support for older chips, of course wihtout putting too much work into it. I don't see a problem compiling it as ARM even when Wine will be compiled for Thumb, we would just need our own veneer or something.

The bigger problem atm is relay tracing and such. I'd need to rewrite nearly every assembler bit in winebuild to use Thumb(1). Again, i really would like to switch to Thumb1, when the compiler chooses Thumb2 on appropriate platforms, fine. atm there are nearly as many valid uses of winelib as of native binaries i guess, so it's worth the work for me.

wine-bugs＠winehq.org

23 Feb 23 Feb

5:47 a.m.

New subject: [Bug 33349] Use Thumb binaries on ARM?

--- Comment #5 from Austin English austinenglish@gmail.com --- This is your friendly reminder that there has been no bug activity for over a year. Is this still an issue in current (1.7.37 or newer) wine? If so, please attach the terminal output in 1.7.37 (see http://wiki.winehq.org/FAQ#get_log).

-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

wine-bugs＠winehq.org

7:10 p.m.

New subject: [Bug 33349] Use Thumb binaries on ARM?

--- Comment #6 from André H. nerv@dawncrow.de --- (In reply to Austin English from comment #5)

This is your friendly reminder that there has been no bug activity for over a year. Is this still an issue in current (1.7.37 or newer) wine? If so, please attach the terminal output in 1.7.37 (see http://wiki.winehq.org/FAQ#get_log).

Still in 1.7.37, but i'll refuse to provide terminal output for this :D

-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

wine-bugs＠winehq.org

20 Aug 20 Aug

11:54 p.m.

New subject: [Bug 33349] Use Thumb binaries on ARM?

Austin English austinenglish@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com

-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

WineHQ Bugzilla

25 May 25 May

1:09 a.m.

New subject: [Bug 33349] Use Thumb binaries on ARM?

--- Comment #7 from Anastasius Focht focht@gmx.net --- Hello folks,

revisiting, still present. It's actually worse now due to various code refactoring (2017-2019?), causing illegal instruction exception even before the (builtin) exe entry point.

signal_start_process -> start_thread/set_cpu_context -> __wine_start_process *boom*

--- snip --- $ WINEDEBUG=+seh,+relay wineboot >>log.txt 2>&1 ... 002c:Ret PE DLL (proc=0x7fad45b5,module=0x7fab0000 L"advapi32.dll",reason=PROCESS_ATTACH,res=0x800efe60) retval=1 002c:trace:seh:raise_exception code=c000001d flags=0 addr=0x7fc2b290 pc=7fc2b290 tid=002c 002c:trace:seh:raise_exception r0=7fb18cd9 r1=7ffcf000 r2=00000000 r3=00000000 r4=00000000 r5=00000000 002c:trace:seh:raise_exception r6=00000000 r7=00000000 r8=00000000 r9=00000000 r10=00000000 r11=00000000 002c:trace:seh:raise_exception r12=00000000 sp=800f0000 lr=00000000 pc=7fc2b290 cpsr=000f0010 002c:err:seh:raise_exception Unhandled exception code c000001d flags 0 addr 0x7fc2b290 --- snip ---

CPSR = 0x000f0010 -> bit 5 (Thumb execution state bit) not set.

--- snip --- 7FC2B28C __wine_start_process 7FC2B28C 7FC2B28C peb = -0x318 7FC2B28C entry = -0x314 7FC2B28C 7FC2B28C entry_0 = R0 ; LPTHREAD_START_ROUTINE 7FC2B28C peb_0 = R1 ; PEB * 7FC2B28C 7FC2B28C PUSH.W {R4-R11,LR} 7FC2B290 SUB.W SP, SP, #0x2FC 7FC2B294 LDR R4, =($_GLOBAL_OFFSET_TABLE_ - 0x7FC2B29E) 7FC2B296 STR peb_0, [SP,#0x320+peb] 7FC2B298 STR entry_0, [SP,#0x320+entry] 7FC2B29A ADD R4, PC ; $_GLOBAL_OFFSET_TABLE_ 7FC2B29C CMP entry_0, #0 ... --- snip ---

$ wine --version wine-5.9

Regards

-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

WineHQ Bugzilla

1 Aug 1 Aug

6:59 p.m.

New subject: [Bug 33349] Use Thumb binaries on ARM?

--- Comment #8 from Austin English austinenglish@gmail.com --- Created attachment 67856 --> https://bugs.winehq.org/attachment.cgi?id=67856 wip thumb

I tried changing -marm to -mthumb. Compiling then fails with: <inline asm>:6:2: error: target does not support ARM mode

removing that line from dlls/rcprt4/ndr_stubles.c and dlls/vcomp/main.c. It then fails with <inline asm>:15:2: error: predicated instructions must be in IT block subeq SP, SP, #4

Adding -mimplicit-it=thumb gets past that. I also added -Wignored-attributes to ignore a flood of: ../../include/msvcrt/stdio.h:451:19: warning: 'pcs' calling convention is not supported for this target [-Wignored-attributes]

That then builds with llvm-mingw-20200526 / gcc 8.3.0.

However, it crashes on start: austin@PrawnOS:~/wine-git-mingw$ ./wine cmd 002c:err:seh:raise_exception Unhandled exception code c000001d flags 0 addr 0x7fc39fe0 0024:err:seh:raise_exception Unhandled exception code c000001d flags 0 addr 0x7fc39fe0

-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

WineHQ Bugzilla

2 Aug 2 Aug

6:25 p.m.

New subject: [Bug 33349] Use Thumb binaries on ARM?

--- Comment #9 from Austin English austinenglish@gmail.com --- (In reply to Austin English from comment #8)

However, it crashes on start: austin@PrawnOS:~/wine-git-mingw$ ./wine cmd 002c:err:seh:raise_exception Unhandled exception code c000001d flags 0 addr 0x7fc39fe0 0024:err:seh:raise_exception Unhandled exception code c000001d flags 0 addr 0x7fc39fe0

Same when using the patch without mingw.

-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

WineHQ Bugzilla

8 Aug 8 Aug

11:22 a.m.

New subject: [Bug 33349] Use Thumb binaries on ARM?

--- Comment #10 from André H. nerv@dawncrow.de --- well, I guess one would need to rewrite most if not all ARM assembler to THUMB

-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

WineHQ Bugzilla

21 Jan 21 Jan

10:24 p.m.

New subject: [Bug 33349] Add support for 32-bit ARM Thumb-2 Wine build

Anastasius Focht focht@gmx.net changed:

--- Comment #11 from Anastasius Focht focht@gmx.net --- Hello folks,

this is fixed by recent commit series.

* https://source.winehq.org/git/wine.git/commitdiff/c1a700f018ae86b31c61b0ce4e... ("winebuild: Generate Thumb2-compatible assembly code on ARM.")

* https://source.winehq.org/git/wine.git/commitdiff/7c48d8d44ba70cbfee21e66202... ("winebuild: Support non-PIC mode for ARM targets.")

* https://source.winehq.org/git/wine.git/commitdiff/54cd0e9187da7b592054dc6cbc... ("ntdll: Make inline asm compatible with Thumb-2.")

* https://source.winehq.org/git/wine.git/commitdiff/37c24eabc7ce287ac2941d18bb... ("ntdll: Support Thumb mode in signal handling.")

* https://source.winehq.org/git/wine.git/commitdiff/621c06a082a5507885f2c98815... ("rpcrt4: Make inline asm compatible with Thumb-2.")

* https://source.winehq.org/git/wine.git/commitdiff/6083c69a3b4f4432e06ed8803e... ("vcomp: Make inline asm compatible with Thumb-2.")

* https://source.winehq.org/git/wine.git/commitdiff/405e128b0b3a9661bd3db59608... ("configure: Default to Thumb-2 mode for ARM. ")

Thanks Alexandre.

I've reactivated one of my older 64-bit ARM playground boards for testing (HiKey960 with 4x Cortex A73 + 4x Cortex A53 Big.Little CPU and ARM Mali G71 MP8 GPU). I still had a Yocto based aarch64/armv7ve-hf multilib distro flashed on it to be able to run both, aarch64 and armv7(th2hf) Wine at the same time on the same system.

All Wine builtins seem to work properly so far with Thumb2 build of Wine. I've tested with 'wordpad' and the like. Additionally I ran some 32-bit ARM Thumb(2) apps I found on the Internet:

* Notepad2 for ARM32 * Miranda32 for ARM * VC++ redist

They all started up fine, showing main user interface. There were some relocation block processing errors:

--- snip --- ... 0024:err:module:LdrProcessRelocationBlock resulting immediate value won't fit: 000100d0 ... --- snip ---

but the apps still started.

---

To be able to build Wine with Poky SDK (Yocto) cross-toolchains I still had to apply two patches:

* bug 46053 ("Support cross-toolchains that need target sysroot explicitly passed via '--sysroot' command-line option (Yocto/Poky SDK)")

* bug 46079 ("Support 32-bit ARM hard-float cross-toolchains with GNU binutils assembler that doesn't implicitly assume '.fpu {vfp,neon}' (Yocto/Poky SDK)") -> that one needed an additional tweak to support -march=xx injection as well. I ran into a problem that unified assembler syntax lead to very obscure build errors because the (cross) toolchain builtin default 'armv5t' won't work with some UAL mov immediate encodings by design (mov vs. movs etc.). With a small patch to 'configure.ac' (and regenerate) to inject '-march=xx' and '-mfpu=xx' options to TARGETFLAGS I was able to fix it.

Toolchain tune (in Yocto speak): armv7vet2hf-neon-vfpv4

--- snip --- ... CC = arm-pokymllib32-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/focht/projects/poky-sdk-install/sysroots/aarch64-poky-linux CXX = arm-pokymllib32-linux-gnueabi-g++ -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/focht/projects/poky-sdk-install/sysroots/aarch64-poky-linux CPPBIN = arm-pokymllib32-linux-gnueabi-cpp CROSSCC = CFLAGS = -g -O2 -mthumb -mfloat-abi=hard -march=armv7ve -mfpu=neon -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 CPPFLAGS = CROSSCFLAGS = CROSSLDFLAGS = EXTRACFLAGS = -Wall -pipe -fcf-protection=none -fno-stack-protector -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wno-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf EXTRACROSSCFLAGS= MSVCRTFLAGS = -fno-builtin -fshort-wchar TARGETFLAGS = -b arm-pokymllib32-linux-gnueabi -mthumb -mfloat-abi=hard -march=armv7ve -mfpu=neon LDDLLFLAGS = -fPIC -fasynchronous-unwind-tables LDEXECFLAGS = LIBS = -ldl ... TOOLSDIR = /home/focht/projects/wine/mainline-build-x86_64 LD = arm-pokymllib32-linux-gnueabi-ld --sysroot=/home/focht/projects/poky-sdk-install/sysroots/aarch64-poky-linux LDFLAGS = -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong -Wl,-z,relro,-z,now DLLFLAGS = -D_REENTRANT -fPIC -fasynchronous-unwind-tables --- snip ---

--- snip --- $ uname -a Linux hikey960 4.20.0+ #1 SMP PREEMPT Wed Jan 2 19:22:38 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux

$ file /home/focht/projects/wine/mainline-install-arm/bin/wine /home/focht/projects/wine/mainline-install-arm/bin/wine: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=c2b4472be6bf82afe65195ad56217f34f69f3a3d, for GNU/Linux 3.2.0, with debug_info, not stripped --- snip ---

$ wine --version wine-6.0-111-gf03db0f75e9

Regards

-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

WineHQ Bugzilla

29 Jan 29 Jan

9:10 p.m.

New subject: [Bug 33349] Add support for 32-bit ARM Thumb-2 Wine build

Alexandre Julliard julliard@winehq.org changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED

--- Comment #12 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.1.

-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

WineHQ Bugzilla

19 Feb 19 Feb

11:49 p.m.

New subject: [Bug 33349] Add support for 32-bit ARM Thumb-2 Wine build