| Technote PT 590 | October 1990 |
Last reviewed: 6/14/93
I am having difficulty in using SADE on an Omnis 5 external. I have previously succeeded in using SADE on stand-alone code resources called from a standard C application, and with MPW tools.
I place the external code resource in the Omnis 5 application resource fork, when the external executes, SADE yields:
Internal fatal error! Please kill the target process! at uEXTERNAL+$0010 in
"Omnis 5"
EXTERNAL
+0010 001164C8 4E45 **TRAP #$5Note that the TRAP is at the breakpoint address, which makes sense. Somehow SADE is getting confused and failing to recognize the TRAP as the breakpoint. What's happening here?
___
It seems like that TRAP statement you got was something from outer space because the trap-dispatching with Macintosh traps is handled by A-line traps whose opcodes start with hex A. The TRAP opcode is never used as with other operating systems, such as A/UX.
The most likely reason for this behavior is that your code resources were moved around, and SADE picked up whatever it found in that memory location--after that the CODE had moved to another place. In order for SADE to get access to the real CODE resources you need to lock them.
Last reviewed: 6/14/93
What does the SADE error "Cannot determine break address: Could not determine address from available source information" mean and how do I fix it?
___
Two common problems are indicated by with SADE's "Cannot determine break address: Could not determine address from available source information" error message are:
1. not all the source modules have been compiled with -sym on
2. one of the tools that produces .SYM file information does not conform to the latest format definition
For the first problem, put breakpoints everywhere except for where the error occurs, and make sure all source code is compiled with the "-sym on" option.
If you can't set breakpoints, check for the second problem. The MPW 3.2 tools (compilers) generate the symbolic information that the Linker puts together for one single file, so eventually when you use an old tool it will not produce good symbolic information for the final .SYM file.
Check the latest Essentials*Tools*Objects (ETO) CD for the current SADE and MPW tools.
Last reviewed: 6/14/93
What's the cause of the SADE error message, "Invalid A6, A6 must be greater than or equal to SP, and within valid stack range"?
___
The "Invalid A6, A6 must be greater than or equal to SP, and within valid stack range" error message that you are receiving stems from a feature that was placed into SADE 1.3a5. There is a simple fix. You just need to change the WantStackWindow variable located in the SadeStartup file from 1 to 0. (The WantStackWindow variable is about 30 lines down from the top of the SadeStartup file.)
When a user targets an application, SADE launches the application and runs until it hits an internally placed break point. At this point in time, the program is given a name and A6 is basically junk. The WantStackWindow basically tells SADE to check to see if A6 is valid or not as the program is running. When SADE hits the break point, A6 is junk, so the user will receive this error message. As the user continues to run the application, A6 becomes valid and the "error" no longer exists.
To sum it up, when WantStackWindow is set to 1, and your program is not running you will receive this error. When WantStackWindow is set to 1, and your program is running, you will not receive this error. By setting WantStackWindow to 0, it doesn't check to see if A6 is valid; therefore, you will not receive the error message.
Last reviewed: 6/14/93
Why is using SADE 1.0 to step through an MPW Tool so slow?
___
When MPW launches a Tool, it acts much like Finder launching an application.The MPW shell now becomes the operating system for the Tool. But unlike Finder, MPW has no hooks for a debugger like SADE. Because of this, SADE requires a huge amount of overhead for each step operation it performs. For each step operation, SADE must:
1. Save its low memory space so that MPW's and the Tool's may be swapped in;
2. Restore MPW's as well as the Tool's low memory;
3. Perform the necessary debugging operation (step);
4. (Block)Move the newly updated low memory to an area accessible by SADE (so that SADE's low memory may be restored). Once SADE is restored, it will want to report on the new low memory state. This is why low memory had to be copied to an area accessible by SADE;
5. Swap SADE's low memory space back in so that SADE can operate.
Last reviewed: 6/14/93
Why is using SADE 1.0 to look at low memory so slow?
___
Since SADE needs to use low memory just like any other application, there is some overhead involved when using SADE to view low memory. Here is what SADE has to do to view the target application's low memory:
1. Save its low memory space so that target application's may be swapped in;
2. Restore the target's low memory;
3. (Block)Move the newly updated low memory to an area accessible by SADE (so that SADE's low memory may be restored). Once SADE is restored, it can report on the new low memory state. This is why low memory had to be copied to an area accessible by SADE;
4. Swap SADE's low-memory space back in so that SADE can now analyze the low memory it copied in step #3 above.
Last reviewed: 6/14/93
I'm having problems printing a CString from memory from SADE. For example,
printf ("<<%s>>\n",^CString($B64A12)^)does not print the string stored at $B64A12. What do I need to do?
___
The problem you encountered with getting SADE to cast a value to CString within a printf involves a type conflict between MacApp's declaration of a type named "CString" and SADE's built-in type named "CString". SADE will first match the type against declarations from the application, in a case sensitive manner. Only if it fails to match will it then match against its built-in types in a case insensitive manner. So, by casting to CSTRING instead of CString you will get the result you desired.
Last reviewed: 6/14/93
The following SADE code gives me an "### Invalid expression operand type" on line 05, unless I include line 03. Could you tell me why?
01 define aTemp, bTemp, cTemp, dTemp, eTemp, fTemp, gTemp; 02 aTemp := ^short(fExpandingView^)^ # Get Class ID 03 aTemp := aTemp * 1 # Multiple by sizeof(short) NOT USED 04 bTemp := ^short(pClassTable) # Get pClassTable address 05 cTemp := aTemp + bTemp # Calculate ptr to class's jump table offset___
The reason line 03 makes it work is that the constant one is treated as a 4-byte value. Multiplying aTemp by 1 and assigning back to aTemp therefore results in aTemp being converted to a 4-byte value. bTemp being a pointer type, SADE requires a 4-byte value as the value to be added to it.