GDB/MI reporting non-ASCII file names
Pedro Alves
palves@redhat.com
Wed Sep 30 11:52:00 GMT 2015
On 09/29/2015 10:18 AM, Eli Zaretskii wrote:
> It seems that "gdb -i=mi" reports non-ASCII characters in filenames as
> octal escapes. Here's an example from a GNU/Linux system whose
> locale's codeset is UTF-8:
>
> (gdb)
> -file-list-exec-source-file
> ^done,line="1",file="/home/e/eliz/\320\277\321\200\320\276\320\262\320\265\321\200\320\272\320\260.c",fullname="/srv/data/home/e/eliz/\320\277\321\200\320\276\320\262\320\265\321\200\320\272\320\260.c",macro-info="1"
>
> Each of these \nnn is a string of literal ASCII characters, not a
> single byte whose octal value is nnn. Why does MI do this? Where in
> GDB do we convert bytes into this representation, and is there any way
> of asking MI not to make these conversions?
>
> The reason for these questions is that Emacs's GDB interface fails to
> recognize the original file name that hides behind these escapes, and
> the result is that debugging a program whose source file names include
> non-ASCII characters fails to display the source files through which
> GDB steps.
>
> It is, of course, possible to decode these escapes on Emacs's side.
> But since many MI output records include file-name fields, doing so
> everywhere is quite a PITA. So if there's a way to avoid the need for
> decoding in the first place, it's preferable.
I happened to stumble on this discussion yesterday:
https://www.sourceware.org/ml/gdb/2012-03/msg00001.html
Which points at:
https://sourceware.org/ml/gdb/2010-08/msg00129.html
Thanks,
Pedro Alves
More information about the Gdb
mailing list