>In the meantime, Steve, try:-
>
>"THREADENTRY"
>LOCAL FN ThProc(tmp&)
>` dc.l 0x7C00012A ' illegal instruction gives reliable access to MacsBug
>END FN
>
>WINDOW 1
>FN ThProc(9999) ' call ThProc to see deliberate crash, and read RTOC value

Here's a register display when ThProc is called by from within FB:

  PowerPC 604e Registers
                          CR0  CR1  CR2  CR3  CR4  CR5  CR6  CR7
   PC  = 057B9BB4     CR  0100 1010 0000 0000 0000 0000 0100 1010
   LR  = 057B9774         <>=O XEVO
   CTR = 00682800
   MSR = 00000000         SOC Compare Count
   Int = 0            XER 000   00     00                     MQ  = 00000004
 
   R0  = 057B9774     R8  = 00000000      R16 = 00000000      R24 = 05799DA0
   SP  = 057DD6F8     R9  = 00E0F420      R17 = 00000000      R25 = 000233DC
   TOC = 057BB628     R10 = 00000000      R18 = 00000000      R26 = 05799DA0
   R3  = 000003E7     R11 = 002B346C      R19 = 00000000      R27 = 00000000
   R4  = 00000000     R12 = 057B562C      R20 = 00000000      R28 = 00000000
   R5  = 055CB590     R13 = 057DD718      R21 = 00000000      R29 = 00000000
   R6  = 00000000     R14 = 055C9030      R22 = 00000000      R30 = 057BCFF4
   R7  = 00000000     R15 = 00000000      R23 = 00000000      R31 = 000003E7

The TOC value is consistent whether I call FN ThProc from the main 
loop or from a subroutine. It is also consistent if I put the illegal 
statement in main or in another subroutine. I assume TOC stands for 
some reference point in memory relative to where the application was 
loaded? If I disassemble from the TOC memory location, it starts with 
the label "FCOD 03E9 2FBE FB^3.PPC".

>fn StartThread ' let the Thread Manager call ThProc;  read RTOC value
>...
>do
>until fn button
>END

When ThreadManager calls ThProc, here's what the registers look like 
when we hit the debugger:

  PowerPC 604e Registers
                          CR0  CR1  CR2  CR3  CR4  CR5  CR6  CR7
   PC  = 057B9BB4     CR  0010 0000 0000 0000 0000 0000 0000 0000
   LR  = 06D2DC00         <>=O XEVO
   CTR = 057B9B9C
   MSR = 00000000         SOC Compare Count
   Int = 0            XER 000   00     00                     MQ  = 00000004
 
   R0  = 06D2DC00     R8  = 00000000      R16 = 00000000      R24 = 00000000
   SP  = 055D1238     R9  = 00000000      R17 = 00000000      R25 = 00000000
   TOC = 055D16E0     R10 = 00000000      R18 = 00000000      R26 = 00000000
   R3  = 057DD738     R11 = 00000000      R19 = 00000000      R27 = 00000000
   R4  = 055C2B60     R12 = 057DD734      R20 = 00000000      R28 = 00000000
   R5  = 055C2A94     R13 = 055D1258      R21 = 00000000      R29 = 00000000
   R6  = 055C2A80     R14 = 00000000      R22 = 00000000      R30 = 057DD738
   R7  = 00000000     R15 = 00000000      R23 = 00000000      R31 = 055CB660

The TOC value is consistent over multiple calls from the ThreadManager.

I disassembled from the incorrect TOC location just to see what was 
there. It appears to be in a no-man's land ("no procedure name"), 
somewhere in the FB runtime (labels like AEOPENAPP, AEQUITAPP, and 
FBAEPRINTDOC appear some 20 instructions later.


>The first value of RTOC from the above exercise will be the one that the FB
>runtime expects. The second value will be what the Threasd Manager
>supplied. Place your bets, laze and gemmun, rien ne va plus,  will they be
>the same or will they be different?


If you bet on "different" you were right...

So I presume the next step is to somehow save the appropriate RTOC 
register value and somehow restore it upon entry to ThProc... 
<shiver>Do we stick in a placeholder assembler instruction to store 
data to the RTOC and then poke in the correct RTOC value at runtime? 
</shiver>


--Steve