GNU bug report logs - #51894
27.2; GDB Gud support on Cygwin has trouble accessing shared files on Windows network drives.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51894 in the body.
You can then email your comments to 51894 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Guy Offer <guyof <at> checkpoint.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 27.2; GDB Gud support on Cygwin has trouble accessing shared files on
 Windows network drives.
Date: Tue, 16 Nov 2021 09:22:26 +0000

[Message part 1 (text/plain, inline)]

--text follows this line--

Working on Cygwin Emacs when source code is located on Windows 10
network drives (e.g. Windows F: drive points to \\fileserver\soruce) and accessed
by gdb using \cygdrive\f\source\.. the Emacs gdb support cannot find the
file.
File can only be find by the Emacs GDB support if the source path begins with
double slash (e.g,, \\cygdrive\f\source\...).  However in this case it
cannot be found by the gud gdb window.
To overcome this source mounts should be done directly from the Cygwin (using mount) and not
through the Windows 10 drives (\cygdrive\...).


In GNU Emacs 27.2 (build 1, x86_64-pc-cygwin, X toolkit, Xaw3d scroll bars)
of 2021-03-26 built on moufang2
Repository revision: 5a2c58d08c59ce5a7afb6511cc99f722f426c12b
Repository branch: master
Windowing system distributor 'The Cygwin/X Project', version 11.0.12012000
Recent messages:
(No changes need to be saved)
elisp--preceding-sexp: End of file during parsing
Saving file /cygdrive/c/Temp/cmd3...
Wrote /cygdrive/c/Temp/cmd3
(No changes need to be saved) [3 times]
Undefined command: "exit".  Try "help".
Switched to thread 1
Mark set
Target doesn't support non-stop mode.  Turning it off.
Mark set [8 times]

Configured using:
'configure
--srcdir=/home/kbrown/src/cygpackages/emacs/emacs-27.2-1.x86_64/src/emacs-27.2
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/emacs --htmldir=/usr/share/doc/emacs/html -C
--with-x-toolkit=lucid 'CFLAGS=-ggdb -O2 -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-fstack-protector-strong --param=ssp-buffer-size=4
-fdebug-prefix-map=/home/kbrown/src/cygpackages/emacs/emacs-27.2-1.x86_64/build=/usr/src/debug/emacs-27.2-1
-fdebug-prefix-map=/home/kbrown/src/cygpackages/emacs/emacs-27.2-1.x86_64/src/emacs-27.2=/usr/src/debug/emacs-27.2-1'
CPPFLAGS= LDFLAGS='

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GSETTINGS GLIB NOTIFY
GFILENOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT
ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS JSON PDUMPER
LCMS2 GMP

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Debugger

Minor modes in effect:
  gud-tooltip-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  tab-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
 line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired dired-loaddefs format-spec
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs text-property-search mailabbrev gmm-utils mailheader
sendmail mail-utils help-fns radix-tree cl-print debug backtrace
help-mode mule-util jka-compr info vc-git cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs which-func
imenu vc vc-dispatcher tempo srecode soap-client mm-decode mm-bodies
mm-encode url-http url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr url-gw nsm rmc puny url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
url-parse auth-source url-vars mailcap rng-xsd rng-dt rng-util
xsd-regexp xml smerge-mode sieve sieve-mode sieve-manage sasl
sasl-anonymous sasl-login sasl-plain password-cache pcvs-defs pcvs-util
grep glasses gdb-mi bindat json map gud flymake-proc flymake warnings
thingatpt etags fileloop generator xref project emerge elide-head ediff
ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init
ediff-util ede/project-am ede/autoconf-edit autoconf autoconf-mode
semantic/find ede/makefile-edit make-mode ede/linux semantic/db
semantic/util-modes semantic/util semantic pp semantic/tag semantic/lex
semantic/fw mode-local find-func ede/make ede/speedbar ede/files ede
ede/detect ede/base ede/auto ede/source eieio-base seq eieio-speedbar
speedbar sb-image ezimage dframe eieio-custom cl-seq eieio byte-opt
bytecomp byte-compile cconv eieio-core cl-macs gv eieio-loaddefs cedet
ebrowse ebuff-menu view diff copyright compile comint ansi-color ring
compare-w diff-mode easy-mmode check-declare calculator edmacro kmacro
add-log time-date subr-x cus-edit easymenu cus-start cus-load wid-edit
cl-loaddefs cl-lib advice tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
threads dbusbind gfilenotify lcms2 dynamic-setting system-font-setting
font-render-setting x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 246697 30355)
(symbols 48 21407 1)
(strings 32 65711 3822)
(string-bytes 1 2120737)
(vectors 16 37254)
(vector-slots 8 481354 23754)
(floats 8 118 220)
(intervals 56 3551 198)
(buffers 1000 37))

