[futurebasic] Re: [FB] FB^3 Threading Puzzle (continuing saga)

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : September 1999 : Group Archive : Group : All Groups

From: "Dr. Stratford" <sstratford@...>
Date: Wed, 29 Sep 1999 14:38:01 -0500
>The story so far
>---------------

Good synopsis of the puzzle so far...educational, too. Isn't learning 
fun?!?! :)

>Back to Steven, whose problem we now believe to be this:
>The ThreadManagerBoys work over the corridor from the MixedMode place, and
>don't talk to those guys. So the Thread Manager call-back doesn't follow
>the rules. It doesn't want the FB function to be prefaced by a UPP; it
>wants plain unwrapped executable code. Steven thus has the strange, and we
>hope rare, task of (a) persuading FB not make a UPP, and (b) still being
>able to pass the correct address of the FN to the OS.
>
>Task (a) is immediately solved: don't use ENTERPROC/EXITPROC.
>
>For Task (b) there are (at least) 3 ways in FB^3 to get the address of some
>code. The most obvious is PROC.
>
>From some tests with PROC (and no ENTERPROC/EXITPROC) I can report a Bad
>Experience. One of the things PROC does is to modify the contents of the
>UPP.  But if there's no UPP, it ends up trampling on code instead. No go.
>
>Another obvious one is LINE.
>The FB^3 documentation isn't very encouraging on this. But remember that we
>are working in a domain of ignorance far beyond that even of Release 0 of
>the FB^3 Reference! And Stephen's recent Bad Experience with LINE and
>ENTERPROC/EXITPROC isn't relevant either, because he's going to remove
>ENTERPROC/EXITPROC. My tests with LINE look hopeful, except for one teeny
>glitch: LINE "THREADENTRY" returns a pointer to the line _before_ the
>function. I've fixed that up in the test program below.

Test with the (LINE "THREADENTRY")+4 option plus LOCAL FN 
ThProc(tmp&) results in a solid hard freeze, not even dropping into 
Macsbug.

Here's the trail up until the freeze (ThreadEntryProc& = 05973F84):

Displaying memory from 5973f84
   05973F84  7C08 02A6 9001 0008  BDA1 FFA0 9421 FF58
   05973F94  39A1 0020 906D 0020  3860 05D4 4BFE 1771
   05973FA4  4BFF EF91 4BFF EFD1  83ED 0020 7FE3 FB78
  Disassembling PowerPC code from 5973f84
   THPROC..
      +00004 05973F84   mflr       r0                         ; LR = 
0x0008 | 7C0802A6
      +00008 05973F88   stw        r0,0x0008(SP) 
| 90010008
      +0000C 05973F8C   stmw       r13,-0x0060(SP) 
| BDA1FFA0
      +00010 05973F90   stwu       SP,-0x00A8(SP) 
| 9421FF58
      +00014 05973F94   addi       r13,SP,0x0020 
| 39A10020
      +00018 05973F98   stw        r3,0x0020(r13) 
| 906D0020
      +0001C 05973F9C   li         r3,0x05D4 
| 386005D4
      +00020 05973FA0   bl         _GETSTRCONST+015C0         ; 
0x05955710 | 4BFE1771
      +00024 05973FA4   bl         _PRINTSTRING+00004         ; 
0x05972F34 | 4BFFEF91
      +00028 05973FA8   bl         _PRINTCR+00004             ; 
0x05972F78 | 4BFFEFD1
      +0002C 05973FAC   lwz        r31,0x0020(r13) 
| 83ED0020
      +00030 05973FB0   mr         r3,r31 
| 7FE3FB78
      +00034 05973FB4   bl         THHNDLR+0005C              ; 
0x05973B3C | 4BFFFB89
      +00038 05973FB8   addi       SP,SP,0x00A8 
| 382100A8
      +0003C 05973FBC   lwz        r0,0x0008(SP) 
| 80010008
      +00040 05973FC0   mtlr       r0                         ; LR = 
0x0008 | 7C0803A6
      +00044 05973FC4   lmw        r13,-0x0060(SP) 
| B9A1FFA0
      +00048 05973FC8   blr 
| 4E800020
      +0004C 05973FCC   addic      r0,r0,0x4E75 
| 30004E75

---->I think that looks ok, but someone else will have to verify that 
it's the way the entry to a function should look in assembler. I set 
a breakpoint at ThreadEntryProc&: (05973F84):
  Break at 05973F84 (THPROC..+00004) every time

---->And here's where the ThreadManager transferred control.

PowerPC breakpoint at 05973F84 THPROC..+00004

---->As soon as I said "go", the computer froze more solid than 
Rover's water dish in January...  (thought maybe some of the rednecks 
on the list would relate to that...) Didn't even drop into Macsbug on 
the crash...

>
>Lastly there's @FN, which I haven't looked into. Let's hope that LINE will
>cut the mustard (idiom for "not crash so severely as to require a reboot")
>when Steven tries the suggestions below in his  thread program.

Derek suggested using
Pascal Fn ThreadEntryProc
   print "stuff"
End fn

and creating the threadprocptr with @Fn ThProc. Here's the trace on that:

ThreadEntryProc& = 05B7DEAC
  Disassembling PowerPC code from 05b7deac
   Goodbye.SDOC
      +00024 05B7DEAC   b          Goodbye.SDOC+00038         ; 
