mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-03-13 13:49:00 +08:00
In PR cli/28665, it was reported that GDB would crash when given a command like: (gdb) list task 123 The problem here is that in cli/cli-cmd.c:list_command, the string 'task 123' is passed to string_to_event_location in find a location specification. However, this location parsing understands about breakpoint conditions, and so, will stop parsing when it sees something that looks like a condition, in this case, the 'task 123' looks like a breakpoint condition. As a result, the location we get back from string_to_event_location has no actual location specification attached to it. The actual call path is: list_command string_to_event_location string_to_event_location_basic new_linespec_location In new_linespec_location we call linespec_lex_to_end, which looks at 'task 123' and decides that there's nothing there that describes a location. As such, in new_linespec_location, the spec_string field of the location is left as nullptr. Back in list_command we then call decode_line_1, which calls event_location_to_sals, which calls parse_linespec, which takes the spec_string we found earlier, and tries to converts this into a list of sals. However, parse_linespec is not intended to be passed a nullptr, for example, calling is_ada_operator will try to access through the nullptr, causing undefined behaviour. But there are other cases within parse_linespec which don't expect to see a nullptr. When looking at how to fix this issue, I first considered having linespec_lex_to_end detect the problem. That function understands when the first thing in the linespec is a condition keyword, and so, could throw an error saying something like: "no linespec before condition keyword", however, this is not going to work, at least, not without additional changes to GDB, it is valid to place a breakpoint like: (gdb) break task 123 This will place a breakpoint at the current location with the condition 'task 123', and changing linespec_lex_to_end breaks this behaviour. So, next, I considered what would happen if I added a condition to an otherwise valid list command, this is what I see: (gdb) list file.c:1 task 123 Junk at end of line specification. (gdb) So, then I wondered, could we just pull the "Junk" detection forward, so that we throw the error earlier, before we call decode_line_1? It turns out that yes we can. Well, sort of. It is simpler, I think, to add a separate check into the list_command function, after calling string_to_event_location, but before calling decode_line_1. We know when we call string_to_event_location that the string in question is not empty, so, after calling string_to_event_location, if non of the string has been consumed, then the content of the string must be junk - it clearly doesn't look like a location specification. I've reused the same "Junk at end of line specification." error for consistency, and added a few tests to cover this issue. While the first version of this patch was on the mailing list, a second bug PR gdb/28797 was raised. This was for a very similar issue, but this time the problem command was: (gdb) list ,, Here the list command understands about the first comma, list can have two arguments separated by a comma, and the first argument can be missing. So we end up trying to parse the second command "," as a linespec. However, in linespec_lex_to_end, we will stop parsing a linespec at a comma, so, in the above case we end up with an empty linespec (between the two commas), and, like above, this results in the spec_string being nullptr. As with the previous case, I've resolved this issue by adding an extra check for junk at the end of the line - after parsing (or failing to parse) the nothing between the two commas, we still have the "," left at the end of the list command line - when we see this we can throw the same "junk at the end of the line" error, and all is good. I've added tests for this case too. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28665 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28797
…
…
…
…
…
…
…
…
…
…
…
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.
Description
Languages
C
51.3%
Makefile
22.7%
Assembly
12.5%
C++
5.9%
Roff
1.4%
Other
5.6%