On Tue, Dec 11, 2001 at 10:39:25AM +1100, Michael Glickman wrote:
> Let me specify it more clearly.
>
> You wouldn't argue that compiler's job is producing a code,
> while linker's job is binding the objects into a binary,
> producing a multisegment application if necessary. Let each
> one do its own job with the minimum possible interference !
I hate to imagine what happens when you try to specify things less clearly.
> By analyzing the current multisegment design, I can't get rid
> of a feeling that everything there is upside down. You specify
> sections at compilation stage, while logically it should be
> done not before linking ! The linker provides a very flexible
> engine for placing either the whole file, or only text section,
> or only specified functions into a segment.
I disagree with your "logic". A C compiler's job is translating C
source code into object code. A linker's job is binding the objects
from several translation units into a single object. Doing special
things that are beyond the scope of the relevant language standards,
such as using multiple code sections, is the responsibility of the
translation system as a whole, and may require cooperation between the
compiler and the linker. For example, your assertion that the linker
can place specified functions into a section by itself is false: it
requires cooperation from the compiler, namely -ffunction-sections or
section attributes on functions.
> Can we use for Palm
> applications ? Yes,
No! RT*F*M.
> but not as far as multigen is concerned.
> Using multigen makes all nice ld design useless!
Multigen just creates a linker script. It is not magic. It does not
make these ld facilities unusable. You are not forced to use multigen.
But as it happens these ld facilities are currently not usable on
Palm OS for other reasons. Clearly you still have not read the existing
documentation to which I keep pointing you.
> Is there a way to satisfy the second party ?
Since the second party cares so much about this, the usual approach is
for him to satisfy himself. I await your patches with interest!
However, I would suggest that your energies might be better spent
admitting that function annotations are currently necessary, and, since
you think this is onerous, making it less so. I've always suggested to
people who think annotating functions is laborious that they write some
scripts to parse function declarations/definitions in their source code
(or maybe you could use debugger symbols?!) and use the preprocessor
intelligently. Dave's posting shows how easy this is.
It gets even easier if you realise that (in C, at least) a function can
have several declarations and prototypes and you can put a section
attribute on an ordinary declaration. Thus you could have code like this:
/* Generated by script, in a central generated header file,
probably encased in more exciting macros, possibly #included
via -include. */
int foo () __attribute__ ((section ("foosect")));
/* Normal header file. (Hand written) */
int foo (int a, int b, int c);
Thus your declaration generating script need only understand function
names and return types. This might or might not be a good idea, but it
might make the mush in the source code even less intrusive than Dave's.
If you wanted to contribute positively rather than just whine, you might
like to write a flexible tool like this and documentation it well.
> You use __attribute__ ((longcall)) + alias:
>
> void Foo(UInt32 par);
> void StubFoo(UInt32 par) alias("Foo") __attribute((longcall);
>
> This decalres a function Foo and its long call alias StubFoo,
> used whenever the 'real' Foo is far away. When StubFoo is used
> for calling, you generate a long call for Foo, that's it!
You might want to look at Doug Anderson's FAR_CALL work (available in
Handspring's headers), which implements something similar, but using
function attributes that actually exist in m68k GCC.
> From the user's prospective it looks really straightforward:
> if you get "relocation truncated to fit" message, you create
> a long call alias, and use it where it was a problem.
You call this straightforward; I call it fragile and annoying -- I don't
want to explain to newbies why, when they added some code in foo() over
here, suddenly they have to change the way they call bar() in six places
over there. But YMMV.
John "likely will neglect this thread next time"
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
