VCS: a plugin given by elaboration -load AND runtime -sv_lib from different paths is loaded twice, with separate static state

Setup: a VPI+DPI capture library. simv was elaborated with -load /abs/build-dev/capture.so:register (VPI system task registration needs compile-time -load), and the run script also passed -sv_lib <builddir>/capture for the DPI imports. To test a new plugin, I made a second build dir holding only the new capture.so plus symlinks to the old build's simv and simv.daidir.

What happened: the two paths are two different dlopen'ed objects in one process. The VPI start task ran in the -load copy, while DPI calls and state went to the -sv_lib copy (anonymous-namespace globals are per-copy, and interposed external symbols can mix code from both). Symptoms: segfaults inside the plugin's start routine, garbage sizes (e.g. a 68 GB reservation built from uninitialised vectors), and 'free(): invalid pointer'. Several 'red/green' results looked like real bugs and were all invalid.

Fix/rule: test only the plugin that simv -loads. Install the candidate at the -load path (keep a backup), or re-elaborate. Never mix a symlinked simv with another dir's -sv_lib. A cheap check: strings -a simv | grep <libname> and the elaboration command line show the -load path. Also note that per-design DPI stub files (e.g. generated per-width entry points) must be linked into the plugin each simv expects; a plugin built for another design fails at runtime with Error-[DPI-DIFNF].

Related build-script pitfall: (cd src && bash src/watched.sh ...) used a relative path that only resolves from the parent dir. The compile never ran, the error was filtered out by a grep, and a stale binary got installed. Check that the output is newer than its sources before installing.