Split up debug-link and build-id debug info into separate classes to
make boundary between them more obvious.
When searching for a debug file in the "same dir" search location,
ensure its not a symlink. (user never explicitly signaled
that they trusted the directory, they only tried to import a file from
there.)
In e0aae02, the `++` was dropped from the index reference in this loop, but
that means the first item on each row of an integer array is incorrectly
repeated.
Restore the ++ so the array index is incremented across the line.
loadSymbols adds n_value to the start of the block the symbol belongs to, but
n_value is an address (see https://man.freebsd.org/cgi/man.cgi?a.out(5) ),
not an offset into its segment, so we need to subtract the segment's base.
In most cases `determineTextAddr` is 0, so they are the same for the .text
segment, which is why function symbols still loaded fine. But for the
.data and .bss segments they don't, so their symbol locations ended up shifted.
Same class of bug as the earlier min/minu fix: the displayed source
operand order contradicts the instruction syntax recorded in each
constructor's own doc comment (and LLVM/the PRM).
vminb/vminh/vminub/vminuh/vminuw/vminw, vmaxb/vmaxh/vmaxub/vmaxuh/
vmaxuw/vmaxw and shuffob/shuffoh are documented as "f ( Rtt32 , Rss32 )"
but displayed Rss before Rtt.
vaddw and vaddw:sat are documented as "vaddw ( Rss32 , Rtt32 )" but
displayed Rtt before Rss.
Includes the V62 "Rdd32,Pe4 = vminub ( Rtt32 , Rss32 )" form.
The pcodeop / inline arguments are swapped to match, so the emitted call
argument order still follows the displayed operand order. For the min,
max and add forms this is semantically neutral (all commutative); it
matters for vminubPred, whose result is defined relative to the first
operand, and for the opaque shuffob/shuffoh, whose operand roles are
positional.
Verified: SleighCompile clean, all 60 Hexagon unit tests pass. No test
expectations change (the one test pinning vminub uses R1R0 for both
sources).