[Message part 2 (text/html, inline)]

Message #8 received at 51894 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Guy Offer <guyof <at> checkpoint.com>
Cc: 51894 <at> debbugs.gnu.org
Subject: Re: bug#51894: 27.2;
 GDB Gud support on Cygwin has trouble accessing shared files on
 Windows network drives.
Date: Tue, 16 Nov 2021 17:16:53 +0200

> Date: Tue, 16 Nov 2021 09:22:26 +0000
> From:  Guy Offer via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Working on Cygwin Emacs when source code is located on Windows 10
> network drives (e.g. Windows F: drive points to \\fileserver\soruce) and accessed
> by gdb using \cygdrive\f\source\.. the Emacs gdb support cannot find the
> file.
> 
> File can only be find by the Emacs GDB support if the source path begins with
> double slash (e.g,, \\cygdrive\f\source\...).  However in this case it
> cannot be found by the gud gdb window.
> To overcome this source mounts should be done directly from the Cygwin (using mount) and not
> through the Windows 10 drives (\cygdrive\...). 

Please show what does the GDB you are using display when you type
this:

  $ gdb --config

Also, when you say "the Emacs gdb support cannot find the file", what
do you mean by "Emacs gdb support"?

Thanks.

Message #13 received at 51894 <at> debbugs.gnu.org (full text, mbox):

From: Guy Offer <guyof <at> checkpoint.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "51894 <at> debbugs.gnu.org" <51894 <at> debbugs.gnu.org>
Subject: RE: bug#51894: 27.2; GDB Gud support on Cygwin has trouble accessing
 shared files on Windows network drives.
Date: Wed, 17 Nov 2021 14:00:39 +0000

This GDB was configured as follows:
   configure --host=x86_64-pc-cygwin --target=x86_64-redhat-linux-gnu
             --with-auto-load-dir=$debugdir:$datadir/auto-load
             --with-auto-load-safe-path=$debugdir:$datadir/auto-load
             --with-expat
             --with-gdb-datadir=/usr/local/share/gdb (relocatable)
             --with-jit-reader-dir=/usr/local/lib/gdb (relocatable)
             --without-libunwind-ia64
             --without-lzma
             --without-babeltrace
             --without-intel-pt
             --without-mpfr
             --without-xxhash
             --without-python
             --without-python-libdir
             --without-debuginfod
             --without-guile
             --disable-source-highlight
             --with-separate-debug-dir=/usr/local/lib/debug (relocatable)

Regarding Emacs GDB support: Emacs has UI support for GDB (GUD GDB) which can display code source in Emacs buffers. 


("Relocatable" means the directory can be moved with the GDB installation
tree, and GDB will still find it.)
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org] 
Sent: Tuesday, 16 November 2021 17:17
To: Guy Offer <guyof <at> checkpoint.com>
Cc: 51894 <at> debbugs.gnu.org
Subject: Re: bug#51894: 27.2; GDB Gud support on Cygwin has trouble accessing shared files on Windows network drives.

