Re: [avr-libc-dev] Erroneous definition of _MemoryBarrier() in cpufunc.h

[David Brown]

Hi,

I know some people find it convenient to get embedded development tools
such as the avr-gcc and avr-libc with the same "apt-get" or "packman"
commands as they use for everything else on their system.  And as a way
to get started or test out tools, it's not too bad.  But I strongly feel
that it is a bad idea for serious work - even if you have an
enthusiastic and dedicated package maintainer.

The reason for this is that changes in these toolsets are often
significant.  Embedded development is not like PC development, where if
the code is fine with one compiler, it is probably fine with another,
newer tools are usually better, and library details seldom matter.  If I
make a project with version x.y of the avr-gcc compiler tested with
version u.v of the library, then I stick to that ever after for that
project.  Version u.(v+1) of the library may have a subtle change that
affects the program.  Compiler x.(y + 1) may have changed the format for
interrupt function attributes.  Few things are less pleasant than taking
a project that used to work, making a quick fix, and finding you are
unable to build a working program again because of toolchain changes.

I usually get the latest versions of the toolchains before working on a
/new/ project, or a significant update - because the toolchains
regularly improve in features, efficiency, and usability.  But I want
the new toolchain alongside the old one, not replacing it, and I don't
want /any/ toolchain to be the "default" or have a special place.

This can all depend on the type of embedded development you do.  There
is a wide range from the "home project" type of development up to the
"archive the whole computer so you get bit-perfect builds in 20 years
time" projects.  Keeping multiple toolchains is a little more effort
than using the OS's default one, but it is not particularly hard.

Of course you should contact your package manager - either the distro's
package should be kept current, or it should be removed.  But for your
own use, you might want to consider if using the OS's package is the
best solution for you.

mvh.,

David


On 22/01/17 22:07, Ralf Ramsauer wrote:
> Thanks David.
> 
> I was about to write a patch, when I found out that this issue is
> already fixed on mainline [1], since 2013(!).  I'll have to contact
> package maintainers of my OS, to mark a more recent version as stable...
> 
> Cheers
>   Ralf
> 
> [1]
> https://github.com/vancegroup-mirrors/avr-libc/commit/6323351b344996a4a8c849ae5e2f6c2b10ae5cc0
> 
> 
> On 01/22/2017 10:28 AM, David Brown wrote:
>> Hi,
>>
>> I am not involved in avr-libc development at all, but I've done my bit
>> of gcc inline assembly.  And you are correct - you need the empty string
>> for the memory barrier.
>>
>> mvh.,
>>
>> David
>>
>>
>> On 21/01/17 17:54, Ralf Ramsauer wrote:
>>> Hi,
>>>
>>> you define _MemoryBarrier() inside avr/cpufunc.h as follows:
>>> #define _MemoryBarrier() __asm__ __volatile__(:::"memory")
>>> which won't compile in my case:
>>>     foo.c:33:2: error: expected string literal before ‘:’ token
>>>       _MemoryBarrier();
>>>
>>> Shouldn't this rather be defined as:
>>> #define _MemoryBarrier() __asm__ __volatile__("":::"memory")
>>>
>>> If someone could confirm this I'll send a short patch.
>>>
>>> Cheers
>>>   Ralf
>>>
>>> PS: BTW: your project page [0] links to [1], which seems to be a dead
>>> link.
>>> [0] http://savannah.nongnu.org/cvs/?group=avr-libc
>>> [1] http://web.cvs.savannah.nongnu.org/viewcvs/?root=avr-libc
>>>
> 
>