GNU bug report logs - #44173
28.0.50; gdb-mi mangles strings with octal escapes

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44173 in the body.
You can then email your comments to 44173 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Fri, 23 Oct 2020 13:50:24 +0200

When GDB sends a string containing octally-escaped characters, it will be something like

 "abc\377def"

which is first massaged into JSON and then parsed as such, but since JSON doesn't recognise octal escapes, the result is

 "abc377def"

which is wrong. This assumes gdb-mi-decode-strings is nil, which it is by default; otherwise the octal escapes are decoded by a fragile preprocessing stage (gdb-mi-decode) which itself has known problems as noted in a comment.

Frankly, this business with going via JSON after several ad-hoc text-based transforms isn't very principled.

While the bug could be 'solved' by adding yet another regexp hack to gdb-mi-decode or gdb-mi-jsonify-buffer, I suggest we write a GDB/MI parser in Lisp directly, ditching the gdb-mi-decode preprocessing and JSON form entirely, solving this and related bugs once and for all. Many transforms can then be done on the S-expression result after parsing, which should be more efficient and less error-prone.

Message #8 received at 44173 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 44173 <at> debbugs.gnu.org
Subject: Re: bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Fri, 23 Oct 2020 15:01:52 +0300

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Fri, 23 Oct 2020 13:50:24 +0200
> 
> While the bug could be 'solved' by adding yet another regexp hack to gdb-mi-decode or gdb-mi-jsonify-buffer, I suggest we write a GDB/MI parser in Lisp directly, ditching the gdb-mi-decode preprocessing and JSON form entirely, solving this and related bugs once and for all. Many transforms can then be done on the S-expression result after parsing, which should be more efficient and less error-prone.

I'm okay with writing a GDB/MI parser, but I'm not sure I understand
how would that help to solve this particular conundrum.  AFAIR,
there's a genuine ambiguity there regarding non-ASCII characters
reported from GDB.  Could you tell how will this be solved by a
different parser?

P.S. Btw: gdb-mi.el already has a BNF parser for GDB/MI.

Message #11 received at 44173 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44173 <at> debbugs.gnu.org
Subject: Re: bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Fri, 23 Oct 2020 14:41:02 +0200

23 okt. 2020 kl. 14.01 skrev Eli Zaretskii <eliz <at> gnu.org>:

> I'm okay with writing a GDB/MI parser, but I'm not sure I understand
> how would that help to solve this particular conundrum.  AFAIR,
> there's a genuine ambiguity there regarding non-ASCII characters
> reported from GDB.

Would you mind explaining the ambiguity? Do you mean what coding system should be used for "\303\266" -- whether it should be interpreted as a string of those two bytes, the string "ö", the string "ö", or something else?
This bug is not about the encoding; it's about not interpreting the string as "303266".

>  Could you tell how will this be solved by a
> different parser?

Again, I'm not sure what you mean. The bug arises because we feed incorrectly translated data into a JSON parser. If we parse the string ourselves instead of going via JSON, that particular problem goes away.

> P.S. Btw: gdb-mi.el already has a BNF parser for GDB/MI.

It doesn't parse the lower parts of the grammar -- 'result', 'value' and so on. JSON is used for that.

Message #14 received at 44173 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 44173 <at> debbugs.gnu.org
Subject: Re: bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Fri, 23 Oct 2020 16:19:42 +0300

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Fri, 23 Oct 2020 14:41:02 +0200
> Cc: 44173 <at> debbugs.gnu.org
> 
> 23 okt. 2020 kl. 14.01 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> > I'm okay with writing a GDB/MI parser, but I'm not sure I understand
> > how would that help to solve this particular conundrum.  AFAIR,
> > there's a genuine ambiguity there regarding non-ASCII characters
> > reported from GDB.
> 
> Would you mind explaining the ambiguity? Do you mean what coding system should be used for "\303\266" -- whether it should be interpreted as a string of those two bytes, the string "ö", the string "ö", or something else?