> Date: Tue, 16 Nov 2021 09:22:26 +0000
> From:  Guy Offer via "Bug reports for GNU Emacs,  the Swiss army knife 
> of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Working on Cygwin Emacs when source code is located on Windows 10 
> network drives (e.g. Windows F: drive points to \\fileserver\soruce) 
> and accessed by gdb using \cygdrive\f\source\.. the Emacs gdb support 
> cannot find the file.
> 
> File can only be find by the Emacs GDB support if the source path 
> begins with double slash (e.g,, \\cygdrive\f\source\...).  However in 
> this case it cannot be found by the gud gdb window.
> To overcome this source mounts should be done directly from the Cygwin 
> (using mount) and not through the Windows 10 drives (\cygdrive\...).

Please show what does the GDB you are using display when you type
this:

  $ gdb --config

Also, when you say "the Emacs gdb support cannot find the file", what do you mean by "Emacs gdb support"?

Thanks.


Secured by Check Point


________________________________

Report suspicious email
<https://mta-cnf.iaas.checkpoint.com/cmta_feedback_request?id=MjUwOTM4ZGY3NWQyYWVjNjZhMjc0YmQ1OGZlYTMzYzNlZTg2ODdhN2NmZTJmODRlZjJkMWEwY2FjNDNhYzIzMA==&t=YWI5ZjBkMjktYmI3Yy00OGI2LWIzYTMtODA0NTRmY2NjODNm>
________________________________

Message #16 received at 51894 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Guy Offer <guyof <at> checkpoint.com>
Cc: 51894 <at> debbugs.gnu.org
Subject: Re: bug#51894: 27.2; GDB Gud support on Cygwin has trouble accessing
 shared files on Windows network drives.
Date: Wed, 17 Nov 2021 16:27:41 +0200

> From: Guy Offer <guyof <at> checkpoint.com>
> CC: "51894 <at> debbugs.gnu.org" <51894 <at> debbugs.gnu.org>
> Date: Wed, 17 Nov 2021 14:00:39 +0000
> 
> This GDB was configured as follows:
>    configure --host=x86_64-pc-cygwin --target=x86_64-redhat-linux-gnu

Does this mean this is a GDB that targets Red Hat GNU/Linux and not a
Cygwin-native debugger?

> Regarding Emacs GDB support: Emacs has UI support for GDB (GUD GDB) which can display code source in Emacs buffers. 

Are you using "M-x gdb RET" or "M-x gud-gdb RET"?

Also, is Emacs capable of visiting file specified as
"\cygdrive\f\source\", i.e. does "C-x C-f" work with such names?

And btw, why you mention file names with backslashes? does using
forward slashes, as in "/cygdrive/f/source/", work for you?

If all of the above doesn't help, please show a minimal recipe
starting from "emacs -Q", where the problem happens: maybe we are
missing some important clue.

Message #19 received at 51894 <at> debbugs.gnu.org (full text, mbox):

From: Guy Offer <guyof <at> checkpoint.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "51894 <at> debbugs.gnu.org" <51894 <at> debbugs.gnu.org>
Subject: RE: bug#51894: 27.2; GDB Gud support on Cygwin has trouble accessing
 shared files on Windows network drives.
Date: Wed, 17 Nov 2021 15:01:09 +0000

-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org] 
Sent: Wednesday, 17 November 2021 16:28
To: Guy Offer <guyof <at> checkpoint.com>
Cc: 51894 <at> debbugs.gnu.org
Subject: Re: bug#51894: 27.2; GDB Gud support on Cygwin has trouble accessing shared files on Windows network drives.

> From: Guy Offer <guyof <at> checkpoint.com>
> CC: "51894 <at> debbugs.gnu.org" <51894 <at> debbugs.gnu.org>
> Date: Wed, 17 Nov 2021 14:00:39 +0000
> 
> This GDB was configured as follows:
>    configure --host=x86_64-pc-cygwin --target=x86_64-redhat-linux-gnu

Does this mean this is a GDB that targets Red Hat GNU/Linux and not a Cygwin-native debugger? yes

