Binutils with MCST patches
6d62641c83
This patch is related to PR python/16699, and is an improvement over the patch posted here: <https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html> Keith noticed that, when using the "complete" command on GDB to complete a Python command, some strange things could happen. In order to understand what can go wrong, I need to explain how the Python completion mechanism works. When the user requests a completion of a Python command by using TAB, GDB will first try to determine the right set of "brkchars" that will be used when doing the completion. This is done by actually calling the "complete" method of the Python class. Then, when we already know the "brkchars" that will be used, we call the "complete" method again, for the same values. If you read the thread mentioned above, you will see that one of the design decisions was to make the "cmdpy_completer_helper" (which is the function the does the actual calling of the "complete" method) cache the first result of the completion, since this result will be used in the second call, to do the actual completion. The problem is that the "complete" command does not process the brkchars, and the current Python completion mechanism (improved by the patch mentioned above) relies on GDB trying to determine the brkchars, and then doing the completion itself. Therefore, when we use the "complete" command instead of doing a TAB-completion on GDB, there is a scenario where we can use the invalid cache of a previous Python command that was completed before. For example: (gdb) A <TAB> (gdb) complete B B value1 B value10 B value2 B value3 B value4 B value5 B value6 B value7 B value8 B value9 (gdb) B <TAB> comp1 comp2 comp4 comp6 comp8 comp10 comp3 comp5 comp7 comp9 Here, we see that "complete B " gave a different result than "B <TAB>". The reason for that is because "A <TAB>" was called before, and its completion results were "value*", so when GDB tried to "complete B " it wrongly answered with the results for A. The problem here is using a wrong cache (A's cache) for completing B. We tried to come up with a solution that would preserve the caching mechanism, but it wasn't really possible. So I decided to completely remove the cache, and doing the method calling twice for every completion. This is not optimal, but I do not think it will impact users noticeably. It is worth mentioning another small issue that I found. The code was doing: wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL); which is totally wrong, because using "sizeof" here will lead to always the same result. So I changed this to use "strlen". The testcase also catches this problem. Keith kindly expanded the existing testcase to cover the problem described above, and everything is passing. gdb/ChangeLog: 2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com> PR python/16699 * python/py-cmd.c (cmdpy_completer_helper): Adjust function to not use a caching mechanism. Adjust comments and code to reflect that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'. (cmdpy_completer_handle_brkchars): Adjust call to cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'. (cmdpy_completer): Likewise. gdb/testsuite/ChangeLog: 2015-04-08 Keith Seitz <keiths@redhat.com> PR python/16699 * gdb.python/py-completion.exp: New tests for completion. * gdb.python/py-completion.py (CompleteLimit1): New class. (CompleteLimit2): Likewise. (CompleteLimit3): Likewise. (CompleteLimit4): Likewise. (CompleteLimit5): Likewise. (CompleteLimit6): Likewise. (CompleteLimit7): Likewise. |
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gold | ||
| gprof | ||
| include | ||
| intl | ||
| ld | ||
| libdecnumber | ||
| libiberty | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| zlib | ||
| .cvsignore | ||
| .gitattributes | ||
| .gitignore | ||
| ChangeLog | ||
| compile | ||
| config-ml.in | ||
| config.guess | ||
| config.rpath | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| COPYING.LIB | ||
| COPYING.LIBGLOSS | ||
| COPYING.NEWLIB | ||
| depcomp | ||
| djunpack.bat | ||
| install-sh | ||
| libtool.m4 | ||
| lt~obsolete.m4 | ||
| ltgcc.m4 | ||
| ltmain.sh | ||
| ltoptions.m4 | ||
| ltsugar.m4 | ||
| ltversion.m4 | ||
| MAINTAINERS | ||
| Makefile.def | ||
| Makefile.in | ||
| Makefile.tpl | ||
| makefile.vms | ||
| missing | ||
| mkdep | ||
| mkinstalldirs | ||
| move-if-change | ||
| README | ||
| README-maintainer-mode | ||
| setup.com | ||
| src-release.sh | ||
| symlink-tree | ||
| ylwrap | ||
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.