I finally got my app building via the gcc multisegmented manner and it is
able to be debugged via Ton's changes to gdb. Thanks all!
I found something interesting that I wanted to post and get opinions about.
Here's part of my previous posts:
>>> int foo(int bar) SEGMENT1;
>>>
>>> ...
>>>
>>> int SEGMENT1 foo(int bar) {
>>> ...
>>> }
>>>
>>> I read on the Falch site that this was basically a no-no and that
>>> best practices indicate to only place the segment definition on the
>>> prototype.
>>
>> If the declaration is visible from the definition, then the second
>> annotation is redundant. Redundancy of course leads to inconsistency
>> and thence to bugs, which is why I would recommend against it.
>> That visibility can be checked with -Wmissing-declarations (although
>> I personally find that flavour a little restrictive), which is not
>> implied by -Wall.
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.
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. I assumed this has to do with static variables that
are local to the functions, but this pattern doesn't hold up in the examples
I'm looking at in my code.
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? I'm thinking that what I read at
falch.net isn't completely accurate here.
To be fair to Falch, here's what the article in their knowledge base
actually says (http://www.falch.net/Articles?art=179):
<falch>
For global functions the section tagging should only be used on the function
prototypes, not the declaration, and all functions that call these functions
must see these prototypes.
For instance, if function foo() in main.c wants to call function foobar() in
thelibrary.c, you must assure that foobar()'s prototype is visible to foo().
This is very important, since otherwise they have no way to distinguish
which segment the called function is in.
Visibility is important for the local function also, so if you want use the
shorthand syntax, you must be certain that the function does not have a
prototype, as a prototype might confuse functions that see the prototype
instead of the actual declaration.
</falch>
Currently I'm putting the segment tags on both the prototype and the
function definition and things seem to be working fine. Although I'll
freely admit that I haven't exercised much of my app at this point under
this new build. Is there some hidden danger in having some of this extra
data within the various segments instead of in the .text segment?
Another oddity: The -Wmissing-declarations flag on the compiler did not
find all of my missing prototypes! In my case I had three functions that
basically are providing malloc, free, and realloc style memory management
(I'm porting an existing code base to Palm). Those three functions are
wrapped with macros, but didn't have prototypes in my header files (an
oversight). -Wmissing-declarations did not find this problem. I'm thinking
that lint or some other tool may be necessary to insure that every single
function has a prototype everywhere it is referenced.
Rick Reynolds
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