> Regarding Emacs GDB support: Emacs has UI support for GDB (GUD GDB) which can display code source in Emacs buffers. 

Are you using "M-x gdb RET" or "M-x gud-gdb RET"? M-x gdb RET

Also, is Emacs capable of visiting file specified as "\cygdrive\f\source\", i.e. does "C-x C-f" work with such names? Emacs can do that if I load the file manually.  However, when emacs tries to open the file as received from gdb (to display the source) it fails.  It only succeeds if I set the pathname to \\cygdrive\f\source.  However in that case the gdb command window cannot access the file. 
Pls note that this happens only if f is a network drive .



And btw, why you mention file names with backslashes? does using forward slashes, as in "/cygdrive/f/source/", work for you?
Sorry for the confusion in the bug report - I used only slashes .  
/cygdrive/f/source - worked for accessing source from the gdb command window (GUD gdb window) but not for opening the source from the GDB buffer.
//cygdrive/f/source - worked for opening the source in a GDB buffer but not for accessing the source from the gdb command window. 
This happened when f points to a remote network drive. 

If all of the above doesn't help, please show a minimal recipe starting from "emacs -Q", where the problem happens: maybe we are missing some important clue.


Secured by Check Point


________________________________

Report suspicious email
<https://mta-cnf.iaas.checkpoint.com/cmta_feedback_request?id=Zjc2OTQzNzJiMzdjZDFjMTk0ZWYyOTA0NTZmM2Y2NmMwOTZmYzNmOTVkMjM3NzhmYTMxYmVmZTlkZmRhNWNkMA==&t=YWI5ZjBkMjktYmI3Yy00OGI2LWIzYTMtODA0NTRmY2NjODNm>
________________________________

Message #22 received at 51894 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Guy Offer <guyof <at> checkpoint.com>, Ken Brown <kbrown <at> cornell.edu>
Cc: 51894 <at> debbugs.gnu.org
Subject: Re: bug#51894: 27.2; GDB Gud support on Cygwin has trouble accessing
 shared files on Windows network drives.
Date: Wed, 17 Nov 2021 19:03:28 +0200

> From: Guy Offer <guyof <at> checkpoint.com>
> CC: "51894 <at> debbugs.gnu.org" <51894 <at> debbugs.gnu.org>
> Date: Wed, 17 Nov 2021 15:01:09 +0000
> 
> Also, is Emacs capable of visiting file specified as "\cygdrive\f\source\", i.e. does "C-x C-f" work with such names? Emacs can do that if I load the file manually.  However, when emacs tries to open the file as received from gdb (to display the source) it fails.  It only succeeds if I set the pathname to \\cygdrive\f\source.  However in that case the gdb command window cannot access the file. 

Please show the Emacs commands and GDB commands you use in these two
cases.  I'm not sure I understand what you mean by "load file
manually" and "open a file received from gdb"

> Pls note that this happens only if f is a network drive .

So maybe it's a Cygwin-specific problem with networked drives?  I'll
CC Ken Brown, who is our Cygwin specialist.  Ken, does this ring a
bell? does /cygdrive/x/ fail when X is a networked drive?

Or maybe the way your networked drives are mounted prevents Emacs from
accessing them due to some authentication issue?

Message #25 received at 51894 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Guy Offer <guyof <at> checkpoint.com>
Cc: 51894 <at> debbugs.gnu.org
Subject: Re: bug#51894: 27.2; GDB Gud support on Cygwin has trouble accessing
 shared files on Windows network drives.
Date: Wed, 17 Nov 2021 12:40:39 -0500

On 11/17/2021 12:03 PM, Eli Zaretskii wrote:
>> From: Guy Offer <guyof <at> checkpoint.com>
>> CC: "51894 <at> debbugs.gnu.org" <51894 <at> debbugs.gnu.org>
>> Date: Wed, 17 Nov 2021 15:01:09 +0000
>> Pls note that this happens only if f is a network drive .
> 
> So maybe it's a Cygwin-specific problem with networked drives?  I'll
> CC Ken Brown, who is our Cygwin specialist.  Ken, does this ring a
> bell? does /cygdrive/x/ fail when X is a networked drive?

