Good day!
I'm playing around one C project. It is located on FreeBSD machine (it looks like Raspberry PI2, not sure)
The problem is I want to run project in Valgrind to find memory leakage. When I try to install Valgrind through ports, I get next error:
root#raspberry-2-55:/usr/ports/devel/valgrind # make
===> valgrind-3.10.1.20160113,1 is only for i386 amd64, while you are running
armv6.
*** Error code 1
Stop.
make: stopped in /usr/ports/devel/valgrind
Please help to run valgrind on this platform.
The combination ARM6/FreeBSD is not supported.
Valgrind fully supports FreeBSD i386 and amd64. You can find information on the ports here FreeBSD stable port and here FreeBSD development port.
At a guess, Valgrind support for ARM won't be implemented until and if ARM becomes a Tier 1 platform or until someone steps forward to do the porting.
See also the Valgrind team's statement on porting:
Maintaining each port takes a lot of effort, more so than for most other programs. Valgrind is fragile due to the low-level nature of what it does. Also, each platform port has CPU-specific code, OS-specific code and platform-specific code, and testing all the combinations is difficult.
Update:
On FreeBSD you can use the very powerful dtrace tool for performance monitoring and debugging. It does have a steep learning curve, though.
My favorite debugging tool is still placing printf() in strategic locations. Say you suspect your program crashes in a large block of code. Place a printf in the middle, recompile and re-run. If you see the output, the error came after the printf. If you don't it was before the printf. You have now halved the size of the block containing the error. Now add another printf in the middle of the remaining suspicious code and repeat. This technique is called bisection. You can also use it to monitor the value of a variable.
I would suggest to wrap the debugging printf in a macro ([1], [2]), so you can leave them in the code but you can disable them for a release build.
Related
I realize this may be a really dumb question. Please humor me:
True or False: The only way to compile a program to run on a VxWorks platform is to purchase a development environment like Tornado or Workbench from WindRiver.
(I'm looking for an free/open-source solution to compile for a VxWorks platform.)
Outside of an academic license (which would use a VxWorks installation anyway), there is not any way to legally compile your code for a vxWorks platform.
Technically, you CAN obtain the GNU toolchain used to compile code for VxWorks.
The issue you will run into is that you won't have access to the header files necessary for compiling your code or the libraries to link against.
One can use a generic GNU cross-compiler to generate ELF files, and load them onto a running VxWorks system using the ld command. However, I don't recommend it for anything beyond proof-of-concept or initial experimentation -- the VxWorks libraries and Wind River's superb documentation of them are both necessary.
On the development host:
powerpc-elf-eabi-gcc -c foo.c
Then on the target-resident shell, that has mounted a filesystem from the development host (for example, over NFS):
-> ld < foo.o
-> main()
(Where the function main() comes from foo.c)
Since VxWorks is proprietary, they made it so you need their tools (Workbench/Tornado), which they supply, in order to develop for their OS.
Having server x86/x64, how best develop software under AIX6/7 on C++?
Someone personally tried to do it and that advise from personal experience:
Can have any IBM compilers for x64, which ensures portability compilation on PowerPC AIX or can be have a virtual machine under Windwos x64 with emulate PowerPC x64 to install AIX and compile under it, or may be better buy cloud's service with AIX to develop and where can I do it?
As I know QEMU does not support AIX.
What do you say about Simics, OVPSim and Bochs or other?
I'm not clear on the question but if you don't have the AIX include files, you are going to have trouble trying to develop code that will compile on AIX. AIX often throws in some oddity that needs to be worked around in the include files.
As far as which compiler, I use gcc. Start by pulling down the gcc from IBM: http://www-03.ibm.com/systems/power/software/aix/linux/toolbox/ezinstall.html Then pick a GCC and compile it using the GCC you pulled down. Then use the new GCC for your development. An alternative would be to pull down the GCC from perzl: http://www.perzl.org/aix/index.php?n=Main.Gcc -- I've never tried that but I've heard good things about them.
Hope this helps
Update to Alex:
Yes. As mentioned, the gcc supplied by IBM will give you fits but it is good enough to compile your own gcc which will then be very stable. I've written device drivers using C++ for AIX, used g++, and included parts of Boost.
gcc/g++ for AIX is very stable and complete if compiled properly. Aside from that project, I have about 50 open source packages working on AIX. Most are C and not C++ but in general, if you are doing open source, gcc on AIX will give you less obstacles than xlc. Not xlc's fault. Its just what the developers assume. Like perzl, I use to upload my images as installp install images but had no users so I stopped.
Last: the customary warning is to not use GNU's ld. Use AIX's ld and assembler (as) but you can find threads that will contradict this. I have not seriously tried GNUs ld although I took a stab at it once about 6 months ago and then got side tracked.
Two of my projects you might want to look at:
https://github.com/pedz/aix-build-scripts -- this is a (probably hard to follow) set of scripts to start from ground zero and get you rolling compiling open source projects on AIX.
https://github.com/pedz/aixbin -- This is a set of two scripts that I now have ambivalent feelings about. Many open source projects (Ruby in particular) need these scripts but others (GNU Emacs) will fail if they are used.
I have been researching Golang and I see that it has a compiler.
But is it compiling Go into assembly level code or just converting it into BYTECODES and then calling that compilation? I mean, even in PHP we are able to convert it into BYTECODES and have faster performance.
Is Golang a REPLACEMENT for system level programming and compiling ?
This is really a compiler (in fact it embbeds 2 compilers) and it makes totally self sufficient executables. You don't need any supplementary library or any kind of runtime to execute it on your server. You just have to have it compiled for your target computer architecture.
From the documentation :
There are two official Go compiler tool chains. This document focuses
on the gc Go compiler and tools (6g, 8g etc.). For information on how
to work on gccgo, a more traditional compiler using the GCC back end,
see Setting up and using gccgo.
The Go compilers support three instruction sets. There are important
differences in the quality of the compilers for the different
architectures.
amd64 (a.k.a. x86-64); 6g,6l,6c,6a
A mature implementation. The
compiler has an effective optimizer (registerizer) and generates good
code (although gccgo can do noticeably better sometimes).
386 (a.k.a. x86 or x86-32); 8g,8l,8c,8a
Comparable to the amd64 port.
arm (a.k.a. ARM); 5g,5l,5c,5a
Supports only Linux binaries. Less widely used than
the other ports and therefore not as thoroughly tested.
Except for
things like low-level operating system interface code, the run-time
support is the same in all ports and includes a mark-and-sweep garbage
collector, efficient array and string slicing, and support for
efficient goroutines, such as stacks that grow and shrink on demand.
The compilers can target the FreeBSD, Linux, NetBSD, OpenBSD, OS X
(Darwin), and Windows operating systems. The full set of supported
combinations is listed in the discussion of environment variables
below.
On a server you'll usually target the amd64 platform.
Note that Go is well known for the speed of compilation. When deploying my server programs, I don't build for the different platforms on the development computer : I deploy the sources and I compile directly on the production servers. Since Go1 I never had a code compiling on one platform and not compiling on the other ones.
On Windows I had no problem in making an exe on my development computer and simply sending this exe to people never having installed anything Go related.
Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language.
Source - golang.org
Golang is a compiler-based language, it can easily be compiled on the development computer for any targeted system such as linux and mac.
A golang project when have compiled turns to a self-sufficient executable and can be ran on the targeted system without anything additional. It's because the golang compiler turns your code into bytes ready to execute on a system which can run compiled c code.
I am a newbie to embedded developement, as figure shown. I have a small ARM board, AT91SAM7-EX256. I have also a JTAG programmer dongle, too. I am using Linux (Ubuntu x86_32) on my notebook and desktop machine. I'm using CodeSourcery Lite for cross-compiling to ARM-Linux.
Am I right that I can't use this Linux-target cross-compiler to make binary or hex files for the small ARM board (it comes without any operating system)? Should I use the version called ARM EABI instead?
As I see, it's a "generic" ARM compiler. I've read some docs, and there're lot of options to specify the processor type and instruction set (thumb, etc.), there will be no problem with it. But how can I tell the compiler, how should the image (bin/hex) looks like for the specific board (startup, code/data blocks etc.)? (In assemblers, there're the org and load directives for it.)
What software do I need to capture some debug messages from the board on my PC? I don't want to on-board debugging, I just need some detailed run-time signal, more than just blinking leds.
I have an option to use MS-Windows, I can get a dedicated machine for it. Do you recommend it, is it much easier?
Can I use inline assembly somehow in my C code? I dunno anything about that. Can I use C++ or just C?
I have also a question, which don't need to answer: are there really 4096 kind of GNU compilers and cross-compilers (from Linux_x86_32 -> Linux_x86_32, Linux_x86_32 -> Linux_ARM, OSX -> Linux_ARM, PPC_Linux -> OSX) and 16 different GNU compiler sources (as many target platforms/processors exists) around? The signs says "yes", but I can't believe it. Correct me, and show me the GNU compiler which can produce object file for any platform/processor, and the universal linker which can produce executable for any platform.
While Windows is not a "better" platform do this kind of embedded development on, it may be easier to start with since you can get a pre-built environment to work with. For example, Yagarto (which I would recommend).
Setting up an embedded development environment on Linux can require a considerable amount of knowledge, but it's not impossible.
To answer your questions:
Your Linux cross-compiler comes with libraries to build executables for a Linux environment. You have hinted that you want to build a bare-metal executable for this board. While you can do this with your compiler, it will just confuse things. I recommend building a baremetal cross-compiler. Since you're building your own baremetal executable (and thus you are the operating system, the ABI doesn't matter since you're generating all of the code and not interoperating with other previously built code.
There are several versions of the ARM instruction set (and Thumb). You need to generate code for your particular processor. If you generate the code for a newer version of the instruction set, you will likely generate code which generates a reserved instruction exception. Most prebuilt gcc cross-compiler toolchains for ARM are "multilib" and will build for a variety of architectures in both ARM and Thumb.
Not sure exactly what you're looking for here. This is a bare metal platform. You can use the debugger channel to send messages if you're debugging on target, or you'll need to build your own communication channel into the firmware you write (i.e. uart support).
See above.
Yes. See here for details on gcc's extended inline assembly syntax. You can do this in C++ and C. You can also simply link pure assembly files.
There is no universal gcc compiler / linker. You need a uniquely built compiler for each host / target combination you use.
Finally, please take a look at Atmel's documentation. They have a wealth of information on developing for this target as well as a board package with the needed linker directives and example programs. Note of course the package is for Atmel's own eval board, but it will get you started.
http://sam7stuff.blogspot.com/
I use either of the codesourcery lite versions. But I have no use for the gcc library nor a C library, I just need a compiler.
In the gcc 3 days newlib was great, modify two files worth of system support (simple open, close, read, putc type stuff) and you could compile just about anything, but with gcc 4.x you cannot even go back and cross compile gcc 3.x, you have to install an old linux distro in a virtual machine.
To get the gcc library yes you probably want to use the eabi version not the version with linux gnueabi in the file names.
You might also consider llvm (if you dont need a C library, and you will still need binutils), hmm, I wonder if newlib compiles with llvm.
I prefer to avoid getting trapped in sandboxes, learn the tools and how to manipulate the linker, etc to build your binaries.
I am quite new to the embedded linux programming and did not really understand this concept very well.
Can anyone explain the essence of the "host-target" relation? Is this model only specific to the "cross-compilation"? Is it used just because "executable code will be run on another enviroment"? and what matters with the linux kernel on the target? E.g., the "building the embedded linux system" book mentioned this, but did not explain its motivation or goal of this type of development.
Thanks a lot.
The 'motivation' for this model is that seldom is an embedded target a suitable platform for development. It may be resource constrained, have no operating system, have no compiler that will run on the target, have no filesystem for source files, have no keyboard or display, no networking, and may be relatively slow or anything else you might need to develop effectively.
If your embedded system is suited to running Linux, it is possible that not all of the above limitations apply, but almost certainly enough of them to make you want to avoid developng directly on the target. If this were not so, they it hardly qualifies as an embedded system perhaps.
http://www.landley.net/writing/docs/cross-compiling.html
Seems pretty clear. What specific questions do you have?
Linux since its very origin was written in very portable way. It runs on a whole range of machines with very different CPUs, and it is considered the Good Thing to write in a portable way, so that, for example, package maintainer can easily port your program to some embedded ARM or Cygwin, or Amiga, or...
So, yes, the model is "only" specific to cross-compilation, but actually about every compilation on Linux is a (variant of) cross-compilation, just that by default build, host and target are automatically set to the same value, the same as the machine you run on.
Still, even then, you can take a Linux-i386 compiled compiler, sources for it, and "cross-compile" it for Linux-amd64. And the resulting binary will run much faster on a 64bit CPU.
It IS quite essential in embedded programming though. Mostly because you write programs for weak CPUs that are not capable of running a compiler or would run it at a snail pace. So you take a cross-compiler on a fast CPU (say, some multi-core Intel) and cross-compile for the embedded CPU (say, some low-end ARM).
"In different environment" is putting things very mildly. What you're doing when cross-compiling for embedded is working with entirely different instruction set, different memory access modes, different resource access methods and so on and so on. A machine of entirely different construction than the build host. Your build host may be a Windows PC running Cygwin. Your target may be a chip inside a smartphone. The binary will look nothing like the Cygwin .exe files.
As a direct consequence, -everything- must be compiled for the target from scratch. The kernel, the system utilities, the system libraries, all the tools the target must be running. Thing is, if the target is a ticket selling booth, there is really no sense cross-compiling Eclipse, GCC and Gnome for it, then developing in "local" environment, typing your code on a ticket booth keyboard. Instead, you just cross-compile the essentials of the OS, and your specific applications. You keep the development environment on the build machine, and cross-compile everything you need on the embedded device.
[in practice, you get a Linux distro for the target, and just compile whatever you need modified].