On Tuesday 15 August 2006 10:15, Joerg Wunsch wrote: > "Steve Franks" <[EMAIL PROTECTED]> 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) _______________________________________________ AVR-chat mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-chat