My memory is imperfect, but luckily I was wise enough to summarize the
problems in a comment to gdb-mi-decode, which you mentioned.  Let me
now quote it:

  ;; FIXME: This is fragile: it relies on the assumption that all the
  ;; non-ASCII strings output by GDB, including names of the source
  ;; files, values of string variables in the inferior, etc., are all
  ;; encoded in the same encoding.  It also assumes that the \nnn
  ;; sequences are not split between chunks of output of the GDB process
  ;; due to buffering, and arrive together.  Finally, if some string
  ;; included literal \nnn strings (as opposed to non-ASCII characters
  ;; converted by GDB/MI to octal escapes), this decoding will mangle
  ;; those strings.  When/if GDB acquires the ability to not
  ;; escape-protect non-ASCII characters in its MI output, this kludge
  ;; should be removed.

The basic ambiguity, AFAIR, is what is described last here: a string
reported bu GDB could include literal \nnn sequences, which are not
non-ASCII characters that GDB/MI converts to octal escapes.  The
information which was which is lost once we receive the GDB/MI output.

> This bug is not about the encoding; it's about not interpreting the string as "303266".

AFAIU, this bug's root cause is the way we solved the ambiguity, which
basically assumes one of the possible interpretations should be
preferred to another, because it is more popular/useful.

Let me turn the table and ask you how did you get that string you show
in the original report?  What kind of application were you debugging,
and what did that string mean in that application?

> >  Could you tell how will this be solved by a
> > different parser?
> 
> Again, I'm not sure what you mean. The bug arises because we feed incorrectly translated data into a JSON parser. If we parse the string ourselves instead of going via JSON, that particular problem goes away.

And what will then happen to non-ASCII strings and file names reported
by GDB?  How will our parser solve that?

> > P.S. Btw: gdb-mi.el already has a BNF parser for GDB/MI.
> 
> It doesn't parse the lower parts of the grammar -- 'result', 'value' and so on. JSON is used for that.

Do you intend to extend the existing parser or write a new one from
scratch?

Message #17 received at 44173 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44173 <at> debbugs.gnu.org
Subject: Re: bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Fri, 23 Oct 2020 16:21:55 +0200

23 okt. 2020 kl. 15.19 skrev Eli Zaretskii <eliz <at> gnu.org>:

> The basic ambiguity, AFAIR, is what is described last here: a string
> reported bu GDB could include literal \nnn sequences, which are not
> non-ASCII characters that GDB/MI converts to octal escapes.  The
> information which was which is lost once we receive the GDB/MI output.

So you mean that GDB would produce the value "\303" that does not stand for a string containing the single byte octal 303? When does this occur?

> AFAIU, this bug's root cause is the way we solved the ambiguity, which
> basically assumes one of the possible interpretations should be
> preferred to another, because it is more popular/useful.

Then we disagree. The code doesn't do the right thing if gdb-mi-decode-string is nil, unless you by 'ambiguity' mean that GDB sometimes inserts a spurious backslash that should be ignored. When gdb-mi-decode-string is non-nil, it is sometimes wrong as well.

> Let me turn the table and ask you how did you get that string you show
> in the original report?

A program in the C language containing the local declaration

  char *s = "\303\266";

produces nonsense in the 'Locals' window when debugged. It doesn't matter what the string means; I would have been happy with gdb/emacs interpreting it as utf-8, latin-1 or just raw bytes presented in octal or hex.

> And what will then happen to non-ASCII strings and file names reported
> by GDB?  How will our parser solve that?

The parser can either leave the strings as undecoded unibyte strings -- that is, "\303\266" would be a 2-char string -- or decode them according to gdb-mi-decode-strings, in which case it might become a 1-char multibyte string. In the former case, the code receiving the parse tree could decide what to do with the strings and how to display them, perhaps on a case-by-case basis.

> Do you intend to extend the existing parser or write a new one from
> scratch?

Extending the existing one appears sensible, just replacing the JSON tour.

Message #20 received at 44173 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 44173 <at> debbugs.gnu.org
Subject: Re: bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Fri, 23 Oct 2020 17:44:39 +0300

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Fri, 23 Oct 2020 16:21:55 +0200
> Cc: 44173 <at> debbugs.gnu.org
> 
> 23 okt. 2020 kl. 15.19 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> > The basic ambiguity, AFAIR, is what is described last here: a string
> > reported bu GDB could include literal \nnn sequences, which are not
> > non-ASCII characters that GDB/MI converts to octal escapes.  The
> > information which was which is lost once we receive the GDB/MI output.
> 
> So you mean that GDB would produce the value "\303" that does not
> stand for a string containing the single byte octal 303?

Yes.

> When does this occur?

