Bug 464476

There problem is with sysctl kern.proc.pathname.PID

This is used to determine the full path of firefox, but when it runs under valgrind it returns the path to valgrind instead.

firefox then looks in the valgrind directory for dependentlibs.list and fails to find it.

A bit trickier than I thought since firefox is a symlink and I need to first resolve the symlink.

We don't have a VG_(lstat) as far as I can see.

Almost there. 

I use VG_(find_executable)(VG_(args_the_exename)) then check if it is a link and if so call VG_(readlink)(exe_name, out, VKI_PATH_MAX);

But readlink doesn't resolve relative paths to absolute paths.

Running firefox under memcheck to close this item !

commit 5d387642049bf366d913f572269f8bf16627ac10
Author: Paul Floyd <pjfloyd@wanadoo.fr>
Date:   Sat Jan 21 17:55:09 2023 +0100

    Bug 464476 - Firefox fails to start under Valgrind
    
    On FreeBSD, Firefox uses the kern.proc.pathname.PID sysctl
    to get the binary path (where PID can be the actual pid
    or -1). The user path is /usr/local/bin/firefox which is
    a symlink to /usr/local/lib/firefox/firefox.
    
    This was failing because we were not handling this MIB.
    That meant that the sysctl returned the path for the
    binary of the running tool (e.g.,
    /home/paulf/scratch/valgrind/memcheck/memcheck-amd64-freebsd).
    Firefox looks for files in the same directory.
    Since it was the wrong directory it failed to find them and
    exited.
    
    I also noticed a lot of _umtx_op errors. On analysis they
    are spurious. The wake ops take an "obj" argument, a pointer
    to a variable. They only use the address as a key for
    lookups and don't read the contents.