There's several ways to find this out:
bitbake -g may be one of them, you are just setting the target incorrectly.
bitbake -g gets the BUILD dependencies, so, it tells you what package (or task) required valgrind to be built, however doing bitbake -g valgrind will tell you what packages are required for valgrind, not what packages require valgrind (not the same), you need to do:
bitbake <your-image> -g
e.g.
bitbake core-image-minimal -g
This will the the build dependencies for your image, and it may tell you what package from your image required valgrind, (open the task-depends.dot file and look for the valgrind lines on the right)
Bitbake -e may be another way if bitbake -g didnt suffice
bitbake -e | grep PACKAGE_INSTALL
bitbake -e will print out bitbake's dictionary, and specifically you should be looking at the PACKAGE_INSTALL variable, if valgrind is there, you can see what recipe added it to the variable and hence why its being installed
If valgrind is actually a secondary dependency, that is to say PACKAGE_A has an RDEPENDS+="valgrind", and PACKAGE_A is required to be installed, then you need to look at the package manager output, this varies depending if you are using RPMs, DEBs or IPKs files, there's more specific ways to find this out but looking at the log.do_rootfs file for your image would probably give you enough information about which package had a runtime dependency to valgrind:
for example if you used RPMs you would see something like this (trimmed for easier reading):
$ cat tmp/work/qemuarm64-poky-linux-musl/core-image-minimal/1.0-r0/temp/log.do_rootfs
Package Arch Version Repo Size
================================================================================
Installing:
base-passwd cortexa57 3.5.29-r0 oe-repo 7.2 k
busybox cortexa57 1.35.0-r0 oe-repo 364 k
busybox-mdev cortexa57 1.35.0-r0 oe-repo 8.7 k
dropbear cortexa57 2020.81-r0 oe-repo 132 k
initramfs-live-boot-tiny qemuarm64 1.0-r12 oe-repo 8.6 k
packagegroup-core-boot qemuarm64 1.0-r17 oe-repo 5.8 k
run-postinsts noarch 1.0-r10 oe-repo 7.4 k
Installing dependencies:
base-files qemuarm64 3.0.14-r89 oe-repo 13 k
busybox-inittab qemuarm64 1.35.0-r0 oe-repo 7.6 k
eudev cortexa57 3.2.10-r0 oe-repo 181 k
libblkid1 cortexa57 2.37.3-r0 oe-repo 85 k
libkmod2 cortexa57 29-r0 oe-repo 36 k
libz1 cortexa57 1.2.11-r0 oe-repo 46 k
musl cortexa57 1.2.2+git0+c4d4028dde-r0 oe-repo 364 k
netbase noarch 1:6.3-r0 oe-repo 14 k
update-alternatives-opkg cortexa57 0.5.0-r0 oe-repo 8.5 k
Installing weak dependencies:
busybox-syslog cortexa57 1.35.0-r0 oe-repo 8.7 k
In this example, you can see that I never requested libz1 to be installed in my image (and others listed as dependencies), however one of the packages from the upper section required those to run.
There's much more information in the log.do_rootfs file which may directly tell you what required valgrind, if you still cant find it, go back to bitbake -g and look for the lines containing the packages above (since those are direct dependencies to your image), one of them should be requiring valgrind.
The RPM command
Last but not least, this is tailored for rpms, but the process should be fairly similar for debs or ipks, although the commands will differ, but once you have the list of packages to be installed from log.do_rootfs you can query the rpm packages via the rpm command:
I'll use the dropbear package as an example from above:
$ rpm -qR tmp/deploy/rpm/cortexa57/dropbear-2020.81-r0.cortexa57.rpm
/bin/sh
libc.so()(64bit)
libz1 >= 1.2.11
libz.so.1()(64bit)
rtld(GNU_HASH)
update-alternatives-opkg
So, in my case, the dropbear package is the one to blame for the libz1 dependency.
