Issue #194: Change --args to match 'gdb --args'. 'cmd' now only takes program name. by fritzr · Pull Request #198 · cs01/gdbgui

fritzr · 2018-05-21T20:18:41Z

Here is a patch which does what I think is reasonable: causes --args to take all remaining arguments as program arguments as with 'gdb --args'. The 'cmd' argument only takes the program name now. There are three options for 'cmd':

Leave 'cmd' as nargs='*'; then any flags passed as '-' are ambiguous with gdbgui arguments unless the entire command string is qutoed, in which case it might as well be nargs=1. (i.e. gdbgui [gdbgui-args] cmd [these-are-more-gdbgui-args])
Set 'cmd' as nargs=1; this essentially works the same as above, but shows this explicitly in the usage string. Then to pass a full command string you would either do gdgbui 'quoted-command --with-arguments' [gdbgui-args...].
Set 'cmd' as nargs=argparse.REMAINDER; in this case the first non-option argument would begin debug program arguments. This acts more like non-GNU option parsing, i.e. gdbgui [gdbgui-options] cmd-name [cmd-arguments...]. However, with '--args' already set to argparse.REMAINDER, the two are equivalent. And then it is possible confusing if you want to do something like gdbgui cmd-name --no-browser, because --no-browser would be interpreted as a command arg.

For this reason I chose the second option. It is still convenient to debug simply with gdbgui [gdbgui-args...] program but you have gdb-like control with gdbgui --args program [program-args...].

…akes program name.

cs01 · 2018-05-27T06:11:48Z

First, thanks for putting so much work and detail into this.

I am on board with #2. I tested it and it worked with --args but it failed when I tried the "cmd" option:

>> gdbgui/backend.py examples/c/hello_c.a
Opening gdbgui in browser at http://127.0.0.1:5000
exit gdbgui by pressing CTRL+C
Traceback (most recent call last):
  File "/Users/cs/.virtualenvs/gdbgui2/lib/python3.6/site-packages/engineio/server.py", line 411, in _trigger_event
    return self.handlers[event](*args)
  File "/Users/cs/.virtualenvs/gdbgui2/lib/python3.6/site-packages/socketio/server.py", line 518, in _handle_eio_message
    self._handle_connect(sid, pkt.namespace)
  File "/Users/cs/.virtualenvs/gdbgui2/lib/python3.6/site-packages/socketio/server.py", line 421, in _handle_connect
    self.environ[sid]) is False:
  File "/Users/cs/.virtualenvs/gdbgui2/lib/python3.6/site-packages/socketio/server.py", line 490, in _trigger_event
    return self.handlers[namespace][event](*args)
  File "/Users/cs/.virtualenvs/gdbgui2/lib/python3.6/site-packages/flask_socketio/__init__.py", line 251, in _handler
    *args)
  File "/Users/cs/.virtualenvs/gdbgui2/lib/python3.6/site-packages/flask_socketio/__init__.py", line 632, in _handle_event
    ret = handler()
  File "gdbgui/backend.py", line 324, in client_connected
    payload = _state.connect_client(request.sid, desired_gdbpid)
  File "/Users/cs/git/gdbgui/gdbgui/statemanager.py", line 58, in connect_client
    ) + REQUIRED_GDB_FLAGS
TypeError: must be str, not list

It is easily fixable by changing

cmd = args.cmd

to

cmd = [args.cmd]

in backend.py.

When viewing the help text I think the arguments should be ordered from most commonly used/useful to least commonly. I think cmd and --args are the most useful. What do you think? Probably also makes sense to put cmd before --args so the help text doesn't show anything after --args.

Can the arg help text be changed to this?

Specify the executable file and any arguments. All arguments are taken literally, so if used, this must be the last argument passed to gdbgui. Example: gdbgui [...] --args ./mybinary myarg -flag1 -flag2

Might be worth considering using dest and mutual exclusion since we can't have cmd and --args at the same time and they overload to the same variable in the end.

fritzr · 2018-05-28T17:43:30Z

I've submitted an update (caa69a4). I had considered using mutex groups, but I found the usage turns out like this:

usage: backend.py [-h] [-x GDB_CMD_FILE] [-g GDB] [--rr] [-p PORT]
                  [--host HOST] [-r] [--auth-file AUTH_FILE] [--user USER]
                  [--password PASSWORD] [--key KEY] [--cert CERT]
                  [--license LICENSE] [--project PROJECT] [-v]
                  [--hide_gdbgui_upgrades] [-n] [--debug]
                  [--args ...]
                  [cmd]

A server that provides a graphical user interface to the gnu debugger (gdb).
https://github.com/cs01/gdbgui

positional arguments:
  cmd                   Name of the binary to run in gdb. To pass flags to the
                        binary, use --args instead. Example: gdbgui ./mybinary
                        [gdbgui-args...]

optional arguments:
  -h, --help            show this help message and exit
  --args ...            All remaining args are taken as the binary and
                        arguments to run in gdb (as with gdb --args). Example:
                        gdbgui [...] --args ./mybinary myarg -flag1 -flag2
gdb commands:
[...]