I'm not aware of any such problem.  I never use networked drives myself, but if 
Guy can tell me exactly how he created his, I'll see if I can reproduce the problem.

Ken

Message #28 received at 51894 <at> debbugs.gnu.org (full text, mbox):

From: Guy Offer <guyof <at> checkpoint.com>
To: Ken Brown <kbrown <at> cornell.edu>, Eli Zaretskii <eliz <at> gnu.org>
Cc: "51894 <at> debbugs.gnu.org" <51894 <at> debbugs.gnu.org>
Subject: RE: bug#51894: 27.2; GDB Gud support on Cygwin has trouble accessing
 shared files on Windows network drives.
Date: Thu, 18 Nov 2021 07:53:37 +0000

Hi, 

Steps to set up this configuration:

Background: 
When working on gdb from Emacs you can see the source code from 2 Emacs windows/buffers:
- the gdb command window: the gdb prompt that displays the current source code line.
- the primary source window: an Emacs window that automatically opened and displays the source file with an arrow pointing on the current line being processed.
The problem is that when the source code is on network drive mounted through Windows 10 drives (F:, G:, etc.) it will not be available to one of these windows. 

Working machine : Windows 10

* Have the source pointed by a network drive (e.g. F:/source, etc.).
* Install Cygwin on the local machine: (including make, X11, GNU Emacs 27.2, gcc, packages etc.). 
* Download and compile gdb 11.1 (I had to compile myself to work with linux target and build x86_64-redhat-linux-gnu-gdb).
* Activate gdb from emacs by : Alt-x, gdb, gdb -i=mi etc.

Now you see the problems:
* If you set the code path (set substitute-path) to the actual code location /cygdrive/f/source the code will be available to the gdb command window but will not be opened automatically in the primary source window/buffer. 
* If you set the code location to //cygdrive/f/source the code will be available to the source window - but not to the gdb command window. 

Possible solution - mounting the source code through Cygwin /mnt. 

Another problem : when the source is not available the Emacs command prompt get into a loop.

Thanks,
Guy


-----Original Message-----
From: Ken Brown [mailto:kbrown <at> cornell.edu] 
Sent: Wednesday, 17 November 2021 19:41
To: Eli Zaretskii <eliz <at> gnu.org>; Guy Offer <guyof <at> checkpoint.com>
Cc: 51894 <at> debbugs.gnu.org
Subject: Re: bug#51894: 27.2; GDB Gud support on Cygwin has trouble accessing shared files on Windows network drives.

On 11/17/2021 12:03 PM, Eli Zaretskii wrote:
>> From: Guy Offer <guyof <at> checkpoint.com>
>> CC: "51894 <at> debbugs.gnu.org" <51894 <at> debbugs.gnu.org>
>> Date: Wed, 17 Nov 2021 15:01:09 +0000 Pls note that this happens only 
>> if f is a network drive .
> 
> So maybe it's a Cygwin-specific problem with networked drives?  I'll 
> CC Ken Brown, who is our Cygwin specialist.  Ken, does this ring a 
> bell? does /cygdrive/x/ fail when X is a networked drive?

I'm not aware of any such problem.  I never use networked drives myself, but if Guy can tell me exactly how he created his, I'll see if I can reproduce the problem.

Ken


Secured by Check Point


________________________________

Report suspicious email
<https://mta-cnf.iaas.checkpoint.com/cmta_feedback_request?id=YmQwMzY5YWNmYTQxMTk1MjBlM2NhOThmYTdjN2ZjNWRiMmQ0OGU3ZWIwNGVhOTlmNGM3Zjk1YTFmYjJhZWNiNQ==&t=YWI5ZjBkMjktYmI3Yy00OGI2LWIzYTMtODA0NTRmY2NjODNm>
________________________________

