[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] eeprom_write_block inconsistent between WinAVR and Li
Re: [avr-libc-dev] eeprom_write_block inconsistent between WinAVR and Linux
Mon, 14 Jul 2008 10:49:57 +0200
the latest debian release of gcc and binutils are based on the
WinAVR-20080610 winavr patches. But the latest avr-libc release is
but winavr seems to be based on 1.6.3, and the only one patch for it,
30-avr-libc-1.6.3-dwarf2.patch, which does not fix this problem.
On Sun, Jul 13, 2008 at 1:39 PM, Preston Wilson <address@hidden> wrote:
> The order of the arguments were accidentally reversed in the first rev of
> the eeprom routines that were inline. Demitry Xmelkov fixed the problem
> quickly when the problem was pointed out. The doc and the WinAVR version
> are correct. Around that same time there were a couple of bugs introduced
> into the compiler that did cause wrong code generation, so even if you fix
> or work around the eeprom_write_block argument order issue, you might be
> dealing with other nasty issues.
> One answer is to build a current Linux tool chain based on the WinAVR
> Here is the bug and commit logs for the eeprom_write_block issue:
> bug #22828: eeprom_write_block(): incompatibility in args order
> The CVS commit logs
> "Dale Whitfield" wrote:
>> I've just been bitten by a nasty...
>> eeprom_write_block is defined differently in WinAVR and avr-libc, as
>> distributed under Linux.
>> Linux has:
>> static __inline__ void
>> eeprom_write_block (void *__dst, const void *__src, size_t __n)
>> __eewr_block (__dst, __src, __n, eeprom_write_byte);
>> WinAVR has:
>> static inline void __attribute__ ((always_inline))
>> eeprom_write_block (const void *pointer_ram,
>> void *pointer_eeprom,
>> size_t size);
>> Its obvious now, after days of debugging, that source and destination
>> are reversed. Thus making code developed on one incompatible with the
>> other. Its not so obvious when code suddenly misbehaves and is erratic
>> when compiled under Linux when it worked under WinAVR. I was looking for
>> compiler issues, mistakenly.
>> defines eeprom_write_block as per WinAVR above.
>> This isn't really a question of right or wrong, since the Linux version
>> follows the usual memcpy/strcpy/etc. It does make me wonder why things
>> diverged at some point since copyrights, etc in the two files are
>> Consistency between the two is important, I feel, but changing one or
>> the other is hugely fraught with compatibility issues.
>> Now that we have a usable compiler for Linux (Debian in my case), for
>> atmega256x, are there any other pitfalls anyone knows about?
>> AVR-libc-dev mailing list