bug#21572: 24.5; Gud gdb doesn't load source files with utf-8 chars in the file name

bug#21572: 24.5; Gud gdb doesn't load source files with utf-8 chars in the file name

[Augusto Fraga Giachero]

I'm having problems when trying to debug a program with gdb. The GUD
doesn't load the source files if they have any utf-8 character in their
names. I know that gdb replaces utf-8 characters with backslash and
their corresponding octal value, it seems that GUD isn't parsing these
octal sequences.

Here is an part of my gdb-source-file-list:

(... "/home/augusto/Projetos/Eletr\303\264nica/ARM/IoControl/src/main.c"
...)

The correct path should be:
/home/augusto/Projetos/Eletrônica/ARM/IoControl/src/main.c

I think it's not hard to fix it, but my knowledge of lisp isn't that
great.




In GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6)
 of 2015-09-09 on foutrelis
Windowing system distributor `The X.Org Foundation', version 11.0.11702000
Configured using:
 `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
 --param=ssp-buffer-size=4' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

Important settings:
  value of $LANG: pt_BR.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  global-company-mode: t
  company-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  display-time-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-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

Recent messages:
[yas] Loading for `emacs-lisp-mode', just-in-time: (lambda nil (yas--load-directory-1 (quote /home/augusto/.emacs.d/elpa/yasnippet-20150811.1222/snippets/emacs-lisp-mode) (quote emacs-lisp-mode)))!
[yas] Loading compiled snippets from /home/augusto/.emacs.d/elpa/yasnippet-20150811.1222/snippets/emacs-lisp-mode
[yas] Loading for `prog-mode', just-in-time: (lambda nil (yas--load-directory-1 (quote /home/augusto/.emacs.d/elpa/yasnippet-20150811.1222/snippets/prog-mode) (quote prog-mode)))!
[yas] Loading compiled snippets from /home/augusto/.emacs.d/elpa/yasnippet-20150811.1222/snippets/prog-mode
Loading /home/augusto/.emacs.d/elpa/yasnippet-20150811.1222/snippets/prog-mode/.yas-setup...done
For information about GNU Emacs and the GNU system, type C-h C-a.
*message*-20150927-113643 has auto save data; consider M-x recover-this-file
Beginning of buffer
Mark set [2 times]
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message idna cl-macs
format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils company-files company-oddmuse
company-keywords company-etags etags ring company-gtags
company-dabbrev-code company-dabbrev company-capf company-cmake
company-xcode company-clang company-semantic company-eclim
company-template company-css company-nxml company-bbdb company-irony
irony-completion irony-snippet irony find-func company waher-theme ido
cl-extra yasnippet help-mode cl gv linum-relative advice help-fns linum
picasm picasm-loops picasm-external edmacro kmacro cl-loaddefs cl-lib
info easymenu tex-site package epg-config time time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer 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 make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 154849 3972)
 (symbols 48 24539 0)
 (miscs 40 103 151)
 (strings 32 37552 10436)
 (string-bytes 1 932429)
 (vectors 16 17551)
 (vector-slots 8 519725 3706)
 (floats 8 406 239)
 (intervals 56 257 0)
 (buffers 960 15)
 (heap 1024 34440 1713))

bug#21572: 24.5; Gud gdb doesn't load source files with utf-8 chars in the file name

[Eli Zaretskii]

> From: Augusto Fraga Giachero <augustofg96@gmail.com>
> Date: Sun, 27 Sep 2015 12:26:55 -0300
> 
> I'm having problems when trying to debug a program with gdb. The GUD
> doesn't load the source files if they have any utf-8 character in their
> names. I know that gdb replaces utf-8 characters with backslash and
> their corresponding octal value, it seems that GUD isn't parsing these
> octal sequences.

They are just ASCII characters, so GUD had no reason to parse them.

> Here is an part of my gdb-source-file-list:
> 
> (... "/home/augusto/Projetos/Eletr\303\264nica/ARM/IoControl/src/main.c"
> ...)
> 
> The correct path should be:
> /home/augusto/Projetos/Eletrônica/ARM/IoControl/src/main.c
> 
> I think it's not hard to fix it

Actually, it's not very simple.  GDB outputs octal escapes in every
string, not just in file names, so decoding should be done on a very
low level, where we don't yet know what is a file name and what is
some other string (like a value of some string variable).  We can
decode that if we assume that all the strings output by GDB are
encoded the same (in your case, probably UTF-8), and keeping fingers
crossed that the communications channel between GBD and Emacs never
breaks the 3-digit sequence due to buffering issues.

I have a prototype fix along the above-mentioned lines which I will
commit soon, unless someone has a better idea.  You could then patch
your gdb-mi.el and use it with those source files.

Alternatively, you can invoke GDB via "M-x gud-gdb RET", which doesn't
have this problem in the first place.

Thanks.

