CODEWITHSUNDEEP
valgrindfreebsdraspberry-pi2
George Gaál
George Gaál

Reputation: 1258

Valgrind on FreeBSD

Good day!

I'm playing around one C project. It is located on FreeBSD machine (it looks like Raspberry PI2, not sure)

enter image description here

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.

Upvotes: 3

Views: 1342

Answers (2)

Paul Floyd
Paul Floyd

Reputation: 6936

Valgrind on FreeBSD now supports aarch64. Still not yet 32bit arm.

For reference, this took about a month spent working fairly hard in my spare time. I expect that porting to 32bit arm would be even quicker since the aarch64 and arm code is generally quite similar.

Upvotes: 0

Roland Smith
Roland Smith

Reputation: 43533

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.

Upvotes: 6

Related Questions