Control: severity -1 normal
(I intended to avoid having to argue by implementing specific objective
tests that valgrind has to meet to be declared available, but I did not
manage to get that done. Thus, arguing...)
On Sat, Oct 22, 2022 at 12:12:40PM +0300, Adrian Bunk wrote:
> Package: valgrind-if-available
> Severity: serious
> valgrind-if-available (3.18.1-1-1) unstable; urgency=medium
> ...
> * Drop mipsel as valgrind disagrees about blah blah baseline Loongson.
> This is wrong, and it makes at least qtmir FTBFS.
(as said already elsewhere) Failing to build because valgrind is not
available means you're using the package wrong: it may or may not pull in
valgrind, and the set of architectures can and will change without any
warning. The whole purpose of this metapackage is to track valgrind's
availability so 100+ individual packages don't need to.
Ie, instead of:
if arch in (foo bar baz quux)
build --valgrind=yes
else
build --valgrind=no
you do:
if `which valgrind >/dev/null`
build --valgrind=yes
else
build --valgrind=no
> If there is any problem with valgrind on mipsel
> it should be discussed and resolved in valgrind first,
> if valgrind is available then valgrind-if-available
> has to provide it.
No, this particular problem is that valgrind doesn't work on _some_
mipsel machines. This doesn't make valgrind itself useless, but makes
it unsuitable for being ran as a part of automated testsuites.
As our buildds appear to be all Loongsons, coding some complex machinery
to detect the subarch at runtime would be a waste of time. Flat out
saying "disable valgrind tests on mipsel" is easier and works good enough
for now.
> It is also unclear what the baseline problem is this changelog
> entry is referring to, there is no open bug in the valgrind package
> mentioned and the closest I could find was a bug that was fixed (sic)
> 5 years ago.
It fails at least in 3.19 (unstable) and 3.20 (experimental):
https://buildd.debian.org/status/fetch.php?pkg=valgrind-if-available&arch=mipsel&ver=3.19.0-1-1&stamp=1667563987&raw=0
==1833049== Memcheck, a memory error detector
==1833049== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1833049== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==1833049== Command: /tmp/___
==1833049==
VEX: Unsupported baseline
Found: Loongson-baseline
Cannot continue. Good-bye
vex storage: T total 0 bytes allocated
vex storage: P total 0 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
host stacktrace:
==1833049== at 0x5804FB44: ??? (in
/usr/libexec/valgrind/memcheck-mips32-linux)
==1833049== by 0x5804FA2C: ??? (in
/usr/libexec/valgrind/memcheck-mips32-linux)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable (lwpid 1833049)
==1833049== at 0x401B920: __start (in /lib/mipsel-linux-gnu/ld.so.1)
==1833049== by 0x7EB7B088: ???
client stack range: [0x7EB78000 0x7EB7BFFF] client SP: 0x7EB7B090
valgrind stack range: [0x42878000 0x42977FFF] top usage: 5512 of 1048576
It appears that no one, both upstream and _in Debian_, cares enough about
mipsel to fix bugs or even report them, thus I don't expect it to be solved
anytime soon -- or, probably, ever, as mipsel is not long for this world.
But, as the trivial solution would be removing support for mipsel completely
from valgrind, I think users are better served by being provided something
that works on at least _some_ hardware.
> It is also suprising if this is really a mipsel-only issue as the
> changelog claims, I would have expected any issues to also show
> up on mips64el.
This very same test works fine on mips64el.
> Therefore please report any issues with valgrind on mipsel as bugs
> against src:valgrind, but in any case please make valgrind-if-available
> always provide valgrind on all architectures where it is available.
Seems we understand "available" differently:
* for you, it means "shipped at all",
* for me, it means "works for a typical set of tasks".
valgrind on mipsel is functional on old hardware but dies even on "hello
world" on Loongson. I consider this availability to be lacking.
My plans for this bug are:
* s/available/available and functional/ in the description
* run all tests even on marginal archs, but don't fail the build if it's
an expected failure
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Only flat-earthers have a problem folding a fitted sheet.
⢿⡄⠘⠷⠚⠋⠀ I instead shape it into a ball.
⠈⠳⣄⠀⠀⠀⠀
