mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-23 03:29:47 +08:00
11bb5c41eb
The reg_buffer constructor zero-initializes (value-initializes, in C++ speak) the gdb_bytes of the m_registers array. This is not necessary, as these bytes are only meaningful if the corresponding register_status is REG_VALID. If the corresponding register_status is REG_VALID, then they will have been overwritten with the actual register data when reading the registers from the system into the reg_buffer. Fix that by removing the empty parenthesis following the new expression, meaning that the bytes will now be default-initialized, meaning they'll be left uninitialized. For reference, this is explained here: https://en.cppreference.com/w/cpp/language/new#Construction These new expressions were added in 835dcf92618e ("Use std::unique_ptr in reg_buffer"). As mentioned in that commit message, the use of value-initialisation was done on purpose to keep existing behavior, but now there is some data that suggest it would be beneficial not to do it, which is why I suggest changing it. This doesn't make a big difference on typical architectures where the register buffer is not that big. However, on ROCm (AMD GPU), the register buffer is about 65000 bytes big, so the reg_buffer constructor shows up in profiling. If you want to make some tests and profile it on a standard system, it's always possible to change: - m_registers.reset (new gdb_byte[m_descr->sizeof_raw_registers] ()); + m_registers.reset (new gdb_byte[65000] ()); and run a program that constantly hits a breakpoint with a false condition. For example, by doing this change and running the following program: static void break_here () {} int main () { for (int i = 0; i < 100000; i++) break_here (); } with the following GDB incantation: /usr/bin/time ./gdb -nx --data-directory=data-directory -q test -ex "b break_here if 0" -ex r -batch I get, for value-intializing: 11.75user 7.68system 0:18.54elapsed 104%CPU (0avgtext+0avgdata 56644maxresident)k And for default-initializing: 6.83user 8.42system 0:14.12elapsed 108%CPU (0avgtext+0avgdata 56512maxresident)k gdb/ChangeLog: * regcache.c (reg_buffer::reg_buffer): Default-initialize m_registers array. Change-Id: I5071a4444dee0530ce1bc58ebe712024ddd2b158
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.