mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-25 21:41:47 +08:00
174981ae1f
The name `current_regcache` for the list of currently-existing regcaches sounds wrong. The name is singular, but it holds multiple regcaches, so it could at least be `current_regcaches`. But in other places in GDB, "current" usually means "the object we are working with right now". For example, we swap the "current thread" when we want to operate on a given thread. This is not the case here, this variable just holds all regcaches that exist at any given time, not "the regcache we are working with right now". So, I think calling it `regcaches` is better. I also considered `regcache_list`, but a subsequent patch will make it a map and not a list, so it would sound wrong again. `regcaches` sounds right for any collection of regcache, whatever the type. Rename a few other things that were related to this `current_regcache` field. Note that there is a `get_current_regcache` function, which returns the regcache of the current thread. That one is fine, because it returns the regcache for the current thread. gdb/ChangeLog: * regcache.h (class regcache) <current_regcache>: Rename to... <regcaches>: ... this. Move doc here. * regcache.c (regcache::current_regcache) Rename to... (regcache::regcaches): ... this. Move doc to header. (get_thread_arch_aspace_regcache): Update. (regcache::regcache_thread_ptid_changed): Update. (registers_changed_ptid): Update. (class regcache_access) <current_regcache_size>: Rename to... <regcaches_size>: ... this. (current_regcache_test): Rename to... (regcaches_test): ... this. (_initialize_regcache): Update. Change-Id: I87de67154f5fe17a1f6aee7c4f2036647ee27b99
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.