[Bug win32/23547] New: GDB didn't work with unix-way names under windows environment

[pavel.seleznev at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23547

Bug ID: 23547
Summary: GDB didn't work with unix-way names under windows
environment
Product: gdb
Version: 8.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: win32
Assignee: unassigned at sourceware dot org
Reporter: pavel.seleznev at gmail dot com
Target Milestone: ---

Hello,

I have compiled program using linux subsystem under Windows 10. Compiled binary
contains paths like "/mnt/c/<...>" to source files.

And gdb via gdbgui gives me error "No source file named c."

I have tried to use path substitution
set substitute-path '/mnt/c/projectname' 'c:\projectname'
but without success.

[pavel.seleznev at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23547

--- Comment #1 from SePavel <pavel.seleznev at gmail dot com> ---
I have patched compiled binary and replace beginning of all paths from "/mnt"
to "c:/" and it doesn't helps

[pavel.seleznev at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23547

SePavel <pavel.seleznev at gmail dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Version|8.2 |7.6

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23547

Tom Tromey <tromey at sourceware dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at sourceware dot org

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
Hi. Thanks for the report.

There isn't enough information here for us to know what the problem is,
or what to do about it.

Could you try a simple "hello world" program?
And put the compilation command line and the gdb session
into this bug? That might help show what is wrong.

[pavel.seleznev at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23547

--- Comment #3 from SePavel <pavel.seleznev at gmail dot com> ---
It is not trivial task to create hello program, because original program was
not written by me

Currently, I have add logs to console in GDB.exe and try to find out what
happened

I saw issue with parser via construction PARSER_STREAM (parser)

original string looks like
:mntcprojectnamefilename.cpp:523

but after some iteration in linespec_lexer_lex_string I saw that PARSER_STREAM
(parser) points to one byte before original string starts
C:mntcprojectnamefilename.cpp:523

Hope, I will provide tomorrow additional log

[pavel.seleznev at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23547

--- Comment #4 from SePavel <pavel.seleznev at gmail dot com> ---
Please ignore my previous comment

in linespec.c there is the following code
.......
else if (PARSER_STREAM (parser)[0] == ':')
{
/* Do not tokenize the C++ scope operator. */
if (PARSER_STREAM (parser)[1] == ':')

++(PARSER_STREAM (parser));

/* Do not tokenify if the input length so far is one
(i.e, a single-letter drive name) and the next character
is a directory separator. This allows Windows-style
paths to be recognized as filenames without quoting it. */
else if ((PARSER_STREAM (parser) - start) != 1 ) ||
!IS_DIR_SEPARATOR (PARSER_STREAM (parser)[1]))
{
LS_TOKEN_STOKEN (token).ptr = start;
LS_TOKEN_STOKEN (token).length = PARSER_STREAM (parser)
- start;

return token;
}

.......

If I understand it correctly this piece of code the parser has special
condition for the situation <disk>:<folder> in windows, for the full paths like
c:/folder/source.cpp (ignore slash orientation)

The condition means: if it is not second character of parsed string (with index
1) or it is not dir separator then we have found token and should return it

but seems to me that it means the following
else if ((PARSER_STREAM (parser) - start) != 1 ) || ":" != PARSER_STREAM
(parser)[0])

I have changed function IS_DIR_SEPARATOR("\\" or "/" == s) to IS_DISK_SEPARTOR
(":" == s)
and changed the char index, because earlier we have done ++(PARSER_STREAM
(parser))

but in such case this check become unnesessary and code should be changed to
else if ((PARSER_STREAM (parser) - start) != 1 )

after this change I have code file name C:mntcPROJECTfilename.cpp:523 instead
of C that either can't opened because slashes are sripped out.

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23547

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---

Post by pavel.seleznev at gmail dot com
I have changed function IS_DIR_SEPARATOR("\\" or "/" == s) to
IS_DISK_SEPARTOR (":" == s) and changed the char index, because
earlier we have done ++(PARSER_STREAM (parser))

That was done conditionally, and the condition could not have held
if the program reached this point.

Please post your actual patch rather than a description of it.

I still don't understand the actual bug here.

You can make a hello world program by making a single .c file
and compiling it alone. Seeing all the commands would still
be useful.

[pavel.seleznev at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23547

--- Comment #6 from SePavel <pavel.seleznev at gmail dot com> ---
Steps to reproduce on Windows

1) load any executable with symbols information into GDB
2) pass command --break-insert "C:/folder/file.cpp"

expected error: No source file named C:/folder/file.cpp
real error: No source file named C