[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!]

On Thu, Feb 20, 2003 at 07:18:33AM -0500, Rick Reynolds wrote:
> I still have my code annotated this way so that I can try different things.
> I'm actually using two different preprocessor macros -- one for the segment
> name on the prototype and one on the actual function definition.  I've
> rigged my build so that I can quickly turn off the segment names that appear
> at the function definitions -- you always need them on the prototypes for
> segmenting to work at all.

One more time, slowly :-).

If the prototype is not visible from the definition, that is bad style
regardless of section annotations.  If there is no section attribute on
the prototype but there is on the definition, that will break any call
sites from which the definition's prototype is not visible (e.g. those
in other translation units).  If the prototype is visible from the
definition and both have the same section attribute, then the attribute
on the definition isn't doing anything.  If the prototype is visible
from the definition and the two both have section attributes but the
two specify different sections, then that is broken and will likely
cause crashes.

So I really don't see what annotating the definitions is buying you.
Please elucidate these "different things" that you are trying!

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 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.

> 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.

I see from your later posting that you've discovered the linker maps
which can be produced with options like "-Wl,-Map,foo.map".  Also of
interest will be looking at assembly output with "-S".

> 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

    John

[1] That's why the prc-tools documentation suggests that having more
    than one declaration of some function is bad style.

-- 
For information on using the Palm Developer Forums, or to unsubscribe, please see 
http://www.palmos.com/dev/support/forums/

Reply via email to