In which case --args or cmd are not shown under gdb commands section; nor are they shown with a mutex pipe as I would expect (i.e. [--args ...|cmd]). The latter is likely because cmd is a positional argument whereas --args is an optional argument. I believe it is for the same reason that --args shows up before cmd in the list, even though --args is set to argparse.REMAINDER and I add --args after cmd. That could be considered a deficiency in argparse because argparse.REMAINDER options should always occur last, even after positional arguments, unless GNU parsing is disabled... oh well. It's worth noting that I tried using dest='cmd' on --args, but argparse cannot use the same dest for two different flags.

However, it does accomplish placing both cmd and --args at the top of the usage like we want (I agree that makes sense) and it saves us having to check the mutex condition ourselves.

I also realized I could fix 'cmd' from str->list using type=.

fritzr · 2018-05-28T17:48:43Z

Oh yeah, and d5d55b9 fixes the --args text to match your request:

usage: backend.py [-h] [-x GDB_CMD_FILE] [-g GDB] [--rr] [-p PORT]
                  [--host HOST] [-r] [--auth-file AUTH_FILE] [--user USER]
                  [--password PASSWORD] [--key KEY] [--cert CERT]
                  [--license LICENSE] [--project PROJECT] [-v]
                  [--hide_gdbgui_upgrades] [-n] [--debug] [--args ...]
                  [cmd]

A server that provides a graphical user interface to the gnu debugger (gdb).
https://github.com/cs01/gdbgui

positional arguments:
  cmd                   Name of the binary to run in gdb. To pass flags to the
                        binary, use --args instead. Example: gdbgui ./mybinary
                        [gdbgui-args...]

optional arguments:
  -h, --help            show this help message and exit
  --args ...            Specify the executable file and any arguments. All
                        arguments are taken literally, so if used, this must
                        be the last argument passed to gdbgui. Example: gdbgui
                        [...] --args ./mybinary myarg -flag1 -flag2

cs01 · 2018-05-28T19:52:26Z

I also realized I could fix 'cmd' from str->list using type=.

Nice!

vcunat · 2019-03-07T12:58:53Z

This is bad. When I start

gdbgui --args cmd arg1 arg2

(as of current latest 0.13.1.1) it gets transformed into

gdb cmd arg1 arg2 --interpreter=mi2

which just can't work. AFAIK it needs to be

gdb --interpreter=mi2 cmd --args arg1 arg2

jhgoebbert · 2019-10-04T15:20:04Z

I can confirm, that the "--args" issue is not yet fixed in 0.13.2.0:
Please check #272 (comment)

cs01 · 2019-10-04T16:07:18Z

Sorry for the inconvenience. If you have the time/ability please submit a PR. Otherwise I will get to it when I can.

… program name. (#198) * Issue #194: Change --args to match 'gdb --args'. 'cmd' now only takes program name. * Use mutex group for --args|cmd and fix cmd to use a list type. * Update --args help text

…b-args-to-gdb-cmd, r=Mark-Simulacrum Fix gdb-cmd for rust-gdbgui With cs01/gdbgui#198, the way that gdbgui arguments were specified changed. I've tested this with program generated from `cargo new --bin` and it worked as gdbgui should. Closes rust-lang#76383.

Issue cs01#194: Change --args to match 'gdb --args'. 'cmd' now only t…

f5a8abd

…akes program name.

fritzr force-pushed the master branch 2 times, most recently from 2344f38 to f5a8abd Compare May 21, 2018 20:36

fritzr mentioned this pull request May 21, 2018

--args does not function as expected #194

Closed

cs01 force-pushed the master branch from 078e027 to ecf3a39 Compare May 27, 2018 03:06

fritzr added 2 commits May 28, 2018 13:53

Use mutex group for --args|cmd and fix cmd to use a list type.

caa69a4

Update --args help text

d5d55b9

fritzr force-pushed the master branch from d4bde02 to d5d55b9 Compare May 28, 2018 17:54

cs01 merged commit 2823c22 into cs01:master May 28, 2018

cs01 mentioned this pull request Oct 4, 2019

use pytest for testing and add minimum coverage requirement #294

Closed

simlay mentioned this pull request Jul 12, 2022

Fix gdb-cmd for rust-gdbgui rust-lang/rust#99194

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issue #194: Change --args to match 'gdb --args'. 'cmd' now only takes program name.#198

Issue #194: Change --args to match 'gdb --args'. 'cmd' now only takes program name.#198
cs01 merged 3 commits intocs01:masterfrom
fritzr:master

fritzr commented May 21, 2018

Uh oh!

cs01 commented May 27, 2018 •

edited

Loading

Uh oh!

fritzr commented May 28, 2018 •

edited

Loading

Uh oh!

fritzr commented May 28, 2018 •

edited

Loading

Uh oh!

cs01 commented May 28, 2018

Uh oh!

vcunat commented Mar 7, 2019 •

edited

Loading

Uh oh!

jhgoebbert commented Oct 4, 2019

Uh oh!

cs01 commented Oct 4, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

fritzr commented May 21, 2018

Uh oh!

cs01 commented May 27, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fritzr commented May 28, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fritzr commented May 28, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cs01 commented May 28, 2018

Uh oh!

vcunat commented Mar 7, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jhgoebbert commented Oct 4, 2019

Uh oh!

cs01 commented Oct 4, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

cs01 commented May 27, 2018 •

edited

Loading

fritzr commented May 28, 2018 •

edited

Loading

fritzr commented May 28, 2018 •

edited

Loading

vcunat commented Mar 7, 2019 •

edited

Loading