Re: [avr-gcc-list] Allocating variables to a fixed address

[Robert von Knobloch]

Erik Christiansen wrote:
>> I confess that GCC seems to me to be mostly something to fight with,
>> perhaps I have been spoiled in the past using manufacturer's C compliers
>> that were tailored especially for the target.
>>     
>
> It just requires leisure time for study and experimentation. ;-)
>
>   
>> I simply require a way to fix absolutely this jump table in memory.
>> Whether I write it in C or assembler seems to me to be irrelevant, as is
>> using an array of pointer to functions, because I still have the problem
>> of fixing these at absolute addresses.
>>
>> If anyone knows a way to do this, I would very much appreciate it.
>>     
>
> Robert, if the table is made __attribute__ ((section(".table"))) , and
> section .table is linked in after the vectors, but prior to any code, then
> its location will be fixed, won't it? In the old linker script I have to
> hand, that places it here:-.
>                            |
>   .text :                  |
>   {                        |
>      __code_start = . ;    |
>     *(.vectors)           /
>     *(.table)       <----'
>      __ctors_start = . ;
>      *(.ctors)
>
> Having shipped firmware to similarly skill constrained recipients, I saw
> from the OP why you're doing it this way. Nor would I hesitate to do the
> same, as need (or convenience) arises. After all, how much does it
> differ from the fixed addresses of BIOS calls in CP/M, or its imitator,
> MS-DOS?
>
> The method seems particularly attractive where the operators would load
> combinations of modules, perhaps with multiples of some, without the
> need for you to build every combination. (Most painful where there could
> be hundreds of them.)
>
> mfG,
>
> Erik
>
> P.S. If this post doesn't appear on the list, would you mind forwarding
>      it? For the last half year, none of my posts have gone through,
>      AFAIR.
>   
Aha !
Yes Erik, this is exactly the way I think. In fact it's slightly more
complex because I use the same download mechanism to load images that
will be flashed into target products with embedded AVR processors. These
are, of course, not native code for my host programmer.
It is from this necessity that I devised the original method and
extended it to the test routines.
I am not exactly a young programmer and grew up with many operating
systems and machines (Intel ISIS - Motorola Exorset, OS9 etc.). All of
the used a similar approach as does indeed BIOS (to call MSDOS an
imitator of CP/M insults CP/M IMHO but still..)
My solution (non-working till now) is, in principle, the same as your
suggestion except I chose a section originating at 0xff00 (after all the
.text sections) which may not work well with GCC - it randomises the
order of my 'vector table'. (Old experience with Motorola processors
makes one tend toward the high address end, of course the AVR
architecture is different here). Would you know why this won't happen if
I relocate the table as you suggest - just because it would then be
before any real code ?
I have had another promising suggestion (off-list) that makes the main
code write the addresses of its public functions to the eeprom, where
the loadable code could find them and use as function pointers.
I will try both and see how far I get.
Have included your posting in my answer so that it gets on the list.

Many thanks,

Robert