mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-25 21:41:47 +08:00
29734269a7
[ Migrating this from Gerrit: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/321 ] I noticed that some functions in infcmd and infrun call each other and all call inferior_thread, while they could just get the thread_info pointer from their caller. That means less calls to inferior_thread, so less reliance on global state, since inferior_thread reads inferior_ptid. The paths I am unsure about are: - fetch_inferior_event calls... - step_command_fsm::should_stop calls... - prepare_one_step and - process_event_stop_test calls... - set_step_info Before this patch, prepare_one_step gets the thread pointer using inferior_thread. After this patch, it gets it from the execution_control_state structure in fetch_inferior_event. Are we sure that the thread from the execution_control_state structure is the same as the one inferior_thread would return? This code path is used when a thread completes a step, but the user had specified a step count (e.g. "step 5") so we decide to do one more step. It would be strange (and even a bug I suppose) if the thread in the ecs structure in fetch_inferior_event was not the same thread that is prepared to stepped by prepare_one_step. So I believe passing the ecs thread is fine. The same logic applies to process_event_stop_test calling set_step_info. gdb/ChangeLog: * infrun.h: Forward-declare thread_info. (set_step_info): Add thread_info parameter, add doc. * infrun.c (set_step_info): Add thread_info parameter, move doc to header. * infrun.c (process_event_stop_test): Pass thread to set_step_info call. * infcmd.c (set_step_frame): Add thread_info pointer, pass it to set_step_info. (prepare_one_step): Add thread_info parameter, pass it to set_step_frame and prepare_one_step (recursive) call. (step_1): Pass thread to prepare_one_step call. (step_command_fsm::should_stop): Pass thread to prepare_one_step. (until_next_fsm): Pass thread to set_step_frame call. (finish_command): Pass thread to set_step_info call.
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.