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

[Robert von Knobloch]

Erik Christiansen wrote:
> On Tue, May 12, 2009 at 02:26:38PM +0200, Jan Waclawek wrote:
>   
>> On the other hand, a compiler is free to do whatever it wants to do
>> with statements you pass to it: it can reorder and insert voids
>> wherever and whenever it wants. This is the very principle of high
>> level languages: you give up part of control in exchange of increase
>> in convenience. If you want to re-gain control for whatever reason,
>> the best thing to do is to revert to assembler.
>>     
>
> While I would, based on experience with gcc on various targets, have
> expected multiple functions from one compile unit to end up in .text in
> the same order as they appear in the source code, we can enforce the
> order if that doesn't happen. Just put each of the ten functions (there
> were 0x0a of them, IIRC) in a separate section, e.g. mit_gewalt_0 to
> mit_gewalt_9, using __attribute__ ((section(".xxx"))) . Then in the
> linker script:
>
>                               /* Ok, it is the table which was to be */
>    .mit_gewalt_0 0xff00 :     /* at 0xff00? Use another address to   */
>    { .mit_gewalt_0 } > text   /* fix the location of the functions?  */
>
>    .mit_gewalt_1 : AT ( ADDR(.mit_gewalt_0) + SIZEOF(.mit_gewalt_0) )
>    { .mit_gewalt_1 } > text
>
>    .mit_gewalt_2 : AT ( ADDR(.mit_gewalt_1) + SIZEOF(.mit_gewalt_1) )
>    { .mit_gewalt_2 } > text
>    etc.
>
> One caveat: It's a while since I did such things regularly, so there
> might be a "typo|thinko" in there, given the hour and the fact I'm not
> allowed coffee.
>
> The gnu tools are flexible enough to do most thing several ways, either
> in C or assembler, or (often conveniently) with a mix.
>
> In a post which I don't yet see on the list, Robert wrote:
>
>   
>> 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'.
>>     
>
> But if that is just an array of function pointers, then it's the
> programmer who initialises it, isn't it? Then the order of entries is
> fixed in code, and only the pointer values may be randomised if care is
> not taken to prevent the possibility.
>
> mfG,
> Erik
>
> P.S. Aaaah, when I cut my teeth on the Siemens grey version of the Intel
> ISIS "blue box", you could count the macros being assembled,
> by the one long and four short head seeks on the 8.5" floppy drives,
> taking several seconds. There was more than time enough for too much
> coffee back then. :-)
>
> P.P.S. Looks like this needs to be forwarded to the list too.
>        (Perhaps the dynamic IP range that I'm in is blocked?)
>   
Hi Erik,

it seems that your block has been lifted.

I had the ISIS box (8008 I think) plus the drives (they were 7",
following the sizes of music records at first).
The head seeks were often drowned by the teleprinter I had as hard copy
device, but yes, you got used to the rhythms and knew when an assembly
was finishing.
</nostalgia>

Thinking about your answer, yes an array of pointers (and nothing else
in the section) could be a good answer. GCC can't randomise the subscripts.
I had simply written a sequence of stub functions, but their written
order is not the order they appear in in code.
I like your 'mit Gewalt' solution, it could also work - just need to be
careful not to waste too much space - i.e. know the sizes of the functions.

Many thanks,

Robert