mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-08-06 14:49:38 +08:00
cdd9148a19
The selftest `regcaches` selftest is a bit too broad for my taste, testing the behavior of get_thread_arch_aspace_regcache and various cases of registers_changed_ptid. Since I'll want to test even more scenarios of registers_changed_ptid, passing different sets of parameters, it will be difficult to do in a single test case. It is difficult to change something at some point in the test case while make sure it doesn't compromise what comes after, that we still test the scenarios that we intended to test. So, split the test case in multiple smaller ones. - Split the test case in multiple, where each test case starts from scratch and tests one specific scenario. - Introduce the populate_regcaches_for_test function, which is used by the various test cases to start with a regcache container populated with a few regcaches for two different targets. - populate_regcaches_for_test returns a regcache_test_data object, which contains the test targets that were used to create the regcaches. It also takes care to call registers_changed at the beginning and end of the test to ensure the test isn't influenced by existing regcaches, and cleans up after itself. - Move the regcache_count lambda function out of regcache_thread_ptid_changed, so it can be used in other tests. - For get_thread_arch_aspace_regcache, test that getting a regcache that already exists does not increase the count of existing regcaches. - For registers_changed_ptid, test the three cases we handle today: (nullptr, minus_one_ptid), (target, minus_one_ptid) and (target, ptid). The (target, minus_one_ptid) case was not tested prior to this patch. gdb/ChangeLog: * regcache.c (regcache_count): New. (struct regcache_test_data): New. (regcache_test_data_up): New. (populate_regcaches_for_test): New. (regcaches_test): Remove. (get_thread_arch_aspace_regcache_test): New. (registers_changed_ptid_all_test): New. (registers_changed_ptid_target_test): New. (registers_changed_ptid_target_ptid_test): New. (regcache_thread_ptid_changed): Remove regcache_count lambda. (_initialize_regcache): Register new tests. Change-Id: Id4280879fb40ff3aeae49b01b95359e1359c3d4b
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.