Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Escapes in MI error records are mangled #57

Closed
barisione opened this issue Jan 10, 2022 · 3 comments · Fixed by #59
Closed

Escapes in MI error records are mangled #57

barisione opened this issue Jan 10, 2022 · 3 comments · Fixed by #59

Comments

@barisione
Copy link
Collaborator

Describe the bug

When parsing an error record, backslashes are just dropped. This works for quotes but mangles other escapes (like \n).

For instance this:

^error,msg="This is an error\non multiple lines and with\tother escapes"

Becomes a dictionary with this message:

This is an errornon multiple lines and withtother escapes

To Reproduce

I wrote a simple script.py Python script with a GDB command to be able to have arbitrary escapes:

import gdb


class MyCommand(gdb.Command):
    def __init__(self):
        super().__init__("my-command", gdb.COMMAND_NONE)

    def invoke(self, args, from_tty):
        raise gdb.GdbError("This is an error\non multiple lines and with\tother escapes")


MyCommand()

Start GDB in MI-mode and load the script:

gdb -i=mi2 -x script.py

When you use the command, GDB produces this output:

(gdb)
my-command
&"my-command\n"
&"This is an error\n"
&"on multiple lines and with\tother escapes\n"
^error,msg="This is an error\non multiple lines and with\tother escapes"

Parse it with pygdbmi:

gdbmiparser.parse_response(r'^error,msg="This is an error\non multiple lines and with\tother escapes"')

And you get:

{'type': 'result',
 'message': 'error',
 'payload': {'msg': 'This is an errornon multiple lines and withtother escapes'},
 'token': None}

Expected behavior

Escapes should be interpreted. In the example above I would expect this output:

{'type': 'result',
 'message': 'error',
 'payload': {'msg': 'This is an error\non multiple lines and with\tother escapes'},
 'token': None}

The correct escape behaviour (which is not compatible with Python escapes) can be found in printchar in gdb/utils.c in the binutils-gdb repository.

Please complete the following information:

  • OS: macOS
  • pygdbmi version (pip freeze output):
$ pip freeze | grep pygdbmi
pygdbmi==0.10.0.1

Additional context

I haven't looked at the pygdbmi code yet but I may be able to make a PR if you are interested. I already have an unescape function in Python.

@cs01
Copy link
Owner

cs01 commented Jan 11, 2022

Thanks for the report. Yes if you'd like to make a PR that would be appreciated!

barisione added a commit to barisione/pygdbmi that referenced this issue Jan 12, 2022
barisione added a commit to barisione/pygdbmi that referenced this issue Jan 13, 2022
@barisione barisione mentioned this issue Jan 13, 2022
1 task
@barisione
Copy link
Collaborator Author

Thanks for the report. Yes if you'd like to make a PR that would be appreciated!

Here we go: #59 (not sure if you receive notifications for PRs).

@cs01
Copy link
Owner

cs01 commented Jan 15, 2022

Thanks, yes I do. I appreciate the PR. I’ll review it as soon as possible. I have a lot of obligations in my personal life at the moment but I will get to it within the next 7 days.

@cs01 cs01 closed this as completed in #59 Jan 16, 2022
cs01 pushed a commit that referenced this issue Jan 16, 2022
* convert Python 2 Unicode strings in test_pygdbmi.py

If some Python 3 features, like f-strings, are used in a file, then
black decides to convert all strings in the form u"..." to "...".

This separate commit convert all these strings into a standalone commit
to avoid the next commit to be too noisy due to black.

* add code to unescape GDB MI strings

* unescape messages in error records (#57)

* unescape strings in console, log and target records (#58)

* add changelog entry for unescaping strings
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants