398169 - PPC mac GET_STACK_EXTENTS problem for large binaries (from AIR team)

Status: VERIFIED FIXED

(Tamarin Graveyard :: Garbage Collection (mmGC), defect)

Description

[Tommy Reilly]

I saw an error just like that when building the AIR runtime for PPC with xcode a long time ago.  I remember tracking it down to some inline PPC assembly that had a jump instruction that was "jumping forward" to a label it should have been "jumping backward" to.  The code in question can be viewed here ( it is actually in the new action script vm ): http://hg.mozilla.org/tamarin-central/?file/e14dd259de12/MMgc/GC.h  Line 102.
 
Here is the fixed code:
#define MMGC_GET_STACK_EXENTS(_gc, _stack, _size) \
  int __ppcregs[20]; \
  asm("stmw r13,0(%0)" : : "b" (__ppcregs));\
  _stack = __ppcregs;\
  void *__stackBase;\
  asm ("mr r3,r1\n"\
       "1: mr %0,r3\n" \
   "lwz r3,0(%0)\n"\
          "rlwinm r3,r3,0,0,30\n"\
   "cmpi cr0,r3,0\n"\
       "bne 1b" : "=b" (__stackBase) :: "r3"); \
  _size = (uintptr) __stackBase - (uintptr) _stack;
 
 
Notice the bne instruction at the end now uses the 1b label, which means the lable 1 above.  The code in the MMgc main line is using an absolute lable which will not work if the binary gets too big.
 
Chris

Comment 1

[Dan Schaffer]

Tom thought is probably fixed.  How can we confirm it is fixed?

Comment 2

[Edwin Smith]

The redux code for gcc mac looks like the "fixed" code above.  For gcc, ppc, non-mac (linux ppc?) and for non-gcc (codewarrior) the code is still the old incorrect code.

afaik we don't support codewarrior or linux-ppc, but before closing this bug we should either fix the code or remove and replace with #error.

Comment 3

[Tommy Reilly]

closing, this is no longer done with assembly

Comment 4

[Chris Peyer]

removing QRB request, bug verified