So, turns out, when you run a program that uses CUDA, either directly or
indirectly (my program runs on CUDA, but uses OpenCL instead), there are
issues preventing libasan
from working. More specifically, if you run a program with libasan, the CUDA
libraries will not work, and the OpenCL ones will not display an NVIDIA platform
as available in the first place.
From my experience, seems like there are similar issues preventing Valgrind from working, either.
Note to self: if your distro’s repositories don’t have a Perl package, it’s best
to install them from CPAN instead. A tool called cpan minus (In Alpine, its
packaged as perl-app-cpanminus) can do it easily, either installing packages
into one’s home directory or globally.
GDB seems to have been clearly made with source-level debugging in mind, the kind where the source code of the program is available. Sometimes this is not the case, or you just don’t want to bother looking for the source code. Here I’ll put a bunch of useful commands.
shell scripts:
grab lines from dictionary, convert them into up-to-16-byte strings, do a binary dump
for x in `cat input_words.txt`; do echo $x | tr -d \\n | dd ibs=16 conv=sync 2>/dev/null | xxd; done
convert a .vgz directory to a .vgm one, along with updating all the playlists:
rename ".vgz" ".vgm.gz" *.vgz; gzip -d *.vgm.gz; sed -i "s/\.vgz/\.vgm/" *.m3u
(requires rename from util-linux and not from perl)
Some small hints for profiling utilities used on Linux systems.
This is a small cheat sheet to remind me of how parameter expansion works in unix shells.