There's nothing special in the text "\303" that says it must be an
octal escape.  They are just 4 ASCII characters.

Moreover, even if it is an escape, it is not clear how to interpret
it: as a raw byte or as a character encoded in some 8-bit encoding.
As you probably know, GDB has settings that control how strings it
reports are encoded, so the same string can be reported in different
forms.

> > AFAIU, this bug's root cause is the way we solved the ambiguity, which
> > basically assumes one of the possible interpretations should be
> > preferred to another, because it is more popular/useful.
> 
> Then we disagree. The code doesn't do the right thing if gdb-mi-decode-string is nil, unless you by 'ambiguity' mean that GDB sometimes inserts a spurious backslash that should be ignored. When gdb-mi-decode-string is non-nil, it is sometimes wrong as well.

The ambiguity is whether gdb-mi-decode-strings should be nil or
non-nil.  We have it nil by default because non-ASCII strings and file
names are rare, but when you are debugging a program that uses such
strings, you had better set it non-nil.  And when some of your
program's source file use non-ASCII characters, you _must_ set it
non-nil, otherwise "M-x gdb" will not find the source files it needs
to visit as you step through the program.

> > Let me turn the table and ask you how did you get that string you show
> > in the original report?
> 
> A program in the C language containing the local declaration
> 
>   char *s = "\303\266";
> 
> produces nonsense in the 'Locals' window when debugged. It doesn't matter what the string means; I would have been happy with gdb/emacs interpreting it as utf-8, latin-1 or just raw bytes presented in octal or hex.

That doesn't really answer my question, though, about the use case
that causes such a string to be in the program.  Without a use case, I
could tell you to set gdb-mi-decode-strings non-nil and be done with
it.

> > And what will then happen to non-ASCII strings and file names reported
> > by GDB?  How will our parser solve that?
> 
> The parser can either leave the strings as undecoded unibyte strings -- that is, "\303\266" would be a 2-char string -- or decode them according to gdb-mi-decode-strings, in which case it might become a 1-char multibyte string. In the former case, the code receiving the parse tree could decide what to do with the strings and how to display them, perhaps on a case-by-case basis.

Well, I know that several possible ways exist, but each one of them
loses in some situations.  You say "the code receiving the parse tree
could decide", but will that code have information to make that
decision correctly?  And if you must decide in the parser, how would
you suggest to make the decision to avoid making incorrect decisions?

Message #23 received at 44173 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44173 <at> debbugs.gnu.org
Subject: Re: bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Fri, 23 Oct 2020 19:31:47 +0200

23 okt. 2020 kl. 16.44 skrev Eli Zaretskii <eliz <at> gnu.org>:

> There's nothing special in the text "\303" that says it must be an
> octal escape.  They are just 4 ASCII characters.

The grammar uses the name 'c-string', so it is reasonable to assume that most of the lexical conventions of C strings are obeyed.

Perhaps you mean that \ooo can occur outside c-string productions? If so, please say where you have seen it, or have evidence of it being produced.

The possibilities are limited. For example, stream records may use an unquoted (newline-terminated) string in place of a c-string, but I haven't seen any evidence of this in practice and it appears that gdb-mi.el does not handle that case either.

The only other possibility in the grammar would be inside 'variable' productions (field keys) which are unquoted, but those only come from a small set of fixed names.

To be clear: the exact encoding of non-ASCII bytes (whether present literally or as octal escapes in c-string tokens) is unclear, and I do not attempt to solve that problem here and now. This is about more fundamental parsing and lexing problems.

Namely: handling octal escapes in gdb-gdbmi-marker-filter is doing it at the wrong level. Moreover, this substitution, when performed, is not correct since it ignores the context; the 4-byte (excluding quotes) string "\\377" then appears to the user as the 2-byte string "\\377", where the '\377' sequence is painted in a distinct colour and really is the raw byte 0xff, and thus not a valid C character escape sequence.

Finally, the JSON mess is evidently the wrong way to go since it does not take care of strings properly -- and heavens know what else, since gdb-jsonify-buffer works at the wrong level (a pattern here) by doing regexp replacement on the whole text prior to parsing.

> That doesn't really answer my question, though, about the use case
> that causes such a string to be in the program.  Without a use case, I
> could tell you to set gdb-mi-decode-strings non-nil and be done with
> it.

