Re: Fix lookup of separate debug file on MS-Windows

[Simon Marchi <simark@simark.ca>]

On 2019-04-27 12:39, Eli Zaretskii wrote:
>> Cc: gdb-patches@sourceware.org
>> From: Simon Marchi <simark@simark.ca>
>> 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 <simark@simark.ca>
>> 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