mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-12-19 01:19:41 +08:00
3d67444936
While debugging another issue, I noticed that 'rbreak' on a large program was very slow. In particular, with 'maint time 1': (gdb) with pagination off -- rbreak ^command_display [...] Command execution time: 1940.646332 (cpu), 1960.771517 (wall) "ps" also reported that, after this command, gdb's VSZ was 4619360. Looking into this, I found something strange. When 'rbreak' found a function "f" in file "file.adb", it would try to set the breakpoint using "break 'file.adb':'f'". This then interacted somewhat poorly with linespec. linespec first expands all the symtabs matching "file.adb", but in this program this results in thousands of CU expansions (probably due to inlining, but I did not investigate). There is probably a linespec bug here. It would make more sense for it to combine the file- and symbol- lookups, as this is more efficient. I plan to file a bug about this at least. I tracked this "file:function" style of linespec to the earliest days of gdb. Back then, "break function" would only break on the first "function" that was found -- it wasn't until much later that we changed gdb to break on all matching functions. So, I think that rbreak was written this way to try to work around this limitation, and it seems to me that this change obsoleted the need for rbreak to mention the file at all. That is, "break file:function" is redundant now, because plain "break function" will redo that same work -- just more efficiently. (The only exception to this is the case where a file is given to rbreak -- here the extra filtering is still needed.) This patch implements this. On the aforementioned large program, with this patch, rbreak still sets all the desired breakpoints (879 of them) but is now much faster: (gdb) with pagination off -- rbreak ^command_display [...] Command execution time: 91.702648 (cpu), 92.770430 (wall) It also reduces the VSZ number to 2539216. Regression tested on x86-64 Fedora 40. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14340 Approved-By: Pedro Alves <pedro@palves.net>
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.