On "Marvell Feroceon CPU @ 1GHz on a Marvell DB-78x00-BP Development
Board (ARM v5)" running Linux 2.6.32.42 valgrind immediately dies in
my unstable chroot:

$ valgrind --version
Illegal instruction

gdb shows

Program received signal SIGILL, Illegal instruction.
0x00008b6c in ?? ()
(gdb) bt
#0  0x00008b6c in ?? ()
#1  0x00008d7c in ?? ()
#2  0x00008d7c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) x/4i $pc
=> 0x8b6c: movw	r2, #4097	; 0x1001
   0x8b70: add	r0, sp, #20
   0x8b74: bl	0x89cc <memset>
   0x8b78: ldr	r0, [pc, #632]	; 0x8df8

forwarded 701691 https://bugs.kde.org/show_bug.cgi?id=248998
severity 701691 wishlist
retitle 701691 valgrind: support for ARMv5/v6
kthxbye

AFAICT building/running valgrind on ARMv5 is not supported (also see #592614)
but there are a couple of patches floating around [0] to add support for them.
I don't know if they actually work (or if they apply at all) though.

Cheers

[0] https://bugs.kde.org/show_bug.cgi?id=248998

Alessandro Ghedini <ghedo@debian.org> writes:
is a shell script maybe it could inform the user about this? Something
like this:

if grep -q "^CPU architecture: 4" /proc/cpuinfo || grep -q "^CPU architecture: 5" /proc/cpuinfo; then
   echo "valgrind does not yet support ARMv4 or ARMv5"
   exit 1
fi

Example cpuinfo from openmoko:

Processor       : ARM920T rev 0 (v4l)
BogoMIPS        : 199.47
Features        : swp half thumb
CPU implementer : 0x41
CPU architecture: 4T
CPU variant     : 0x1
CPU part        : 0x920
CPU revision    : 0

Hardware        : GTA02
Revision        : 0360
Serial          : 0000000000000000

Example cpuinfo from the marvell development board:

Processor       : Feroceon rev 0 (v5l)
BogoMIPS        : 999.42
Features        : swp half thumb fastmult vfp edsp
CPU implementer : 0x41
CPU architecture: 5TE
CPU variant       : 0x1
CPU part          : 0x926
CPU revision      : 0

Hardware          : Marvell DB-78x00-BP Development Board
Revision          : 0000
Serial              : 0000000000000000

Example cpuinfo from marvell sheevaplug:

Processor       : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS        : 1192.75
Features        : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant       : 0x2
CPU part          : 0x131
CPU revision      : 1

Hardware          : Marvell eSATA SheevaPlug Reference Board
Revision          : 0000
Serial              : 0000000000000000

Just ran into this issue on our build box abel -- I was genuinly surprised to
see valgrind available for that architecture so immediately jumped to install
it -- but as this report shows, it is next to useless on armel, so why we carry
armel build at all thus confusing poor users?

may be

 override_dh_auto_test:
        : # do nothing for now

should be tuned up to run at least few really quick tests to guarantee that
valgrind works to at least some degree on a given platform, and if not -- fail
that build thus avoiding users' frustration with useless package.  Meanwhile
removing all the builds for unsupported architectures.

NB I have been enabling build-time testing for all of my packages and yes
-- it does give more work to make package suitable for testing/stable BUT it
provides a guarantee against many bugs being unraveled on users systems after.

Cheers,

It was enabled to let armel users with ARMv7 hardware to use valgrind. At least
that's what I understood from #592614, but I wasn't the maintainer at the time.

There's no such thing as "quick tests" in valgrind sources, and the regression
and performance test suites (intended for the valgrind developers) are way too
heavy and fragile to be enabled on Debian's buildds.

Cheers

Hi,
Something as little as "valgrind ls" would do it.
It could have saved some time from me when I tried running valgrind on
armel on Wheezy...

Thanks,
Balint

Did you read the other part of my email?

Obviously running valgrind on the armel buildd wouldn't have worked since thay
are not ARMv7. Building armel ARMv7-only valgrind on ARMv5 was *by design*, to
let people with armel ARMv7 systems use it.

In any case valgrind is no longer built on armel, and will be removed from
there soon.

Cheers

Hi Alessandro,
2013.11.13. 11:06, "Alessandro Ghedini" <ghedo@debian.org> ezt írta:
surprised to
to install
why we carry
valgrind. At least
the time.
regression
are way too
Sure. I meant this could be a very basic regression test which would run on
buildd machines now with dropping the special case armel arch and could
help people rebuilding Valgrind with changed dependencies.
valgrind. At least
the time.
thay
design*, to