Re: [avr-chat] more of the same ;)

[Rolf Magnus]

On Tuesday 15 August 2006 10:15, Joerg Wunsch wrote:

> "Steve Franks" <address@hidden> wrote:
>>
>> Any hope of disabling my earlier warning?  I think we've nailed down the
>> reason, thanks to Joerg, so now I need to get it to go away until a fix
>> becomes aparrent.  Digging around in the gcc manual, I found -Wno-packed
>> -Wno-padded, but they do not appear to do the trick.  Am I out of luck?
>>
>> the suspect: alignment of 'VRmsAStream::_ZTV11VRmsAStream' is greater than
>> maximum object file alignment.  Using 1

I've found that now. It's a bug in the avr target of gcc. The fix is a simple 
one-liner. I guess I should to send this to someone to get it commited to the 
repository, though it's so small that it doesn't even deserve the 
name "patch" ;-)

The problem was: Each target can define a maximum alignment supported by its 
object  file format. The avr target defines this as 8 (bits). It can also
define an alignment for the vtable entries, which the avr target does not do. 
In this case, the alignment is set to the size of the native pointer type,
which is (just like the warning says) greater than the maximum object file
alignment. 
Btw: The warning is harmless, since g++ automatically reduces the vtable 
alignment to 8 bits (the warning prints it in bytes, hence "Using 1").

> Without digging deep into gcc/cpp/*, probably, yes.
>
> Oh, while you are at it, move the vtables out to ROM, please. :-)

I think that's trickier. I had a look into it, but still don't know how it 
could be done.  The problem is that the vtable is just stored 
like a global variable. So to make vtables in flash, two things would need to 
be done:

- make the compiler put the vtables into the .text secion
- make it able to correctly access variables from that section

The first part might be doable (I'm not sure if my idea would work). The 
second part seems tricky. I didn't yet find any way to tell gcc that there 
are separate types of memory that should be accessed with separate assembler 
instructions (lds vs. lpm). That would have the nice side effect that
pgm_read_* from the avr-libc would become pretty much obsolete I guess.  
Anyway, in the RTL, it seems that the attributes are gone, so I don't know 
how to propagate that information to that part. There are register classes 
that can define different types of registers, but no memory classes or 
something like that. I couldn't find any other target that would do that 
either.
The C and C++ front end are independant of the target, so everything must be 
done in the AVR target part (directory gcc/config/avr)