ctf: handle srcdir-relative paths properly.

ctf: handle srcdir-relative paths properly.

The dwarf2ctf tool maintains various blacklists to get around things some
modules do which are incompatible with large-scale deduplication of types or
with having one type table per module. These blacklists are in the source tree,
and unfortunately we were looking for them using a relative path, which equates
to the objdir when O= or KBUILD_OUTPUT are in use: so we got assertion failures
from dwarf2ctf and a kernel build failure when it detected that something was
wrong with its duplicate-type detection.

Worse yet, one of these blacklists, member.blacklist, contains the names of
source files.  These paths relate to entities in the source tree, but they are
compared to source-file paths in object files generated by the compiler (which
are in theory objdir-relative, but which are in any case always absolute iff
KBUILD_OUTPUT is in use).  If these comparisons are to be successful, we must
absolutize the relative paths in the member.blacklist against the source tree,
not against the object tree.

We don't need to extend the realpath()-result-caching infrastructure to handle
this case, because we're only absolutizing *one path* this way, and at most
it'll be a few dozen.  The caching infrastructure exists to handle cases where
millions or billions of realpath()s are done.  We just need to chdir() to the
source tree, realpath(), and fchdir() back.  (We use the O_PATH open() flag to
do this if possible, but older glibcs such as that on OL6 do not provide O_PATH,
and it has an architecture-dependent so we cannot provide it ourselves: in that
case we fall back to O_RDONLY | O_DIRECTORY, which should always work since the
objdir really should always be readable by the current user.)

Orabug: 19712731

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Tested-by: Chuck Lever <chuck.lever@oracle.com>
Tested-by: Guangyu Sun <guangyu.sun@oracle.com>
Acked-by: Guru Anbalagane <Guru.Anbalagane@oracle.com>