bug#21572: Fwd: bug#21572: 24.5; Gud gdb doesn't load source files with utf-8 chars in the file name

[Augusto Fraga]

> From: Eli Zaretskii <eliz <at> gnu.org>
> Date: Wed, 30 Sep 2015 20:52:24 +0300
>
> Actually, it's not very simple.  GDB outputs octal escapes in every
> string, not just in file names, so decoding should be done on a very
> low level, where we don't yet know what is a file name and what is
> some other string (like a value of some string variable).

The only string that needs to be converted back to UTF-8 is the
sources file names string (couldn't it be done by hacking the
gdb-get-source-file-list function?).

> We can decode that if we assume that all the strings output by GDB are
> encoded the same (in your case, probably UTF-8), and keeping fingers
> crossed that the communications channel between GBD and Emacs never
> breaks the 3-digit sequence due to buffering issues.

I think that would be a nice option if gdb had a flag to disable these
octal sequences for the mi protocol. It would make everything easier.

> I have a prototype fix along the above-mentioned lines which I will
> commit soon, unless someone has a better idea.  You could then patch
> your gdb-mi.el and use it with those source files.

Nice! I'll try it out when you commit.

> Alternatively, you can invoke GDB via "M-x gud-gdb RET", which doesn't
> have this problem in the first place.

Well, but I wouldn't have a good source debugging interface. In fact
the "M-x gdb RET" doesn't fails, it only doesn't load the buffer for
the source code (it behaves like standard gdb without tui).

Thank you!

bug#21572: Fwd: bug#21572: 24.5; Gud gdb doesn't load source files with utf-8 chars in the file name

[Eli Zaretskii]

> Date: Wed, 30 Sep 2015 21:37:33 -0300
> From: Augusto Fraga <augustofg96@gmail.com>
> 
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > Date: Wed, 30 Sep 2015 20:52:24 +0300
> >
> > Actually, it's not very simple.  GDB outputs octal escapes in every
> > string, not just in file names, so decoding should be done on a very
> > low level, where we don't yet know what is a file name and what is
> > some other string (like a value of some string variable).
> 
> The only string that needs to be converted back to UTF-8 is the
> sources file names string

For your use case, yes.  But if your program manipulates non-ASCII
text in its strings (like non-ASCII file names it creates), you will
see the same problem with them.  Why should they be treated any
different?

> (couldn't it be done by hacking the gdb-get-source-file-list
> function?).

No, because the source file names arrive through other ways as well,
notably when GDB reports a breakpoint being hit.

I actually started with gdb-get-source-file-list, but this wasn't
enough to automatically pop up the source when the program is started.

> > We can decode that if we assume that all the strings output by GDB are
> > encoded the same (in your case, probably UTF-8), and keeping fingers
> > crossed that the communications channel between GBD and Emacs never
> > breaks the 3-digit sequence due to buffering issues.
> 
> I think that would be a nice option if gdb had a flag to disable these
> octal sequences for the mi protocol. It would make everything easier.

I agree.  But if this will happen (and I hope it will; I'm talking to
GDB developers about that), Emacs users will not be able to take
advantage of that until their sysadmins upgrade to that newer version
of GDB.  So it makes sense to provide a solution now, with the
existing GDB versions.

> > I have a prototype fix along the above-mentioned lines which I will
> > commit soon, unless someone has a better idea.  You could then patch
> > your gdb-mi.el and use it with those source files.
> 
> Nice! I'll try it out when you commit.

You can do that now, see commits 439f483 and 9c86325.

Note that this decoding is by default turned off, for the reasons I
explained in the doc string of gdb-mi-decode-strings option and in the
comments to the gdb-mi-decode function.  Set it to t to see the
feature at work.

bug#21572: Fwd: bug#21572: 24.5; Gud gdb doesn't load source files with utf-8 chars in the file name

[Augusto Fraga Giachero]

> From: Eli Zaretskii <eliz <at> gnu.org>
> Date: Thu, 01 Oct 2015 15:14:57 +0300
>
> You can do that now, see commits 439f483 and 9c86325.
>
> Note that this decoding is by default turned off, for the reasons I
> explained in the doc string of gdb-mi-decode-strings option and in the
> comments to the gdb-mi-decode function.  Set it to t to see the
> feature at work.

Thank you! I've tried and it worked well!

It is a nice short-time fix until gdb support turning off octal
conversion for non-ASCII strings.

bug#21572: 24.5; Gud gdb doesn't load source files with utf-8 chars in the file name

[Eli Zaretskii]

> Date: Wed, 30 Sep 2015 20:52:24 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 21572@debbugs.gnu.org
> 
> I have a prototype fix along the above-mentioned lines which I will
> commit soon, unless someone has a better idea.  You could then patch
> your gdb-mi.el and use it with those source files.

I've pushed those changes now, and I'm marking this bug done.

Thanks.