[Bug cli/21688] `python` command ignores argument when invoked inside `if` clause

cvs-commit at gcc dot gnu.org sourceware-bugzilla@sourceware.org
Fri Jun 30 11:15:00 GMT 2017


https://sourceware.org/bugzilla/show_bug.cgi?id=21688

--- Comment #6 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Sergio Durigan Junior
<sergiodj@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=51ed89aa0dce3db46561235efdc4bbc0661bcf37

commit 51ed89aa0dce3db46561235efdc4bbc0661bcf37
Author: Sergio Durigan Junior <sergiodj@redhat.com>
Date:   Wed Jun 28 21:55:03 2017 -0400

    PR cli/21688: Fix multi-line/inline command differentiation

    This bug is a regression caused by the following commit:

      604c4576fdcfc4e7c28f569b3748a1b6b4e0dbd4 is the first bad commit
      commit 604c4576fdcfc4e7c28f569b3748a1b6b4e0dbd4
      Author: Jerome Guitton <guitton@adacore.com>
      Date:   Tue Jan 10 15:15:53 2017 +0100

    The problem happens because, on cli/cli-script.c:process_next_line,
    GDB is not using the command line string to identify which command to
    run, but it instead using the 'struct cmd_list_element *' that is
    obtained by using the mentioned string.  The problem with that is that
    the 'struct cmd_list_element *' doesn't have any information on
    whether the command issued by the user is a multi-line or inline one.

    A multi-line command is a command that will necessarily be composed of
    more than 1 line.  For example:

      (gdb) if 1
      >python
       >print ('hello')
       >end
      >end

    As can be seen in the example above, the 'python' command actually
    "opens" a new command line (represented by the change in the
    indentation) that will then be used to enter Python code.  OTOH, an
    inline command is a command that is "self-contained" in a single line,
    for example:

      (gdb) if 1
      >python print ('hello')
      >end

    This Python command is a one-liner, and therefore there is no other
    Python code that can be entered for this same block.  There is also no
    change in the indentation.

    So, the fix is somewhat simple: we have to revert the change and use
    the full command line string passed to process_next_line in order to
    identify whether we're dealing with a multi-line or an inline command.
    This commit does just that.  As can be seen, this regression also
    affects other languages, like guile or the compile framework.  To make
    things clearer, I decided to create a new helper function responsible
    for identifying a non-inline command.

    Testcase is attached.

    gdb/ChangeLog:
    2017-06-30  Sergio Durigan Junior  <sergiodj@redhat.com>

        PR cli/21688
        * cli/cli-script.c (command_name_equals_not_inline): New function.
        (process_next_line): Adjust 'if' clauses for "python", "compile"
        and "guile" to use command_name_equals_not_inline.

    gdb/testsuite/ChangeLog:
    2017-06-30  Sergio Durigan Junior  <sergiodj@redhat.com>

        PR cli/21688
        * gdb.python/py-cmd.exp (test_python_inline_or_multiline): New
        procedure.  Call it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Gdb-prs mailing list