We currently use one of the typical "zero run-time overhead" implementations of these features, but that implementation does have a cost in storage overhead. The extra code space used is mainly due to exception handling library routines which are pulled in during linking if you use exceptions. The global data overhead is due to various data tables generated for both exceptions and RTTI.
Especially if you are using C++ "as a better C", you may not be using these
features anyway. You can avoid the storage overhead by compiling your code
with
-fno-exceptions -fno-rtti.
You also need to ensure that any C++ libraries with which you link were
also compiled with these options. In practice, the usual culprits are the
new and delete operators, which, in their standard
versions, use exceptions to indicate memory exhaustion. You can solve this
by overriding operator new et al with non-throwing versions
(although of course you will then be using non-Standard C++). You can do
this yourself, or you can use libnoexcept.a, which is provided
by prc-tools for this purpose, by linking your code with
-lnoexcept.
(The array versions of operator new[] were omitted from
libnoexcept.a in prc-tools versions prior to 2.1. If you use
these operators and the library, you should upgrade to the current version.)
(If you are wanting to use exceptions, you should note that actually throwing an exception is probably currently broken anyway, due to a bug in prc-tools.)
foo.c and then link
with a command like
m68k-palmos-gcc -lPalmOSGlue foo.o bar.o
-lPalmOSGlue appears because
foo.o has not yet been examined, so nothing gets pulled in
from the library.
Unless you have a reason for doing otherwise, libraries should be specified at the end of a link command line:
m68k-palmos-gcc foo.o bar.o -lPalmOSGlue
echo foo | m68k-palmos-gcc -dM -E -
__palmos__.
You can also find this out by invoking the compiler with the -v
option. In addition, this will tell you that the following
assertions
are predefined:
-Asystem(palmos) -Acpu(m68k) -Amachine(pilot)
But assertions are less portable and not so widely known, and so probably less interesting.
sdksymbolic link affect the default SDK anymore?
-palmosN option) was controlled by
a symbolic link in the PalmDev directory:
$ cd /opt/palmdev or cd /PalmDev $ ls -l lrwxrwxrwx 1 root root 5 May 25 16:43 sdk -> sdk-4 drwxr-xr-x 4 root root 4096 Feb 21 14:50 sdk-3.5 drwxr-xr-x 4 root root 4096 Feb 21 12:50 sdk-4
From prc-tools 2.1 onwards, anything -- symlink, directory, or otherwise --
named sdk in the PalmDev directory is ignored.
Instead, you should use
palmdev-prep's -d or
--default option to change the default SDK.
gdb myapp, where myapp is the Palm OS
executable file you gave to build-prc, all you'll get is
$ gdb myapp
"myapp": not in executable format: File format not recognized
(gdb) target palmos
Undefined target command: "palmos". Try "help target".
gdb command is a native debugger,
for use on programs running locally on your host machine and operating system.
It has no Palm OS-specific functionality, and in particular it doesn't know
how to connect to a remote Palm OS device.
The command you want to use instead is m68k-palmos-gdb, which
is GDB configured for Palm OS and with all the needed knowledge of Palm OS:
$ m68k-palmos-gdb myapp
(gdb) target palmos
Remote debugging under PalmOS using localhost:2000