Why a string is in a program is irrelevant; the user does not necessarily know that. If Emacs says that a string contains six decimal digits when it really just contains two (nonzero) bytes, then that is a lie no matter what.

> Well, I know that several possible ways exist, but each one of them
> loses in some situations.  You say "the code receiving the parse tree
> could decide", but will that code have information to make that
> decision correctly?  And if you must decide in the parser, how would
> you suggest to make the decision to avoid making incorrect decisions?

Again that problem is outside the scope of this bug but I think we can agree that it is easier, or at least no more difficult, to make a correct decision knowing the context of the string than not.

Let's see what a value/result parser can do and work from there.

Message #26 received at 44173 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 44173 <at> debbugs.gnu.org
Subject: Re: bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Fri, 23 Oct 2020 21:20:09 +0300

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Fri, 23 Oct 2020 19:31:47 +0200
> Cc: 44173 <at> debbugs.gnu.org
> 
> Let's see what a value/result parser can do and work from there.

Whatever.  I don't understand your answers and don't see how they
resolve the issues I raised.  I guess we will have to see who is right
when the code is in place.  Too bad.

Message #29 received at 44173 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44173 <at> debbugs.gnu.org
Subject: Re: bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Sat, 24 Oct 2020 18:21:53 +0200

[Message part 1 (text/plain, inline)]

23 okt. 2020 kl. 20.20 skrev Eli Zaretskii <eliz <at> gnu.org>:

> I don't understand your answers and don't see how they
> resolve the issues I raised.

Sorry if I've been communicating badly (but it takes two to do it).
I honestly thought I did address your concerns but must have misunderstood you.
Please tell me what you believe I have not explained properly, and I promise I'll do my best to answer it without referring to any previous message.

Meanwhile, here is a proof of concept which may clarify what I failed to put in words. It actually runs both the old and new value parsers on data sent by GDB, and logs an error message if discrepancies are found. They seem to work identically unless there are strings with octal escapes, which are handled correctly by the new parser. (Of course, a proper patch would not retain the old parser.)

If gdb-mi-decode-strings is non-nil, then file names, string contents etc are properly decoded as UTF-8 as expected, without any of the bugginess of the current code. Otherwise raw bytes are shown as octal escapes, which also fixes the original bug.

[gdb-mi.diff (application/octet-stream, attachment)]

Message #32 received at 44173 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 44173 <at> debbugs.gnu.org
Subject: Re: bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Sat, 24 Oct 2020 20:23:06 +0300

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Sat, 24 Oct 2020 18:21:53 +0200
> Cc: 44173 <at> debbugs.gnu.org
> 
> If gdb-mi-decode-strings is non-nil, then file names, string contents etc are properly decoded as UTF-8 as expected

Not UTF-8, but the value of gdb-mi-decode-strings, if it's a
coding-system, right?

> without any of the bugginess of the current code. Otherwise raw bytes are shown as octal escapes, which also fixes the original bug.

I hoped/thought you intended to solve this issue as well, but if the
situation is no worse than it was before, it's fine to leave it at
that.  However, please retain at least part of the comment regarding
gdb-mi-decode-strings and the ambiguity related to its use, I think
it's important that people know that.

And I hope you've verified that this does still fix the problem in
bug#21572, which this variable and the related code tries to fix?

> +       (t
> +        (error "Unrecognised escape char: %c" (following-char))))

How about leaving the text unchanged instead of signaling an error
(and thus preventing the entire data from getting to the higher
levels)?

Thanks.

Message #35 received at 44173 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44173 <at> debbugs.gnu.org
Subject: Re: bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Sat, 24 Oct 2020 20:27:13 +0200

24 okt. 2020 kl. 19.23 skrev Eli Zaretskii <eliz <at> gnu.org>:

>> If gdb-mi-decode-strings is non-nil, then file names, string contents etc are properly decoded as UTF-8 as expected
> 
> Not UTF-8, but the value of gdb-mi-decode-strings, if it's a
> coding-system, right?

Right.

> I hoped/thought you intended to solve this issue as well, but if the
> situation is no worse than it was before, it's fine to leave it at
> that.  However, please retain at least part of the comment regarding
> gdb-mi-decode-strings and the ambiguity related to its use, I think
> it's important that people know that.

Yes, the valid parts of the comment will be kept.
I'm not sure what a solution to the remaining problems would look like, but it would probably involve splitting gdb-mi-decode-strings in separate variables for file names and program values. On the other hand, given that the world is converging to UTF-8, it may be a disappearing problem?

