John,
Thanks for your lengthy reply.
> [Remember (everybody :-)) that changing subject lines -- even just
> something as apparently innocuous as adding "SUCCESS" -- breaks the
> thread tracking in the (substandard) archives and causes the record
> of your success to be lost to future generations. Please don't!]
I apologize. This is common practice on other lists I'm familiar with.
<snip - discussion of segment annotations on prototypes and function
definitions>
> So I really don't see what annotating the definitions is buying you.
> Please elucidate these "different things" that you are trying!
By "different things", I meant playing around with the build. Experimenting
to try and understand the multisegmenting method itself. This is my first
Palm app, and I'm still working through a lot of the technical issues. By
annotating the prototypes with a separate macro than the definitions I can
turn one or the other off while I investigate why my app isn't building the
way I want. Also, I was wondering about the question you bring up here.
What DOES annotating the definition buy me? Anything? As I indicated in my
report, at this point it seems like it IS having an affect. Some data ends
up in the .text segment when the annotations are not on the function
definitions (in my code -- which may still have problems).
This placing and removing of the segment annotations certainly isn't any
kind of feature that I'll need once my build process gets more mature.
> If a function is just a local utility function within some translation
> unit and all calls to it are from that same .c file after the
> definition of that function (so the prototype implied by the function
> definition is visible from all the call sites), then probably that
> function is file static and there are no other prototypes of it
> anywhere (because the prototype in the function definition is
> sufficient for full type checking). This is the only situation I can
> think of in which I think it would be appropriate for a section
> attribute to appear in a function definition.
I'm working on a port of a code base which is still being maintained.
Unfortunately for my efforts, the other programmers on the project either
condone or have inherited a style of programming that limits prototypes to
functions that are being called outside of the compilation unit.
Personally, I prefer putting all prototypes into header files and including
them as appropriate.
So the situation you describe above is prevalent in this code base. There
are many places where functions that are local to a given compilation unit
are not prototyped.
>> I have found that if I put the segment names only on the prototypes
>> (and define my macros on the actual function definitions to be
>> blank), then the main .text segment gets larger than if I have the
>> segment names at the function definitions.
>
> If I had to guess, I would say that the definition is not seeing the
> annotated prototype (and that the function is static or it has another
> prototype somewhere [1], so that -Wmissing-declarations is not
> triggered) and that the entire function is going into the .text
> section. This of course will cause a crash when a call that can see
> the annotated prototype is executed.
>
> But it's just a guess.
I think I can confidently say that there are no unexpected functions landing
in the .text segment. When I look over the link map that gets produced on
my build without the annotations on the function definitions, I see entries
for a couple of .o files that aren't there in my other build, but no
functions appear. This leads me to believe that the extra space has to do
with data that is either static to that file's scope or data that is static
within some of the functions in that .o file that have been placed in
another code segment.
>> When I put the segment names on the prototypes AND on the function
>> definitions, it frees up more space in the .text segment. I'm
>> guessing that is a good thing. Anyone care to comment on the types
>> of things that get placed within the annotated segment when the
>> function definition has the segment naming as well as the prototype?
>
> Rather than asking us to guess, it'd probably be more productive if
> you looked at your output to see exactly what moves between sections,
> and came back to us with the results and we'll help you interpret
> them. Just diff the two versions.
OK. Here's part of the link map (produced by -Xlinker -M) that is different
between the two versions of my build (one with annotations on the function
definitions and one without -- both have annotations on the prototypes).
This is from the one without the annotations on the function definitions:
.text 0x0000012c 0x4de object.o
*fill* 0x0000060a 0x2
.text 0x0000060c 0x638 process.o
.text 0x00000c44 0x5fa screen.o
*fill* 0x0000123e 0x2
.text 0x00001240 0x344 err.o
.text 0x00001584 0xbb6 text.o
*fill* 0x0000213a 0x2
.text 0x0000213c 0x158 quetzal.o
.text 0x00002294 0x422c pm_frotz.o
0x000031d6 CloseDatabases
0x00004f10 SetVerbLists
0x00002e3e WritePreferences
0x00003bde SetGlobalButtonBarItems
The files object.o, screen.o, text.o, and quetzal.o do not appear in the
other link map. But you can see that this link map shows no functions under
those files. That only leaves some kind of persistent data, right?
FWIW, err.o and process.o appear in both maps. process.o has a smaller size
in the other build, but err.o has the same size in both. err.c contains a
couple of static file-scoped static arrays. process.c defines a couple
static file-scoped arrays along with a couple of arrays that are global.
They get referred to in other compilation units via an extern.
OTOH, object.c has no file scoped or function local static data at all. It
does refer to global data declared in other places, however. It also
declares several of its functions to be static, and now that I'm looking at
it more closely I can see that it has several utility type functions (only
called from this file) that lack prototypes. As an experiment I'll
prototype those and see if it makes a difference.
<time passes...>
Declaring prototypes for all functions in object.c (even those that are
purely local) causes the reference to object.o to disappear from the .text
segment. So what do you think is getting moved to the other code segment
that was being placed in .text before? Certainly not any functions.
>> Is there some hidden danger in having some of this extra
>> data within the various segments instead of in the .text segment?
>
> Possibly, if you don't think about the code that handles your
> non-globals launch codes. See
>
>
http://prc-tools.sf.net/cgi-bin/info/multiple+code+resources+and+global+data
Thanks for the pointer. I'm aware of this documentation. When I get to the
point where I'm considering launch codes other than
sysAppLaunchCmdNormalLaunch, I'll be poring over this kind of information
carefully.
Thanks again for the help.
Rick Reynolds
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
