From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98171 invoked by alias); 9 Nov 2018 19:42:31 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 98157 invoked by uid 89); 9 Nov 2018 19:42:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy= X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Nov 2018 19:42:28 +0000 Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 4B60010A87D; Fri, 9 Nov 2018 14:42:26 -0500 (EST) Subject: Re: [PATCH] Fix search of debug files for remote debuggee To: Andrey Utkin , gdb-patches@sourceware.org References: <20181109190940.22554-1-autkin@undo.io> From: John Baldwin Openpgp: preference=signencrypt Message-ID: <10046787-753c-f7e0-4386-2b50086ae530@FreeBSD.org> Date: Fri, 09 Nov 2018 19:42:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181109190940.22554-1-autkin@undo.io> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg00170.txt.bz2 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 // is intentional rather than the // behavior that I would like (and that I think your use case also wants). -- John Baldwin                                                                            Â