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: hutchinsonandy
Subject: Re: [avr-gcc-list] Re: Patch Fix PR35013, PR27192
Date: Wed, 16 Apr 2008 13:59:34 -0400

The solution is to have linker and gcc do the same maths. Or gcc only do the maths. So we do not mix. Then it will be predictable.

But this also depends if we can manage ok with just words OR just bytes - as may be avaialble as a solution.



Andy



-----Original Message-----
From: Wouter van Gulik <address@hidden>
To: Andy H <address@hidden>
Cc: AVR-GCC <address@hidden>
Sent: Wed, 16 Apr 2008 10:52 am
Subject: Re: [avr-gcc-list] Re: Patch Fix PR35013, PR27192


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]