From: Eli Zaretskii <eliz@gnu.org>
To: Augusto Fraga <augustofg96@gmail.com>
Cc: 21572@debbugs.gnu.org
Subject: bug#21572: Fwd: bug#21572: 24.5; Gud gdb doesn't load source files with utf-8 chars in the file name
Date: Thu, 01 Oct 2015 15:14:57 +0300 [thread overview]
Message-ID: <83d1wyaipq.fsf@gnu.org> (raw)
In-Reply-To: <CAD1u=nMhGtGRRcwbmEKiRJFt9Vr=3LgfoQfN7LsdiNSF9ecJeQ@mail.gmail.com>
> 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.
next prev parent reply other threads:[~2015-10-01 12:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-27 15:26 bug#21572: 24.5; Gud gdb doesn't load source files with utf-8 chars in the file name Augusto Fraga Giachero
2015-09-30 17:52 ` Eli Zaretskii
[not found] ` <CAD1u=nOrGAjZ8Qpr2bt09h5PR-B_Wht_P7EUJdEdvDuXmtrR+Q@mail.gmail.com>
2015-10-01 0:37 ` bug#21572: Fwd: " Augusto Fraga
2015-10-01 12:14 ` Eli Zaretskii [this message]
2015-10-01 13:00 ` Augusto Fraga Giachero
2015-10-01 11:53 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83d1wyaipq.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=21572@debbugs.gnu.org \
--cc=augustofg96@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).