Message #31 received at 51894 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Guy Offer <guyof <at> checkpoint.com>
Cc: 51894 <at> debbugs.gnu.org, kbrown <at> cornell.edu
Subject: Re: bug#51894: 27.2; GDB Gud support on Cygwin has trouble accessing
 shared files on Windows network drives.
Date: Thu, 18 Nov 2021 10:40:35 +0200

> From: Guy Offer <guyof <at> checkpoint.com>
> CC: "51894 <at> debbugs.gnu.org" <51894 <at> debbugs.gnu.org>
> Date: Thu, 18 Nov 2021 07:53:37 +0000
> 
> * If you set the code path (set substitute-path) to the actual code location /cygdrive/f/source the code will be available to the gdb command window but will not be opened automatically in the primary source window/buffer. 
> * If you set the code location to //cygdrive/f/source the code will be available to the source window - but not to the gdb command window. 

Why is "set substitute-path" command needed?  The program you are
debugging should have the source location recorded in the debug info,
so that step should not be needed.

I'm asking because perhaps this step is an important part of the
problem.

Also, can you try "M-x gud-gdb RET" instead, and see if the problem
exists there as well?  Maybe there's something in gdb-mi.el that
doesn't work well in this case, in particular when it parses the file
names reported by GDB's MI interface.  For that reason, I'd be
interested to see the raw data about source file names emitted by GDB
in response to Emacs's queries.  For that purpose, activate the
gdb-enable-debug minor mode, and show the contents of the variable
gdb-debug-log after a command that results in such failures.

> Another problem : when the source is not available the Emacs command prompt get into a loop.

I believe that was fixed in Emacs 28.

Message #34 received at 51894 <at> debbugs.gnu.org (full text, mbox):

From: Guy Offer <guyof <at> checkpoint.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "51894 <at> debbugs.gnu.org" <51894 <at> debbugs.gnu.org>,
 "kbrown <at> cornell.edu" <kbrown <at> cornell.edu>
Subject: RE: bug#51894: 27.2; GDB Gud support on Cygwin has trouble accessing
 shared files on Windows network drives.
Date: Thu, 18 Nov 2021 08:54:22 +0000

-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org] 
Sent: Thursday, 18 November 2021 10:41
To: Guy Offer <guyof <at> checkpoint.com>
Cc: kbrown <at> cornell.edu; 51894 <at> debbugs.gnu.org
Subject: Re: bug#51894: 27.2; GDB Gud support on Cygwin has trouble accessing shared files on Windows network drives.

> From: Guy Offer <guyof <at> checkpoint.com>
> CC: "51894 <at> debbugs.gnu.org" <51894 <at> debbugs.gnu.org>
> Date: Thu, 18 Nov 2021 07:53:37 +0000
> 
> * If you set the code path (set substitute-path) to the actual code location /cygdrive/f/source the code will be available to the gdb command window but will not be opened automatically in the primary source window/buffer. 
> * If you set the code location to //cygdrive/f/source the code will be available to the source window - but not to the gdb command window. 

Why is "set substitute-path" command needed?  The program you are debugging should have the source location recorded in the debug info, so that step should not be needed.


I'm asking because perhaps this step is an important part of the problem.
===>
	It was compiled on a different location. 
	I had the same problem occurring when using the "directory" command (adding a directory to the source search path) as well.


Also, can you try "M-x gud-gdb RET" instead, and see if the problem exists there as well?  Maybe there's something in gdb-mi.el that doesn't work well in this case, in particular when it parses the file names reported by GDB's MI interface.  For that reason, I'd be interested to see the raw data about source file names emitted by GDB in response to Emacs's queries.  For that purpose, activate the gdb-enable-debug minor mode, and show the contents of the variable gdb-debug-log after a command that results in such failures.

=====> The gud-gdb does not have the IDE support (it only runs the gdb on a single window without opening the source files, stack or variable windows).

> Another problem : when the source is not available the Emacs command prompt get into a loop.

I believe that was fixed in Emacs 28.


Secured by Check Point


