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

[hutchinsonandy]

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