From: Pedro Alves <palves@redhat.com>
To: Eli Zaretskii <eliz@gnu.org>, gdb@sourceware.org
Subject: Re: GDB/MI reporting non-ASCII file names
Date: Wed, 30 Sep 2015 11:52:00 -0000 [thread overview]
Message-ID: <560BCCF9.2040202@redhat.com> (raw)
In-Reply-To: <83a8s5d1nw.fsf@gnu.org>
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
next prev parent reply other threads:[~2015-09-30 11:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-29 9:18 Eli Zaretskii
2015-09-30 11:52 ` Pedro Alves [this message]
2015-09-30 14:34 ` Eli Zaretskii
2015-09-30 14:49 ` Pedro Alves
2015-09-30 15:52 ` Eli Zaretskii
2015-10-09 11:12 ` Pedro Alves
2015-10-09 13:31 ` Eli Zaretskii
2015-10-09 16:48 ` Pedro Alves
2015-10-09 17:11 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=560BCCF9.2040202@redhat.com \
--to=palves@redhat.com \
--cc=eliz@gnu.org \
--cc=gdb@sourceware.org \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox