binutils-gdb modified for the FreeChainXenon project
![]() Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com> |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
contrib | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gdbserver | ||
gdbsupport | ||
gnulib | ||
gold | ||
gprof | ||
gprofng | ||
include | ||
intl | ||
ld | ||
libbacktrace | ||
libctf | ||
libdecnumber | ||
libiberty | ||
libsframe | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
ar-lib | ||
ChangeLog | ||
compile | ||
config-ml.in | ||
config.guess | ||
config.rpath | ||
config.sub | ||
configure | ||
configure.ac | ||
COPYING | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
COPYING3 | ||
COPYING3.LIB | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
lt~obsolete.m4 | ||
MAINTAINERS | ||
Makefile.def | ||
Makefile.in | ||
Makefile.tpl | ||
makefile.vms | ||
missing | ||
mkdep | ||
mkinstalldirs | ||
move-if-change | ||
multilib.am | ||
README | ||
README-maintainer-mode | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
test-driver | ||
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.