On Thu, Sep 12, 2002 at 06:49:37PM +0800, Geoffrey wrote:
> I am still not really clear on multi-segment after I read all the reference
> on the web.
Thank you for following the advice at
http://www.tuxedo.org/~esr/faqs/smart-questions.html
and finding some specific issues that you don't understand. Unlike your
previous "I don't understand multiple code sections at all!" posting,
it's actually possible to help you with this one :-).
> I have 3 questions about that:
> 1)In the .def file, what things affect the name "mainform" and "editform" in
> "multiple code { mainform editform }"
Uh... I don't understand the question. It's the same as "what things
affect the names I give to my functions?". The answer is you name them
whatever you want within the relevant constraints, which in the case of
a section name in COFF means you are limited to eight characters (and
of course in prc-tools this sort of section name has to be composed only
of valid C identifier characters).
Generally the process is like this:
1. You realise that your application is of such a size that you need to
break it into three code resources. This means that you have to define
(and name) two new code sections and move some of your app's functions
from the main default unnamed code section to these new ones.
You might choose to call these sections something like "mainform" and
"editform" if the functions in them happened to be related to each
other in such a way, or you could just call them "sectionA" and
"sectionB" if you wanted. It doesn't matter to the tools.
2. You annotate some function declarations with the section names you
have chosen.
3. You list all the section names in a multiple code cause in your .def
file.
4. Later you realise that you need a fourth code resource; you annotate
some more functions and add the new section name to the list in the
.def file.
> 2) Where do I put this things? In the .c or .h or .def file?
> static void calltodo(void) __attribute__ ((section ("mainform")));
It should be clear from the documentation that such C code would be
irrelevant in a .def file.
As noted in the documentation, the important thing is that this annotated
declaration should be visible whenever calltodo is *called*, and also
when it is defined. In practice, this means that you should put it in a
header (.h) file. In particular, there is the following paragraph in the
documentation:
In practice, probably the best policy is to have exactly one
declaration for each function that needs one, in a header file
somewhere, and to use -Wimplicit (which is implied by -Wall),
and possibly also -Wmissing-declarations, to ensure that the
declaration is visible when it needs to be.
(And then one wonders why your example has "static" in it. In fact,
there are two cases:
1. You're putting a static function in a named code section. In this
case, of course all the calls to this function are from within this
particular .c file, so putting the section attribute on a (static)
declaration of the function at the top of the .c file is fine.
2. You're putting a non-static function in a named code section. In
this case, the function is probably called from several .c files,
it won't be "static", and the declaration with the section attribute
should be in a header file, as described.)
> 3) When I run the build-prc, it tell me:
> app_name:mainform: warning: spurious code section ignored
> How can I make it "not-spurious" ?
When build-prc says that a code section named "mainform" is _spurious_,
what it means is that the BFD executable "app_name" contained a code
section named "mainform" but "mainform" was not listed in the multiple
code clause in the .def file, so build-prc did not know what to do with
that code section.
(It is important that the list of section names given to
m68k-palmos-multigen matches that given to build-prc. This diagnostic
helps verify that.)
Either "mainform" is missing from the .def file, or, as is perhaps
more common, you forgot to pass your .def file to build-prc and it is
producing that diagnostic for *every* extra code section in "app_name".
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
