From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6760 invoked by alias); 27 Apr 2019 18:56:18 -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 6736 invoked by uid 89); 27 Apr 2019 18:56:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=H*c:US-ASCII, H*r:112, somebody, remains X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 27 Apr 2019 18:56:15 +0000 Received: by simark.ca (Postfix, from userid 112) id 9BC131E7B4; Sat, 27 Apr 2019 14:56:13 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 1A70A1E175; Sat, 27 Apr 2019 14:56:11 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 27 Apr 2019 18:56:00 -0000 From: Simon Marchi To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: Fix lookup of separate debug file on MS-Windows In-Reply-To: <83ftq3v1vv.fsf@gnu.org> References: <83ef5ze84y.fsf@gnu.org> <03da9895-5136-1da6-8c37-c4be0d06b608@gmail.com> <8336mfdumf.fsf@gnu.org> <831s1va7h8.fsf@gnu.org> <2697b965-e108-5e7c-75d3-9baa7493141c@simark.ca> <835zr68kiw.fsf@gnu.org> <491fba49-4be5-ef4e-c75e-8b8845673360@simark.ca> <83ftq3v1vv.fsf@gnu.org> Message-ID: <2ef82187bed72c3fbe61d851c2d6781b@simark.ca> X-Sender: simark@simark.ca User-Agent: Roundcube Webmail/1.3.6 X-SW-Source: 2019-04/txt/msg00605.txt.bz2 On 2019-04-27 12:39, Eli Zaretskii wrote: >> Cc: gdb-patches@sourceware.org >> From: Simon Marchi >> Date: Sat, 27 Apr 2019 12:16:23 -0400 >> >> I think we should consider the case where we build GDB on GNU/Linux, >> to remotely >> debug a Windows program. When building on GNU/Linux, HAS_DRIVE_SPEC >> always return false, >> since it's defined as (see include/filenames.h): >> >> #define HAS_DRIVE_SPEC(f) (0) >> >> Let's suppose DEBUGDIR is "D:/my/debug", DIR is >> "target:E:/the/directory/" and DEBUGLINK >> is "program.debug". On GNU/Linux, we would build the path >> >> target:D:/my/debug/E:/the/directory/program.debug >> >> And I suppose that the "E:" would result in the debug file not being >> found. > > When debugging remotely, is the debug info on a Windows or on a > GNU/Linux filesystem? If the latter, the above will work. I always > thought that in remote debugging, GDB itself runs on the local host, > i.e. on GNU/Linux in this case, and the part that runs on the remote > is gdbserver. Isn't that correct? The latter part is correct, gdbserver would run on the Windows machine, while GDB would run on the local GNU/Linux machine. But the debug info can come from either places, depending on the setup. If the executable read by GDB comes from the "target:" filesystem, we will search for the separate debug files on the target: filesystem (hence all this complexity with target_prefix in this function). If you are debugging remotely, the target: filesystem represents the remote filesystem, which GDB can read through requests serviced by gdbserver. If you have a local copy of the remote filesystem (a sysroot) and made "set sysroot" point to it, then GDB will read from there. If you are debugging locally on Windows, you want the path to end up like: target:D:/my/debug/E/the/directory/program.debug If you are debugging remotely your Windows from another Windows, using "set sysroot target:" (the default), you also want the path to end up like target:D:/my/debug/E/the/directory/program.debug If you are debugging remotely from a Windows machine to another Windows machine, but installed a sysroot of the debugged machine in F:/sysroot, then I guess you'll want the path to end up like F:/sysroot/D/my/debug/E/the/directory/program.debug So maybe we would want to apply the same treatment to the sysroot drive letter? If you are debugging remotely your Windows from GNU/Linux, using "set sysroot target:", we would want the path to end up like target:D:/my/debug/E/the/directory/program.debug Since the target filesystem wouldn't support a "E:" directory. If you are debugging remotely your Windows from GNU/Linux, but installed a sysroot of the debugged machine in /sysroot, then either of these could work: /sysroot/D:/my/debug/E:/the/directory/program.debug /sysroot/D:/my/debug/E/the/directory/program.debug /sysroot/D/my/debug/E:/the/directory/program.debug /sysroot/D/my/debug/E/the/directory/program.debug This leads me to say that for simplicity, when we convert a Windows drive letter into a directory component, we should always convert it to the letter without the colon. This way, whatever platform GDB itself runs on, the searched path will be the same and predictable. Also, if you were to copy D:/my/debug over to your GNU/Linux machine, you wouldn't have to rename the "E" directory to "E:". ? I would suggest the first one, If you are debugging remotely from GNU/Linux and installed a sysroot of your Windows machine in /sysroot, then I suppose you would want the path to end up like: /sysroot/D:/my/debug/E/the/directory/program.debug ? Or /sysroot/D/my/debug/E/the/directory/program.debug ? In this last example, the file is lookup up on the GNU/Linux filesystem, so the path technically could include the E:. However, since the So if you are using a local sysroot of your In the first case since you are reading from the GNU/Linux filesystem, so colons would be supported. But in the latter case, they wouldn't. One use case to consider is: you start debugging your Windows machine from your GNU/Linux machine, we do strip the colon, such that the separate debug info is searched at: target:D:/my/debug/E/the/directory/program.debug and it is found. However, it is quite slow, because everytime you start debugging, GDB needs to download this information. So you make a sysroot of your Windows machine on your GNU/Linux machine, at /sysroot, such that you have locally: /sysroot/E:/the/directory/program.exe /sysroot/D:/my/debug/E/the/directory/program.debug Then, you point GDB to the executable in your local sysroot, and it should At this point, the local filesystem > >> So I think we should be using HAS_DRIVE_SPEC_1, which allows us to do >> the same check. We >> just need to pass to the macro whether the target filesystem id >> DOS-based. The only problem >> is, how do we know whether the target filesystem is DOS-based? We >> wouldn't want >> HAS_DRIVE_SPEC_1 to do this stripping erroneously when debugging >> natively on GNU/Linux... > > But if we do that, how do we distinguish between the use case you > describe above and a use case where the we debug locally and the file > names just happen to include colons? Are we willing to restrict file > names on GNU/Linux to support the remote debugging on Windows? > > Thanks for the other comments, I will implement them when we agree > about the above issue. On 2019-04-27 12:39, Eli Zaretskii wrote: >> Cc: gdb-patches@sourceware.org >> From: Simon Marchi >> Date: Sat, 27 Apr 2019 12:16:23 -0400 >> >> I think we should consider the case where we build GDB on GNU/Linux, >> to remotely >> debug a Windows program. When building on GNU/Linux, HAS_DRIVE_SPEC >> always return false, >> since it's defined as (see include/filenames.h): >> >> #define HAS_DRIVE_SPEC(f) (0) >> >> Let's suppose DEBUGDIR is "D:/my/debug", DIR is >> "target:E:/the/directory/" and DEBUGLINK >> is "program.debug". On GNU/Linux, we would build the path >> >> target:D:/my/debug/E:/the/directory/program.debug >> >> And I suppose that the "E:" would result in the debug file not being >> found. > > When debugging remotely, is the debug info on a Windows or on a > GNU/Linux filesystem? If the latter, the above will work. I always > thought that in remote debugging, GDB itself runs on the local host, > i.e. on GNU/Linux in this case, and the part that runs on the remote > is gdbserver. Isn't that correct? The latter part is correct, gdbserver would run on the Windows machine, while GDB would run on the local GNU/Linux machine. But the debug info can come from either places, depending on the setup. If the executable read by GDB comes from the "target:" filesystem, we will search for the separate debug files on the target: filesystem (hence all this complexity with target_prefix in this function). If you are debugging remotely, the target: filesystem represents the remote filesystem, which GDB can read through requests serviced by gdbserver. If you have a local copy of the remote filesystem (a sysroot) and made "set sysroot" point to it, then GDB will read from there. I tried to think about different scenarios, it brought more questions than answers, but here it is. If you are debugging locally on Windows, you want the path to end up like: target:D:/my/debug/E/the/directory/program.debug If you are debugging remotely your Windows from another Windows, using "set sysroot target:" (the default), you also want the path to end up like target:D:/my/debug/E/the/directory/program.debug If you are debugging remotely from a Windows machine to another Windows machine, but installed a sysroot of the debugged machine in F:/sysroot, then I guess you'll want the path to end up like F:/sysroot/D/my/debug/E/the/directory/program.debug We couldn't have a "D:" directory, so maybe we would want to apply the same treatment to the sysroot drive letter? If you are debugging remotely your Windows from GNU/Linux, using "set sysroot target:", we would want the path to end up like target:D:/my/debug/E/the/directory/program.debug ... since the target filesystem wouldn't support a "E:" directory. If you are debugging remotely your Windows from GNU/Linux, but installed a sysroot of the debugged machine in /sysroot, then either of these could work: /sysroot/D:/my/debug/E:/the/directory/program.debug /sysroot/D:/my/debug/E/the/directory/program.debug /sysroot/D/my/debug/E:/the/directory/program.debug /sysroot/D/my/debug/E/the/directory/program.debug This leads me to say that for simplicity, when we convert a Windows drive letter into a directory component, we should always convert it to the letter without the colon. This way, whatever platform GDB itself runs on, the searched path will be the same and predictable. Also, if you were to copy D:/my/debug/E/the/directory/program.debug over to your sysroot on the GNU/Linux machine, you wouldn't have to rename the "E" directory to "E:" for it to be found. Now, the question remains: how do we know for sure a path is a Windows path, in which we need to strip the colon? I don't know. Given the complexity of supporting all these scenarios (if we want to support them, we at least want to test them, which is a lot of work) and the fact that they are all theoretical at this point, I would be fine to go with what you had in your patch (using HAS_DRIVE_SPEC). If somebody ever needs to remotely debug a Windows machine from a Linux machine and have GDB find separate debug file in the remote debug file directory... then they can add the missing pieces :). Simon