Hello
Yesterday I spent an hour with "multiapp" in attempt to understand what
makes John Marshal so certain that you can't postpone section definitions to
the linkage stage.
Sorry John for some naive assertions, you are really right ... to a certain
extent.
Well, I take the liberty to tell all subscribers how I understand the
problem.
Sorry, CW users: just delete this email, if you are annoyed.
By default, the compiler uses three sections: "text" for code, "data" for
... and bss for stack (?). However some implementations of GCC compiler
accept -ffile-sections parameter that allows using custom section names. As
to m68k-palmos-gcc -ffile-section appears to be enabled by default, so you
can aspecify a custom section using __attribute__(section("...")).
The ld script generated by multigen uses the following template:
MEMORY
{
SECT1res : ORIGIN = 0x0, LENGTH = 32768
SECT2res : ORIGIN = 0x0, LENGTH = 32768
SECT3res : ORIGIN = 0x0, LENGTH = 32768
}
SECTIONS
{
SECT1 : { *(homer) } > SECT1res
SECT2 : { *(bart) } > SECT2res
SECT3 : { *(lisa) } > SECT3res
}
In this example input section "homer" is mapped to output section
"SECT1" which in turn mapped to memory section "SECT1res", others
are similar.
So far, so good. Later I might see, that sections "bart" and "lisa"
are small enough to fit into a single memory section. In this case
a normal logic suggests that I simply change the script in
the following way:
MEMORY
{
SECT1res : ORIGIN = 0x0, LENGTH = 32768
SECT2res : ORIGIN = 0x0, LENGTH = 32768
}
SECTIONS
{
SECT1 : { *(homer) } > SECT1res
SECT2 : { *(bart) *(lisa) } > SECT2res
}
Is this accepted by the linker ? Yes.
Is this accepted by build-prc ? No!
Have a look at how build-prc works.
As it was mentioned in one of previous threads, a resource can't
be longer than something near 64K. This in particular applies
to a code resource. The build-prc will help us to build a prc file
containing several separate code resources each having no more than
64k (actually, all resources are no more than 32K long, but this is
a different topic). Will it really help us ? Let's see how it works.
You get a module definition file which look as the following:
application {"myapp", my00}
multiple code {"homer" "bart" "lisa" }
One question is obvious:
"Why section have to be listed in def - can't we just get them from coff ?"
We should be able to, it might be a problem with the order - leave it for
now.
The more important is another question:
"Why to use input section name - can't we use the output sections instead or
in addition ?"
This is what really crucial, because it opens the door to any alternative
solution!
I don't like anotation each function, therefore I don't use __attribute__
(section).
I simply have three object files: homer.o, bart.o, lisa.o
My ld script looks as the following:
MEMORY
{
SECT1res : ORIGIN = 0x0, LENGTH = 32768
SECT2res : ORIGIN = 0x0, LENGTH = 32768
}
SECTIONS
{
SECT1 : { homer.o(.text) stub1.o } > SECT1res
SECT2 : { bart.o(.text) lisa.o(.text) stub2.o } > SECT2res
}
Where stub1.o and stub2.o contain "manually" written assembler stubs
for long calls .
I can have in def file something like:
application {"myapp", my00}
multiple code {"SECT1res" "SECT2res" }
Th build-prc will try to find an input section SECT1res.
Since it doesn't find it, it will attempt to look for
output section SECT1res - and it will succeed, and it will work!
Well, I still believe that it can be completely
automated, but currently I will be happy with
manual stubs: just open the door please!
It should be really a simple fix, for a one who knows
build-prc code.
Anticipating reply. Michael.
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
