Sergio Durigan Junior
51ed89aa0d
This bug is a regression caused by the following commit:604c4576fdis the first bad commit commit604c4576fdAuthor: 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.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.