Thanks to all who have replied to this enquiry. I must admit I'm somewhat
astonished that there is not a simple answer to this.
Nico Coesel and David Brown suggest linking the function in the data section.
Since in my application, the RAM occupancy of the flash reprogramming function
can approach 100% on the smaller processors, linking it permanently into the
RAM section, the cleanest solution, seems not to be an option. In fact, on
the tiny programmers, I even overwrite the stack and the heap with my
programming function, secure in the knowledge that it does not use them.
I am entirely in agreement with JMGross that a global symbol emitted by .size
is the perfect solution, provided that optimisation does not fool it. As a
matter of fact, I'm not sure that "optimisation" is always as good as it
should be. I've found instances where it produces a jump to a "RETI"
instruction, which is a waste of code space and run time. Merely replacing
the jump with a second "RETI" is clearly more efficient.
All in all, I think I'll stick with my somewhat kludgy use of a separate
section for the function to be moved. The optimiser does not jump to code
outside the section, and the linker reliably reports the memory address of
the end of the section.
extern int __foobar_start, __foobar_end; // Provided by linker
int size_of_programmer; // Computed at runtime
static void __attribute__ ((section (".foobar"))) __attribute__ ((naked)) \
programmer(void)
{
...
}
size_of_programmer = __foobar_end - __foobar_start;
Seems to work well, at the expense of maintaining a linker file with the
section "foobar" defined.
--
Rick Jenkins <[email protected]>
Hartman Technica http://www.hartmantech.com
Phone +1 (403) 230-1987
221 35 Avenue. N.E., Calgary, Alberta, Canada T2E 2K5
