Re: [PATCH] Fix search of debug files for remote debuggee

[John Baldwin <jhb at FreeBSD dot org>]

On 11/9/18 11:09 AM, Andrey Utkin wrote:
> When using remote debugging server, and when debuggee filename is
> inferred via qXfer:exec-file:read request, or sysroot starts with
> "target:", this "target:" prefix of filepaths is not treated correctly
> during debug file search - it appears in the middle of the looked up
> paths.

I only have a somewhat related comment.  I have a similar-ish issue when
using sysroot and cross-debugging without a remote target.  My use case is
that I'm on an x86 host but that I run QEMU instances of other architectures
(mips, arm, riscv, etc.) on my host.  I tend to build base OS builds and
install them to some path (e.g. /ufs/riscv64/rootfs) and then use a tool
like makefs to generate a filesystem image to use with QEMU.  I will then
scp a core dump out and debug it like so:

gdb /path/to/binary
...
(gdb) set sysroot /ufs/riscv64/rootfs
(gdb) core /path/to/core

Now there are debug symbols for the various base OS libraries and binaries
installed in the sysroot at /ufs/riscv64/rootfs/usr/lib/debug.  For example,
FreeBSD's libc is installed as /lib/libc.so.7 under the sysroot
(/ufs/riscv64/lib/libc.so.7) and the debug info is stored at /usr/lib/debug
under the sysroot (/ufs/riscv64/usr/lib/debug/lib/libc.so.7.debug).  However,
GDB places the sysroot after the debug prefix and ends up looking for
/usr/lib/debug/ufs/riscv64/lib/libc.so.7 on the host instead.  I usually
work around this by creating a symlink from /usr/lib/debug/ufs/riscv64 to
/ufs/riscv64/usr/lib/debug, but it seems like a bug to me that the we don't
look for debug files "under" the sysroot.

I bring this up because I wonder if a more general solution of always putting
the sysroot before the debug prefix (e.g. "/usr/lib/debug") wouldn't fix
both your case and mine.  It's not clear to me what the "correct" behavior
is for mixing sysroot with separate debug files.   It may be that the current
behavior of <debug dir>/<sysroot>/<object file> is intentional rather than
the <sysroot>/<debug dir>/<object file> behavior that I would like (and that
I think your use case also wants).

-- 
John Baldwin