[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Robert von Knobloch
Subject: Re: [Fwd: Re: [avr-gcc-list] Allocating variables to a fixed address]
Date: Tue, 12 May 2009 16:11:42 +0200
User-agent: Thunderbird (X11/20060911)

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.

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,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]