Hi,
Post by David BrownHi,
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.
Post by David BrownThe 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.
Post by David BrownI 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)
Post by David BrownThis 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
Post by David BrownOf 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
Post by Ralf RamsauerThanks 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
Post by David BrownHi,
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
Post by Ralf RamsauerHi,
#define _MemoryBarrier() __asm__ __volatile__(:::"memory")
foo.c:33:2: error: expected string literal before ‘:’ token
_MemoryBarrier();
#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