________________________________

Report suspicious email
<https://mta-cnf.iaas.checkpoint.com/cmta_feedback_request?id=OTNmODc4NjYzMTE2NzlhOTZkNmI2NGQ4ZjI2MmY4ZjI2NDhhMDc4OTcyNmZkYjFmYzI0ZjMwNThiZTM5OGMyMA==&t=YWI5ZjBkMjktYmI3Yy00OGI2LWIzYTMtODA0NTRmY2NjODNm>
________________________________

Message #37 received at 51894 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Guy Offer <guyof <at> checkpoint.com>
Cc: 51894 <at> debbugs.gnu.org, kbrown <at> cornell.edu
Subject: Re: bug#51894: 27.2; GDB Gud support on Cygwin has trouble accessing
 shared files on Windows network drives.
Date: Thu, 18 Nov 2021 13:02:52 +0200

> From: Guy Offer <guyof <at> checkpoint.com>
> CC: "kbrown <at> cornell.edu" <kbrown <at> cornell.edu>,
>         "51894 <at> debbugs.gnu.org"
> 	<51894 <at> debbugs.gnu.org>
> Date: Thu, 18 Nov 2021 08:54:22 +0000
> 
> Also, can you try "M-x gud-gdb RET" instead, and see if the problem exists there as well?  Maybe there's something in gdb-mi.el that doesn't work well in this case, in particular when it parses the file names reported by GDB's MI interface.  For that reason, I'd be interested to see the raw data about source file names emitted by GDB in response to Emacs's queries.  For that purpose, activate the gdb-enable-debug minor mode, and show the contents of the variable gdb-debug-log after a command that results in such failures.
> 
> =====> The gud-gdb does not have the IDE support (it only runs the gdb on a single window without opening the source files, stack or variable windows).

That's not entirely true: it does open a window with the source file.

Anyway I'm not saying you should use "M-x gud-gdb" instead of "M-x
gdb", I'm asking you to try gud-gdb just this once to see if it is
capable of resolving these file names.  Could you please try that and
report the results?  Knowing that could give some hint about where to
look for the reasons of your original problem.

Thanks.

Message #40 received at 51894 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Guy Offer <guyof <at> checkpoint.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: "51894 <at> debbugs.gnu.org" <51894 <at> debbugs.gnu.org>
Subject: Re: bug#51894: 27.2; GDB Gud support on Cygwin has trouble accessing
 shared files on Windows network drives.
Date: Thu, 18 Nov 2021 09:17:58 -0500

On 11/18/2021 2:53 AM, Guy Offer wrote:
> * Have the source pointed by a network drive (e.g. F:/source, etc.).
> * Install Cygwin on the local machine: (including make, X11, GNU Emacs 27.2, gcc, packages etc.).
> * Download and compile gdb 11.1 (I had to compile myself to work with linux target and build x86_64-redhat-linux-gnu-gdb).
> * Activate gdb from emacs by : Alt-x, gdb, gdb -i=mi etc.

I don't have time to try to replicate this setup, nor do I have a Linux machine 
on my network.  But I did map a network drive and verify that there was no 
problem accessing it via the cygdrive prefix (e.g., 'ls /cygdrive/x' succeeds 
after X: is mapped to a folder that I can access on a networked Windows 
machine).  This answers a question that Eli asked earlier.

Ken

Message #43 received at 51894 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: guyof <at> checkpoint.com, 51894 <at> debbugs.gnu.org
Subject: Re: bug#51894: 27.2; GDB Gud support on Cygwin has trouble accessing
 shared files on Windows network drives.
Date: Thu, 18 Nov 2021 16:58:45 +0200

> Date: Thu, 18 Nov 2021 09:17:58 -0500
> Cc: "51894 <at> debbugs.gnu.org" <51894 <at> debbugs.gnu.org>
> From: Ken Brown <kbrown <at> cornell.edu>
> 
> I don't have time to try to replicate this setup, nor do I have a Linux machine 
> on my network.  But I did map a network drive and verify that there was no 
> problem accessing it via the cygdrive prefix (e.g., 'ls /cygdrive/x' succeeds 
> after X: is mapped to a folder that I can access on a networked Windows 
> machine).  This answers a question that Eli asked earlier.

