armel build failure (thumb problem?)

Bug #635413 reported by Matthias Klose
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openmsx (Ubuntu)
Fix Released
Undecided
Unassigned
Oneiric
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: openmsx

http://launchpadlibrarian.net/52448222/buildlog_ubuntu-maverick-armel.openmsx_0.8.0-1_FAILEDTOBUILD.txt.gz

Creating derived/arm-linux-opt/config/Version.ii...
Creating derived/arm-linux-opt/config/build-info.hh...
Creating derived/arm-linux-opt/config/components.hh...
Compiling Autofire.cc...
{standard input}: Assembler messages:
{standard input}:54: Error: shift must be constant -- `orr r0,r0,r3,LSL r2'
make[1]: *** [derived/arm-linux-opt/obj/Autofire.o] Error 1
make[1]: Leaving directory `/build/buildd/openmsx-0.8.0'
make: *** [build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Revision history for this message
Maarten ter Huurne (maarten-treewalker) wrote :

The openMSX source file src/Autofire.cc does not contain any line assembly nor does it use inline assembly from a header file, so I think it must be the compiler that is generating invalid assembly.

Revision history for this message
Matthias Klose (doko) wrote :

most likely it comes in from a header file, not from the compiler itself

Revision history for this message
Matthias Klose (doko) wrote :
Revision history for this message
Maarten ter Huurne (maarten-treewalker) wrote :

You are right: it does use assembly from a header file (src/utils/DivModBySame.hh), one that I didn't expect at all to be pulled in by Autofire.cc. Thanks for the preprocessed source!

Revision history for this message
Wouter Vermaelen (wouter-vermaelen) wrote :

It might indeed be a problem with thumb, because AFAIK 'orr r0,r0,r3,LSL r2' is a valid ARM mode instruction. How is this code compiled? Does it use ARM or thumb(2) mode? The ARM asm snippets in openMSX are written for ARM mode.

I don't have much experience with thumb(2). Is it possible to force ARM mode? Or is it possible to detect the mode via some preprocessor define? All asm routines have plain c++ fallbacks, so it should be fine to not use the asm routines in thumb mode. Possibly gcc code generation has improved enough so that the asm routines are less needed.

Revision history for this message
Maarten ter Huurne (maarten-treewalker) wrote :

There appears to be a "__thumb__" define that is set when compiling in Thumb mode. We could use that to skip the assembly implementation and fall back to the C++ implementation.

It seems to be possible to mix the normal 32-bit ARM instruction set with Thumb instructions. I don't know though whether the overhead of the mode switch does or does not eliminate the performance advantage of the assembly routine over the C++ version. Also, this will only work if the compilation is done with support for both instruction sets (-mthumb-interwork), which is not enabled by default.

http://www.devrs.com/gba/files/asmc.txt

Revision history for this message
Matthias Klose (doko) wrote :

not the only inline assembler

$ grep -r __arm__ .
./src/utils/DivModBySame.hh: #elif defined(__arm__)
./src/utils/DivModBySame.hh: #ifdef __arm__
./src/utils/MemoryOps.cc:#elif defined __arm__
./src/utils/DivModByConst.hh: #if ASM_X86_32 || defined(__arm__)
./src/utils/DivModByConst.hh: #elif defined(__arm__)
./src/utils/DivModByConst.hh: #if ASM_X86_32 || defined(__arm__)
./src/utils/DivModByConst.hh: #elif defined(__arm__)
./src/video/LineScalers.hh:#ifdef __arm__
./src/video/BitmapConverter.cc:#ifdef __arm__
./src/video/CharacterConverter.cc:#ifdef __arm__
./src/video/CharacterConverter.cc:#ifdef __arm__
./src/sound/ResampleLQ.cc:#ifdef __arm__
./src/sound/ResampleLQ.cc:#ifdef __arm__
./src/sound/AY8910.cc:#ifdef __arm__
./src/sound/MSXMixer.cc:#ifdef __arm__
./src/sound/MSXMixer.cc:#ifdef __arm__
./src/sound/MSXMixer.cc:#ifdef __arm__
./src/sound/SCC.cc:#ifdef __arm__

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openmsx - 0.8.0-1ubuntu1

---------------
openmsx (0.8.0-1ubuntu1) maverick; urgency=low

  * On armel, build with -marm -march=armv6, inline assembler not ready
    for thumb. LP: #635413.
 -- Matthias Klose <email address hidden> Sat, 18 Sep 2010 17:44:28 +0200

Changed in openmsx (Ubuntu):
status: New → Fix Released
Revision history for this message
Matthias Klose (doko) wrote :

reopen the issue, the assembler should be fixed for thumb

Changed in openmsx (Ubuntu):
status: Fix Released → Confirmed
tags: added: arm-mode
Revision history for this message
Richard Earnshaw (richard-earnshaw) wrote :

orr r0,r0,r3,LSL r2

is not a legal thumb2 instruction. Only constant shifts are permitted when the shift is combined with any other operation. This will need to be recoded as
lsl rx, r3, r2
orr r0, r0, rx

where rx is some spare register.

Better still, if the flags are not live, use lsls and orrs to get 16-bit thumb1 instructions.

tags: added: ftbfs
Steve Langasek (vorlon)
tags: added: arm-porting-queue
tags: added: oneiric
Changed in openmsx (Ubuntu):
milestone: none → oneiric-alpha-2
Changed in openmsx (Ubuntu):
milestone: oneiric-alpha-2 → oneiric-alpha-3
Changed in openmsx (Ubuntu Oneiric):
milestone: oneiric-alpha-3 → none
tags: added: universe
Revision history for this message
Stefano Rivera (stefanor) wrote :

This appears to have been fixed upstream. Sync LP: #824542 filed.

Revision history for this message
Matthias Klose (doko) wrote :

0.8.1-3 built in oneiric

Changed in openmsx (Ubuntu Oneiric):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.