Apr 00 Factory Floor
Volume Number: 16
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
Top Ten
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:
?id@?$num_put@DV?$ostreambuf_iterator@DU?$char_traits@D@std@@std@@@std
@@2V0locale@2@A (class std::locale::id std::num_put
std::ostreambuf_iterator>>::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:
Java 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
Setup Procedure:
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).
Notes:
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.
Credits
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: cw_support@metrowerks.com
Report Bugs: cw_bug@metrowerks.com
Suggestions: cw_suggestion@metrowerks.com
URLs
AltiVec programming tutorials
http://developer.apple.com/hardware/altivec/index.html
Apple's Universal InterfacesBR> http://developer.apple.com/sdk/
______________________________
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 ratwell@metrowerks.com.