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

[Ralf Ramsauer]

Hi,

On 01/23/2017 09:21 AM, David Brown wrote:
> 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.
I'm using Gentoo Linux.  Gentoo comes along with a nice tool called
crossdev [1].  You specify your desired target architecture and build
triple, libc type (musl, glibc, diet, ...) and it compiles the whole
cross toolchain for you, including a remote cross-debugger, if you
desire.  The nice thing about is that I can select almost any version
for my binutils, gcc, gdb, libc, ...  Still, they define stable default
versions.
> 
> 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.
Ack, that's right.  And then there are those other projects that force
you to use their patched toolchain, as compilation of the project only
works with that.  That's the other side of the medal.  I'd rather stick
to upstream versions, than using a bloody old toolchain that no one will
maintain.
> 
> 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.
That's how I usually do it.  But I needed the AVR toolchain for a
hobbyist project, so I didn't want to spend half a day on just building
the toolchain on my own, for getting a LED blinking (more or less, for
blinking LEDs I wouldn't need memory barriers :-P)
> 
> 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.
Ack, using Gentoo's crossdev really integrates smooth in your system:
You can have multiple toolchain with different versions. This is my
current setup:

 [1] aarch64-unknown-linux-gnu-4.9.4 *
 [2] armv7a-hardfloat-linux-gnueabi-4.9.3
 [3] armv7a-hardfloat-linux-gnueabi-4.9.4 *
 [4] avr-4.9.3
 [5] avr-4.9.4 *
 [6] x86_64-pc-linux-gnu-5.4.0 *

gcc-config helps me to easily switch default compilers.

Cheers
  Ralf

[1] https://wiki.gentoo.org/wiki/Cross_build_environment
> 
> 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
>>>>
>>
>>
> 

-- 
Ralf Ramsauer
PGP: 0x8F10049B