qt 4.5 sigbus fault - fixed

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Referring to...

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=78520

I've finally tracked this down to a misaligned 16-bit access in the template function for...

qt_blend_argb24_on_rgb16()

...in qblendfunctions.cpp

It seems it is necessary to add (QT_ARCH_AVR32) into the list of arches which can't handle 16-bit non-aligned access.

I guess I was expecting this to be blindingly obvious once I got to the correct place in the code.

I've not looked at what the compiler generates here, but I believe ARV32 can do some non-aligned operations - seems not in this case.

Thanks for help on this - got there in the end & can now move on and do some applications work.

I'll post this in other places.

Bob

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

{ld,st}.w can handle any alignment (with a performance penalty). I guess the compiler sees the 16-bit-ness of the load and uses the appropriate {ld,st}.[su]h instructions. Fair enough choice really but annoying that it explodes in this way..

Well done and thanks :-)

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!
Could you tell me how to "add (QT_ARCH_AVR32) into the list of arches which can't handle 16-bit non-aligned access."?
Can't find anything in the mkspec/ files ...
Thanks,
Sebastian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!
Ok .. found the place where the patch belongs ... more below ... IT WORKS!
Thanks a lot.

I used it as a debugging/dissasm try, and found the following ... my first attempt at avr32 asm:

Program received signal SIGBUS, Bus error.
0x2acc503c in ?? ()    
(gdb) disass
No function contains program counter for selected frame.
(gdb) disass 0x2acc503c
No function contains specified address.
(gdb) x/10i 0x2acc503c
0x2acc503c:     ld.uh r5,lr[1]
0x2acc5040:     cp.b r9,r8
# 4 bytes back, cmds executed
(gdb) x/10i 0x2acc5038
0x2acc5038:     ld.ub r9,lr[0x0]
0x2acc503a:     mov r8,-1
0x2acc503c:     ld.uh r5,lr[1] # sigbus
0x2acc5040:     cp.b r9,r8
(gdb) info regis
lr             0x6e438  
(gdb) x/10x 0x6e438
0x6e438:        0x09    0x41    0x08    0x04    0x20    0x00    0x00    0x00
0x6e440:        0x00    0x12

so ... the byte pointed at by lr is loaded into r9, then, the halfword pointed at by lr+1 is loaded into r5.
It seems the variable pointed at by lr (char*?) is correctly aligned, but contains binary data that needs to be parsed - bitmap, probably. And, using this code, this will never succeed in a machine that forces alignment.

On the other hand, the compiler should never have generated code that acesses an aligned variable+1 as a word, should it?

Grr, now I see what you meant ... looking into the source code ... someone tried to optimise in a way that uses an explicitly unaligned access.

template  void qt_blend_argb24_on_rgb16(uchar *destPixels, int dbpl,
  const uchar *srcPixels, int sbpl,
  int w, int h, const T &alphaFunc)
...
#if defined(QT_ARCH_ARM) || defined(QT_ARCH_POWERPC) || (defined(QT_ARCH_WINDOWSCE) && !defined(_X86_))
  // non-16-bit aligned memory access is not possible on PowerPC &
  // ARM 

I see where the patch belongs, now ...

BTW, created a debug env for avr32 ... only a tad more than 300MB for the root filesystem ;-)

Thanks again,
Sebastian