mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-12-19 01:19:41 +08:00
b7a5722ebd
This commits changes how errors are reported from the expression parser. Previously, parser errors were reported like this: (gdb) p a1 +}= 432 A syntax error in expression, near `}= 432'. (gdb) p a1 + A syntax error in expression, near `'. The first case is fine, a user can figure out what's going wrong, but the second case is a little confusing; as the error occurred at the end of the expression GDB just reports the empty string to the user. After this commit the first case is unchanged, but the second case now reports like this: (gdb) p a1 + A syntax error in expression, near the end of `a1 +'. Which I think is clearer. There is a possible issue if the expression being parsed is very long, GDB will repeat the whole expression. But this issue already exists in the standard case; if the error occurs early in a long expression GDB will repeat everything after the syntax error. So I've not worried about this case in my new code either, which keeps things simpler. I did consider trying to have multi-line errors here, in the style that gcc produces, with some kind of '~~~~~^' marker on the second line to indicate where the error occurred; but I rejected this due to the places in GDB where we catch an error and repackage the message within some longer string, I don't think multi-line error messages would work well in that case. At a minimum it would require some significant work in order to make all our error handling multi-line aware. I've added a couple of extra tests in gdb.base/exprs.exp. Approved-By: John Baldwin <jhb@FreeBSD.org>
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.