bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21572: Fwd: bug#21572: 24.5; Gud gdb doesn't load source files with


From: Eli Zaretskii
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

> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]