In any case, should we want to decode strings differently depending on their structural position in the answer, I believe that it would be better done in the field accessors instead of the parser. For example,

  (bindat-get-field breakpoint 'fullname)

might become something like

  (gdb-mi--get-string-field breakpoint 'fullname 'filename)

which would tell the accessor how to decode the field.

In the short term I suggest changing the default value of gdb-mi-decode-strings to 't' as this gives the behaviour most commonly expected by the user. However, it is not critical, and in any case orthogonal to the issue at hand. What do you think?

> And I hope you've verified that this does still fix the problem in
> bug#21572, which this variable and the related code tries to fix?

Yes -- I tried debugging programs whose source file names contain Unicode chars and they were shown correctly (with gdb-mi-decode-strings = t).

>> +       (t
>> +        (error "Unrecognised escape char: %c" (following-char))))
> 
> How about leaving the text unchanged instead of signaling an error
> (and thus preventing the entire data from getting to the higher
> levels)?

Maybe, but I really dislike hiding bugs by being overly tolerant. It is precisely this tolerant nature of 'json-read' that caused this bug in the first place. (I'm not sure whether this is compliant with RFC 8259, by the way.)
I think it's fine to signal errors if the syntax isn't what we expect; after all, that is what the JSON parser does in other cases.

Thanks for the helpful comments. I'll prepare a proper patch.

Message #38 received at 44173 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 44173 <at> debbugs.gnu.org
Subject: Re: bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Sat, 24 Oct 2020 21:44:57 +0300

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Sat, 24 Oct 2020 20:27:13 +0200
> Cc: 44173 <at> debbugs.gnu.org
> 
> > I hoped/thought you intended to solve this issue as well, but if the
> > situation is no worse than it was before, it's fine to leave it at
> > that.  However, please retain at least part of the comment regarding
> > gdb-mi-decode-strings and the ambiguity related to its use, I think
> > it's important that people know that.
> 
> Yes, the valid parts of the comment will be kept.
> I'm not sure what a solution to the remaining problems would look like, but it would probably involve splitting gdb-mi-decode-strings in separate variables for file names and program values.

How do we know, at that level, whether a string is a file name or not?
And even if we succeed in knowing that about source file names of the
debuggee, we have no hope of knowing whether some string in the
debuggee is a file name or just a string.

> On the other hand, given that the world is converging to UTF-8, it may be a disappearing problem?

The rate of the convergence is severely exaggerated.  And GDB can be
used to debug all kinds of targets, which is why it has settings for
the host and the target charsets.  As long as GDB doesn't convert
everything to UTF-8, I don't see how gdb-mi.el could do that.

> In any case, should we want to decode strings differently depending on their structural position in the answer, I believe that it would be better done in the field accessors instead of the parser. For example,
> 
>   (bindat-get-field breakpoint 'fullname)
> 
> might become something like
> 
>   (gdb-mi--get-string-field breakpoint 'fullname 'filename)
> 
> which would tell the accessor how to decode the field.

See above: this still doesn't solve the problem of knowing the correct
encoding, even in specific fields of specific responses.

> In the short term I suggest changing the default value of gdb-mi-decode-strings to 't' as this gives the behaviour most commonly expected by the user. However, it is not critical, and in any case orthogonal to the issue at hand. What do you think?

I'm not at all sure this is what users want, since non-ASCII file
names in debugging are quite rare.  But I don't mind changing the
default value.

> >> +       (t
> >> +        (error "Unrecognised escape char: %c" (following-char))))
> > 
> > How about leaving the text unchanged instead of signaling an error
> > (and thus preventing the entire data from getting to the higher
> > levels)?
> 
> Maybe, but I really dislike hiding bugs by being overly tolerant.

We could display a warning.  But interrupting (and possibly ruining) a
debugging session because of our bug is very harsh: the user is
certainly not guilty.

Message #41 received at 44173 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44173 <at> debbugs.gnu.org
Subject: Re: bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Sat, 24 Oct 2020 21:41:45 +0200

24 okt. 2020 kl. 20.44 skrev Eli Zaretskii <eliz <at> gnu.org>:

> How do we know, at that level, whether a string is a file name or not?
> And even if we succeed in knowing that about source file names of the
> debuggee, we have no hope of knowing whether some string in the
> debuggee is a file name or just a string.

I think we can distinguish source file names by what field they occur in (which is why I thought that doing it in the accessor might do), but you are certainly right about strings in the program being debugged.

> The rate of the convergence is severely exaggerated.  And GDB can be
> used to debug all kinds of targets, which is why it has settings for
> the host and the target charsets.  As long as GDB doesn't convert
> everything to UTF-8, I don't see how gdb-mi.el could do that.

I don't disagree. What we can do is to have defaults that cover the most likely case and let users with less common setups change those.

> See above: this still doesn't solve the problem of knowing the correct
> encoding, even in specific fields of specific responses.

That's true, and I don't have a good answer. Perhaps we somehow can get GDB (or the OS, if it is the file system) to inform us. But as you noted, even GDB doesn't know what encoding the debugged program uses. It could very well be multiple encodings at once.

A serious debugger interface would probably push this decision to the data presentation layer and allow the user to specify how he wants to view the contents of a particular string, in the same way that users select radix for viewing integers. Not sure how this would be done in gdb-mi.

>> In the short term I suggest changing the default value of gdb-mi-decode-strings to 't' as this gives the behaviour most commonly expected by the user. However, it is not critical, and in any case orthogonal to the issue at hand. What do you think?
> 
> I'm not at all sure this is what users want, since non-ASCII file
> names in debugging are quite rare.  But I don't mind changing the
> default value.

Let's do this separately then. It seems unlikely to cause trouble.

>> Maybe, but I really dislike hiding bugs by being overly tolerant.
> 
> We could display a warning.  But interrupting (and possibly ruining) a
> debugging session because of our bug is very harsh: the user is
> certainly not guilty.

I definitely have some sympathy for that point of view, but then again, warnings that don't impede the user's progress tend to go unfixed, so being 'nice' to the user isn't necessarily in his or her best interest.

But we could try (warn ...), which I suppose you were thinking about? It's fairly visible.

Message #44 received at 44173 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44173 <at> debbugs.gnu.org
Subject: Re: bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Sun, 25 Oct 2020 13:47:49 +0100

[Message part 1 (text/plain, inline)]

Here is the complete patch. It does not change the default value of
gdb-mi-decode-strings.

[0001-Parse-GDB-MI-results-directly-instead-of-going-via-J.patch (text/x-patch, attachment)]

Message #47 received at 44173 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44173 <at> debbugs.gnu.org
Subject: Re: bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Tue, 27 Oct 2020 19:16:55 +0100

[Message part 1 (text/plain, inline)]

Here is an updated patch, rebased after some basic code cleaning in gdb-mi.el.
OK for master?

[0001-Parse-GDB-MI-results-directly-instead-of-going-via-J.patch (application/octet-stream, attachment)]

Message #50 received at 44173 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 44173 <at> debbugs.gnu.org
Subject: Re: bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Sat, 31 Oct 2020 10:22:56 +0200

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Tue, 27 Oct 2020 19:16:55 +0100
> Cc: 44173 <at> debbugs.gnu.org
> 
> Here is an updated patch, rebased after some basic code cleaning in gdb-mi.el.
> OK for master?

Yes, thanks.

Message #53 received at 44173 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44173 <at> debbugs.gnu.org
Subject: Re: bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Sat, 31 Oct 2020 14:57:01 +0100

[Message part 1 (text/plain, inline)]

31 okt. 2020 kl. 09.22 skrev Eli Zaretskii <eliz <at> gnu.org>:

> Yes, thanks.

Thank you, pushed.

The attached patch changes the default value of gdb-mi-decode-strings from nil to t.
I think we agree that it's probably a good idea, but leave the patch here in case there are comments on the documentation.

[0001-Change-the-default-value-of-gdb-mi-decode-strings-to.patch (application/octet-stream, attachment)]

Message #58 received at 44173-done <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44173-done <at> debbugs.gnu.org
Subject: Re: bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
Date: Fri, 6 Nov 2020 14:01:06 +0100

31 okt. 2020 kl. 14.57 skrev Mattias Engdegård <mattiase <at> acm.org>:

> The attached patch changes the default value of gdb-mi-decode-strings from nil to t.

This patch has now been pushed since it did not appear controversial. Changes are of course still possible.
With that, the bug is closed.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.