>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@...>