Erroneous definition of _MemoryBarrier() in cpufunc.h

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Erroneous definition of _MemoryBarrier() in cpufunc.h

Ralf Ramsauer
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
GPG: 0x8F10049B


_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|

Re: Erroneous definition of _MemoryBarrier() in cpufunc.h

David Brown-4
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
>

_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|

Re: Erroneous definition of _MemoryBarrier() in cpufunc.h

Joerg Wunsch
In reply to this post by Ralf Ramsauer
As Ralf Ramsauer wrote:

> If someone could confirm this I'll send a short patch.

https://savannah.nongnu.org/bugs/index.php?37778

Already fixed in the SVN tree.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|

Re: Erroneous definition of _MemoryBarrier() in cpufunc.h

Ralf Ramsauer
In reply to this post by David Brown-4
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
GPG: 0x8F10049B

_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|

Re: Erroneous definition of _MemoryBarrier() in cpufunc.h

David Brown-4
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
>>>
>
>


_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|

[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

_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev