avr-gcc-list
[Top][All Lists]
Advanced

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

Re: [avr-gcc-list] Re: Patch Fix PR35013, PR27192


From: Wouter van Gulik
Subject: Re: [avr-gcc-list] Re: Patch Fix PR35013, PR27192
Date: Wed, 16 Apr 2008 16:52:58 +0200
User-agent: Thunderbird 2.0.0.12 (Windows/20080213)

Andy H schreef:
RFC

A problem has come up trying to  fix  function pointer arthmetic bugs.


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27192


I created patch to solve this, but Anatoly has found a problem.

Without patch we had &func returning word address and (&func + 2) returning byte address. This occurred because AVR backend did not recognise (func+2) as program memory and did not use linker directive gs(func+2).

With patch we get &func and &func+2 both returning word address. Which solved the bugs reported.

Now if such a word pointer undergoes further arithmetic in c, then it will, of course, be adjusting it by words.

The problem that Anatoly discovered is that optimization can break this. His example involved volatile pointers but it will happen on more realistic cases. For example if we create pointers to Foo, Foo+2, Foo+4, optimization will try and use one pointer to create values of other pointers. So we will get word address of Foo offset by words - or word address of Foo offset by bytes! This just depends if the offset calculation is done in gcc or the linker. Aghhhh!


Just for my understanding. The programpointer calculation is thus translated to datapointer calculation?

There probably is no way of telling GCC we are dealing with different pointer types here? Since GCC can not handle different memory types at all.

To fix is not simple. The following are ideas only - please add some more

1) One way to to get linker to perform maths on gs() using word offsets. gs(foo+2) would be word address of foo+ 2 words. Then it would not matter if gcc or linker performed maths. I do not know if this is possible or what problems this might create.

2) We could avoid using gs() and get function address as byte address + byte offset. This would require extra run-time code for function pointer calls (to divide by two). It is useful in that same pointers could be used to read bytes from program memory.

3) Give up and dont permit any arithmetic. (Perhaps error or warning would still be needed)

4) Like (1) but use new directive gsw() to permit this method?

5) Like (2) but use attribute to permit this method?

6) Get gcc to recognize constant pointer maths and exclude it from linker gs()

7) Get gcc to recognize constant pointer maths and pass to linker as gs(Foo) + n instead of gs(Foo+n) - if this is possible.


Please add to discussion.



So they main point is to keep the knowledge that the add is in words not bytes. Right? Is it not possible to do all programspace addition on byte level, until the linker? Which converts them to words? e.g. foo+2 becomes foo+linker_know_this_is_2_words.

Wouter




reply via email to

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