0x05B7DEC0 | 48000014
      +00028 05B7DEB0   mflr       r0                         ; LR = 
0x0008 | 7C0802A6
      +0002C 05B7DEB4   subi       SP,SP,0x0004 
| 3821FFFC

Maybe I need to offset ThreadEntryProc& by 4 here too?

Try again with thredEntryProc& = (@FN ThProc)+4:

thredEntryProc& =0597F4A0
Displaying memory from 0597f4a0
   0597F4A0  7C08 02A6 3821 FFFC  9001 0020 4800 0008
   0597F4B0  4800 0000 8061 0020  3821 0004 7C7F 1B78
   0597F4C0  3860 0004 7C7F 1A14  906D 0120 3860 04B0
  Disassembling PowerPC code from 0597f4a0
   Goodbye.SDOC
      +00028 0597F4A0   mflr       r0                         ; LR = 
0x0008 | 7C0802A6
      +0002C 0597F4A4   subi       SP,SP,0x0004 
| 3821FFFC
      +00030 0597F4A8   stw        r0,0x0020(SP) 
| 90010020
      +00034 0597F4AC   b          Goodbye.SDOC+0003C         ; 
0x0597F4B4 | 48000008
      +00038 0597F4B0   b          Goodbye.SDOC+00038         ; 
0x0597F4B0 | 48000000
      +0003C 0597F4B4   lwz        r3,0x0020(SP) 
| 80610020
      +00040 0597F4B8   addi       SP,SP,0x0004 
| 38210004
      +00044 0597F4BC   mr         r31,r3 
| 7C7F1B78
      +00048 0597F4C0   li         r3,0x0004 
| 38600004
      +0004C 0597F4C4   add        r3,r31,r3 
| 7C7F1A14
      +00050 0597F4C8   stw        r3,0x0120(r13) 
| 906D0120
      +00054 0597F4CC   li         r3,0x04B0 
| 386004B0
      +00058 0597F4D0   bl         _GETSTRCONST+015C0         ; 
0x05960EF0 | 4BFE1A21
      +0005C 0597F4D4   bl         _PUSHSTRING+01C90          ; 
0x059615C0 | 4BFE20ED
      +00060 0597F4D8   lwz        r31,0x0120(r13) 
| 83ED0120
      +00064 0597F4DC   mr         r3,r31 
| 7FE3FB78
      +00068 0597F4E0   bl         _HEX+02A94                 ; 
0x059623C4 | 4BFE2EE5
      +0006C 0597F4E4   bl         _ADDSTRINGS+01D5C          ; 
0x0596168C | 4BFE21A9
      +00070 0597F4E8   addi       r31,r13,0x0020 
| 3BED0020
      +00074 0597F4EC   li         r30,0x0100 
| 3BC00100
  Break at 0597F4A0 (Goodbye.SDOC+00028) every time
PowerPC breakpoint at 0597F4A0 Goodbye.SDOC+00028
PowerPC access exception at CE006B84

---->Actually this disassembled code doesn't look the same as with 
(LINE "THREADENTRY")+4. That one looks right to me (because it 
includes a PRINTSTRING and a call to THHNDLR), because my ThProc fn 
looks like:

"THREADENTRY"
LOCAL FN ThProc(tmp&)
  print "Here we are at ThProc"
  FN ThHndlr(tmp&)
end fn

One or more of the following is probably true:
(1) +4 is not the right offset
(2) jumping into the code like this is insane (probably screwing up the stack)
(3) we are very very close with (LINE "THREADENTRY")+4
(4) we are way way off

--Steve

>
>Robert
>
>'-----------------------------------
>dim gSillyTestProc&
>end globals
>
>clear local
>local fn StartThread
>' of course here we don;t attempt to StartThread; we are just testing
>dim thredEntryProc&
>thredEntryProc& = line "THREADENTRY"' whoops, gets pointer wrong
>#if cpuPPC
>thredEntryProc&=thredEntryProc&+4' fix pointer to executable code
>#else
>thredEntryProc&=thredEntryProc&+6' fix pointer to executable code
>#endif
>' here's the use that Steven will make of thredEntryProc&
>//
>//gOSErr%=FN NewThread(0,thredEntryProc&,t_ThreadData&,0,0,_nil,t_ThreadData&)
>//
>'we'll save a copy for testing this address, and drop into MacsBug for fun
>gSillyTestProc&=thredEntryProc&
>'------------
>DIM db$
>db$ = "thredEntryProc& " + HEX$(thredEntryProc&) + " points to first real
>code of FN ThProc ;il"
>CALL DEBUGSTR(db$)
>'-------------
>end fn
>
>'~Thread Handler Entry
>"THREADENTRY"
>local FN ThProc(tmp&)'this is what the OS is supposed to call
>print "Hello from ThProc" tmp&
>end fn
>
>def fn SillyTestThProc(param&) using gSillyTestProc& ' just for testing
>
>window 1
>fn StartThread' set up gSillyTestProc&
>fn SillyTestThProc(1234)' a test call based on gSillyTestProc&
>do
>until fn button
>end
>'-----------------------------------
>
>
>
>
>
>
>
>
>--
>To unsubscribe, send ANY message to <futurebasic-unsubscribe@...>