Apr 00 Factory Floor
Volume Number: 16 (2000)
Issue Number: 4
Column Tag: From the Factory Floor
Metrowerks Top Ten
by Richard Atwell
A monthly column of assorted news, interviews, and technical information from Metrowerks
It's been quite a while since we presented a top ten list of support questions so this month we'll do just that. URL addresses to useful resources mentioned in the answers are located at the end of article.
Q) I am having trouble with the CodeWarrior CD installer. It partially completes then stops citing a bad disk error. What can I do?
A) Check for these common disturbances and try running the installer again:
- the CD is dirty or scratched
- the correct driver for the CD-ROM drive is missing
- disruptive third-party extensions are installed such as virus scanning software and/or Norton CrashGuard
Q) Can I use CodeWarrior to port MFC applications to Mac OS?
A) Microsoft's Foundation Classes, or MFC, is a Microsoft Windows specific application framework. CodeWarrior Professional ships with PowerPlant, our world-class application framework for Mac OS. PowerPlant is similar to MFC except there isn't a simple way to port MFC-based code to Mac OS using PowerPlant. This is due to differences between the underlying APIs that both operating systems provide.
Q) The CodeWarrior Release 5.3 Update supports AltiVec but your documentation doesn't have any detailed information on how to program AltiVec. Where can I find such information?
A) Apple's Web site has technical information for developers that describes how to utilize AltiVec instructions to enhance your programs. The CodeWarrior documentation describes the debugging features within the IDE, the compiler support for AltiVec code generation and runtime library support only.
Q) I've written a simple C++ project but somewhere along the way I added some code and now I'm getting compiler errors like this:
Link Error : Undefined symbol:
(class std::locale::id std::num_put<char, class std::ostreambuf_iterator<char,
struct std::char_traits<char>>>::id) in hello.cpp
A) The problem is likely caused by having the C/C++ language setting "ARM Conformance" set to on. The MSL C++ library is built with the settings below. If your target differs in setting you may get errors at any stage of development.
ARM Conformance off
Enable C++ Exceptions on
Enable bool Support on
Enable wchar_t Support on
Map newlines to CR off
Enums Always Int off
Use Unsigned Chars off
Q) When I try to debug my Java application on Mac OS, I receive the following message:
"Error setting up JDWP server socket"
A) Ensure your setup is correct:
- Make sure that you have Apple's MRJ installed on your Mac.
- Check your CodeWarrior installation and make sure that the RunJava application was installed and is located in the (Helper Apps) folder.
- Check that you have TCP/IP enabled and set up correctly for your machine.
Starting with CodeWarrior Release 5, the Java debugger requires that you have TCP/IP services installed on your Mac. For information on creating this configuration read the release notes in the following location:
CodeWarrior Pro 5:
CWPro Release Notes:
IMPORTANT (Mac Java Debug).txt
If you have TCP/IP set up correctly, and you have the CodeWarrior Release 5.3 Update installed, try increasing the timeout value in the global Java Debugging preference panel to 30 or 60 seconds and see if this allows the debugger to launch correctly.
Q) CodeWarrior Release 5 included Apple's Universal Interfaces 3.2. How do I install a newer release like Universal Interfaces 3.3?
A) Starting with CodeWarrior Release 5, the Mac OS Support folder was re-organized in order to simplify the procedure for upgrading essential headers and libraries from Apple. Previous versions required you to hunt down the duplicate files and remove them, but now all you need to do is replace the contents of this folder:
Metrowerks CodeWarrior:MacOS Support:Universal
If you want to leave the 3.2 files in place you can add the new 3.3 files to a (shielded) folder. Then, explicitly add an access path to that folder so projects that require the older files and have an implicit access path to MacOS Support will not accidentally pick up the newer files. You may want to exchange the contents of the shielded folder with the existing Universal folder if you plan to move your projects to the newer headers and libraries.
Q) When my application is halted by the integrated debugger for the very first time, xSYM files for all loaded shared libraries are opened. Since our application has many shared libraries, opening a large number of xSYM files can slow down the debugger startup. How can I stop this from happening?
A) Turn off the "Auto Target Libraries" option in the Global debugger settings. Alternatively, you can turn off the "Auto-target Libraries" option in the debugger target settings of the project that you are debugging.
To debug a specific shared library, simply open the project for it and set a breakpoint. This can also be done by opening the library's xSYM file and setting a breakpoint from there. Doing so will stop the debugger from loading symbolics for all the shared libraries that your application loads when you start debugging.
Q) I can export a project as XML through AppleScript, but how do I create a project from an XML file through AppleScript?
A) The correct statement is:
Make new project document as "HD:Test:Test.mcp" with data "HD:Test:Test.mcp.xml"
There is a paragraph in the release notes that describes the syntax for exporting projects. Currently you must say "make new project document" instead of "make project document" or else this command won't work, even though the AppleScript documentation says that the "new" can optionally follow the "make" command.
Q) How do I setup the Mac-hosted cross-debugger to debug my Win32 apps built with Mac-hosted x86 tools?
A) To use the Mac-hosted x86 cross debugger, you'll need the following:
- A Mac and a Windows machine networked together using the TCP/IP protocol
- The CodeWarrior remote debugger nub, MWRemote.exe from the Pro 5 Mac Tools CD
Metrowerks CodeWarrior:Win32-x86 Support:MWRemote.exe
1) Copy MWRemote.exe to any folder on the Windows machine.
Preferably, you should use an empty folder since the .EXEs or .DLLs you debug will be copied to this location during debugging and may overwrite any existing files with the same names.
2) Enter the Windows machine's TCP/IP address in the x86 Debugger preferences panel within the Mac hosted IDE.
From the Edit menu, select Preferences and then select x86 Debugger panel. Enable remote debugging by checking the Remote Debugging checkbox. Then, edit the Remote IP Address field and enter the remote machine's TCP/IP address. Leave the port number in the second field to the default value of 6969. Close the preferences dialog to save the new settings.
3) Run MWRemote.exe on the Windows host.
Make sure that "TCP/IP" is selected in the Connection combo-box. Note that you can also enter an alternative port number here, otherwise leave it as the default setting of 6969. If you minimize this dialog you'll notice the nub's icon in the Windows task bar, indicating that it's running.
4) Select Debug from the Project menu.
The debugger should launch, automatically copying the target output over to the remote machine. If the application launched, you will stop at the default entry point (i.e., main() or WinMain() for applications, DLLMain() for DLLs).
If your application uses DLLs, they must be manually copied to the remote machine. The debugger will not automatically copy DLLs over.
At the present time, it's not possible to debug Win32 DLLs using CodeView for the symbolics format since it's not possible to open the DLLs CodeView file in the Mac-hosted debugger. A workaround is to select the SYM symbolics option through the x86 linker panel for all your targets (any debug libs will also have to be rebuilt using SYM). Then, you can browse the symbolics of any of your DLLs by opening the .iSYM file generated by the linker.
Q) I want to allocate memory for many large objects in my program. To avoid heap fragmentation I have called _prealloc_newpool at the start of the main() function in several projects for many years now. With the CodeWarrior 5.3 Update (with or without patches) the linker complains that it can no longer can find this function and displays the following error:
Link Error : undefined 'std::_prealloc_newpool(unsigned long)' (code)
A) Metrowerks was not satisfied with the performance of our previous memory allocators so for CodeWarrior Release 5 we rewrote the malloc/free functions in our MSL C library. This resulted in large performance gains.
For Mac OS targets, operator new has always had several implementation options. In the file New.cp (Mac OS Support:Libraries:Runtime:Common Sources:), these options are implemented as conditionals:
#define NEWMODE_NONE 0 // do not define operator new/delete
#define NEWMODE_SIMPLE 1 // call NewPtr/DisposPtr
#define NEWMODE_MALLOC 2 // use malloc/free
#define NEWMODE_NORMAL 3 // regular new/delete
#define NEWMODE_FAST 4 // regular new/delete fast version
With CodeWarrior Release 4, we shipped with NEWMODE_FAST on by default, which is an allocation algorithm implemented right in New.cp, separate from the malloc/free routines of the MSL C library. This algorithm supported the method mentioned in the linker error along with NEWMODE_NORMAL.
char _prealloc_newpool(size_t size);
With the malloc/free rewrite, we switched the default implementation of new to NEWMODE_MALLOC (which has no corresponding _prealloc_newpool). NEWMODE_FAST is still there but you need to edit New.cp and rebuild your runtime libraries.
The CodeWarrior Release 5 malloc is a sophisticated and robust algorithm in terms of both CPU performance and memory usage. It avoids memory fragmentation two ways:
1. Tiny allocations are lumped together and taken from fixed sized pools. This greatly increases the speed of allocation/deallocation of small blocks and completely eliminates the unused blocks between allocated blocks.
2. Larger allocations come from traditional variably sized pools. As these larger allocations are freed, adjacent free blocks are merged into larger free blocks.
Thanks to James Lee and everyone in Metrowerks' Tech-Support group who contributed to this article.
We always welcome your feedback on any subject. Contact us through our newsgroup or send us email directly using the addresses below.
Technical Support: email@example.com
Report Bugs: firstname.lastname@example.org
AltiVec programming tutorials
Apple's Universal Interfaces
Richard Alexander David Atwell lives and works in Austin, Texas, where the Metrowerks headquarters are located. Richard attended the University of Victoria, British Columbia, Canada and graduated with a B.Sc. in Computer Science just prior to joining Metrowerks. You can reach him at email@example.com.