Thanks.  So some other factor must be at work here.  I think the
solution of the riddle is somewhere in what GDB/MI returns to Emacs in
response to its requests, which is why I asked for gdb-debug-log
contents.

Message #46 received at 51894 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: guyof <at> checkpoint.com, 51894 <at> debbugs.gnu.org
Subject: Re: bug#51894: 27.2; GDB Gud support on Cygwin has trouble accessing
 shared files on Windows network drives.
Date: Thu, 18 Nov 2021 15:15:41 -0500

On 11/18/2021 9:58 AM, Eli Zaretskii wrote:
> Thanks.  So some other factor must be at work here.  I think the
> solution of the riddle is somewhere in what GDB/MI returns to Emacs in
> response to its requests, which is why I asked for gdb-debug-log
> contents.

One other thing that could be relevant is that Guy is using a self-built gdb 
11.1, based presumably on the upstream sources.  Cygwin's gdb is at version 
10.2, and the maintainer has applied 9 patches to the upstream sources.

Guy, maybe you should try imitating the build of Cygwin's gdb-10.2 package.

Ken

Message #49 received at 51894 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: guyof <at> checkpoint.com, Eli Zaretskii <eliz <at> gnu.org>, 51894 <at> debbugs.gnu.org
Subject: Re: bug#51894: 27.2; GDB Gud support on Cygwin has trouble
 accessing shared files on Windows network drives.
Date: Thu, 23 Dec 2021 11:22:13 +0100

Ken Brown <kbrown <at> cornell.edu> writes:

>> Thanks.  So some other factor must be at work here.  I think the
>> solution of the riddle is somewhere in what GDB/MI returns to Emacs in
>> response to its requests, which is why I asked for gdb-debug-log
>> contents.
>
> One other thing that could be relevant is that Guy is using a
> self-built gdb 11.1, based presumably on the upstream sources.
> Cygwin's gdb is at version 10.2, and the maintainer has applied 9
> patches to the upstream sources.
>
> Guy, maybe you should try imitating the build of Cygwin's gdb-10.2 package.

Skimming this thread, I'm not sure there's anything actionable here --
the problems seem like they might be stemming from a self-built version
of gdb, which seems outside of the scope of the Emacs bug tracker.

So is there anything to do here on our side, or should this bug report
be closed?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #54 received at 51894-done <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: guyof <at> checkpoint.com, Eli Zaretskii <eliz <at> gnu.org>,
 51894-done <at> debbugs.gnu.org
Subject: Re: bug#51894: 27.2; GDB Gud support on Cygwin has trouble accessing
 shared files on Windows network drives.
Date: Thu, 23 Dec 2021 08:45:25 -0500

On 12/23/2021 5:22 AM, Lars Ingebrigtsen wrote:
> Ken Brown <kbrown <at> cornell.edu> writes:
> 
>>> Thanks.  So some other factor must be at work here.  I think the
>>> solution of the riddle is somewhere in what GDB/MI returns to Emacs in
>>> response to its requests, which is why I asked for gdb-debug-log
>>> contents.
>>
>> One other thing that could be relevant is that Guy is using a
>> self-built gdb 11.1, based presumably on the upstream sources.
>> Cygwin's gdb is at version 10.2, and the maintainer has applied 9
>> patches to the upstream sources.
>>
>> Guy, maybe you should try imitating the build of Cygwin's gdb-10.2 package.
> 
> Skimming this thread, I'm not sure there's anything actionable here --
> the problems seem like they might be stemming from a self-built version
> of gdb, which seems outside of the scope of the Emacs bug tracker.
> 
> So is there anything to do here on our side, or should this bug report
> be closed?

I think it should be closed (and I'm doing so).

Ken

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.