rocket-tools/riscv-gnu-toolchain/binutils.git - Unnamed repository; edit this file 'description' to name the repository.

Age	Commit message (Collapse)	Author	Files	Lines
2025-06-03	[gdb/cli] Use captured per_command_time in worker threads	Tom de Vries	1	-1/+1
	With test-case gdb.base/maint.exp, I ran into: ... (gdb) file maint^M Reading symbols from maint...^M (gdb) mt set per-command on^M (gdb) Time for "DWARF indexing worker": ...^M Time for "DWARF indexing worker": ...^M Time for "DWARF indexing worker": ...^M Time for "DWARF indexing worker": ...^M Time for "DWARF skeletonless type units": ...^M Time for "DWARF add parent map": ...^M Time for "DWARF finalize worker": ...^M Time for "DWARF finalize worker": ...^M Time for "DWARF finalize worker": ...^M Time for "DWARF finalize worker": ...^M Time for "DWARF finalize worker": ...^M FAIL: $exp: warnings: per-command: mt set per-command on (timeout) mt set per-command off^M 2025-05-31 09:33:44.711 - command started^M (gdb) PASS: $exp: warnings: per-command: mt set per-command off ... I didn't manage to reproduce this by rerunning the test-case, but it's fairly easy to reproduce using a file with more debug info, for instance gdb: ... $ gdb -q -batch -ex "file build/gdb/gdb" -ex "mt set per-command on" ... Due to the default "mt dwarf synchronous" == off, the file command starts building the cooked index in the background, and returns immediately without waiting for the result. The subsequent "mt set per-command on" implies "mt set per-command time on", which switches on displaying of per-command execution time. The "Time for" lines are the result of those two commands, but these lines shouldn't be there because "mt per-command time" == off at the point of issuing the file command. Fix this by capturing the per_command_time variable, and using the captured value instead. Tested on x86_64-linux. Approved-By: Simon Marchi <simon.marchi@efficios.com> PR cli/33039 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33039
2025-04-29	gdb: add some scoped_time_its to profile startup time	Simon Marchi	1	-2/+7
	I'm investigating some issues where GDB takes a lot of time to start up (read: for the DWARF index to be ready to do anything useful). Adding those scoped_time_it instances helped me gain some insights about where GDB spends time. I think they would be useful to have upstream, to make investigating future problems easier. It would also be useful to be able to give some numbers in the commit messages. Here's an example of what GDB outputs: Time for "minsyms install worker": wall 0.045, user 0.040, sys 0.004, user+sys 0.044, 97.8 % CPU Time for "minsyms install worker": wall 0.511, user 0.457, sys 0.048, user+sys 0.505, 98.8 % CPU Time for "minsyms install worker": wall 1.513, user 1.389, sys 0.111, user+sys 1.500, 99.1 % CPU Time for "minsyms install worker": wall 1.688, user 1.451, sys 0.102, user+sys 1.553, 92.0 % CPU Time for "minsyms install worker": wall 1.897, user 1.518, sys 0.089, user+sys 1.607, 84.7 % CPU Time for "minsyms install worker": wall 2.811, user 2.558, sys 0.231, user+sys 2.789, 99.2 % CPU Time for "minsyms install worker": wall 3.257, user 3.049, sys 0.188, user+sys 3.237, 99.4 % CPU Time for "minsyms install worker": wall 3.617, user 3.089, sys 0.211, user+sys 3.300, 91.2 % CPU Time for "DWARF indexing worker": wall 19.517, user 0.894, sys 0.075, user+sys 0.969, 5.0 % CPU Time for "DWARF indexing worker": wall 19.807, user 0.891, sys 0.086, user+sys 0.977, 4.9 % CPU Time for "DWARF indexing worker": wall 20.270, user 1.559, sys 0.119, user+sys 1.678, 8.3 % CPU Time for "DWARF indexing worker": wall 20.329, user 1.878, sys 0.147, user+sys 2.025, 10.0 % CPU Time for "DWARF indexing worker": wall 20.848, user 3.483, sys 0.224, user+sys 3.707, 17.8 % CPU Time for "DWARF indexing worker": wall 21.088, user 4.285, sys 0.295, user+sys 4.580, 21.7 % CPU Time for "DWARF indexing worker": wall 21.109, user 4.501, sys 0.274, user+sys 4.775, 22.6 % CPU Time for "DWARF indexing worker": wall 21.198, user 5.087, sys 0.319, user+sys 5.406, 25.5 % CPU Time for "DWARF skeletonless type units": wall 4.024, user 3.858, sys 0.115, user+sys 3.973, 98.7 % CPU Time for "DWARF add parent map": wall 0.092, user 0.086, sys 0.004, user+sys 0.090, 97.8 % CPU Time for "DWARF finalize worker": wall 0.278, user 0.241, sys 0.009, user+sys 0.250, 89.9 % CPU Time for "DWARF finalize worker": wall 0.307, user 0.304, sys 0.000, user+sys 0.304, 99.0 % CPU Time for "DWARF finalize worker": wall 0.727, user 0.719, sys 0.000, user+sys 0.719, 98.9 % CPU Time for "DWARF finalize worker": wall 0.913, user 0.901, sys 0.003, user+sys 0.904, 99.0 % CPU Time for "DWARF finalize worker": wall 0.776, user 0.767, sys 0.004, user+sys 0.771, 99.4 % CPU Time for "DWARF finalize worker": wall 1.897, user 1.869, sys 0.006, user+sys 1.875, 98.8 % CPU Time for "DWARF finalize worker": wall 2.534, user 2.512, sys 0.005, user+sys 2.517, 99.3 % CPU Time for "DWARF finalize worker": wall 2.607, user 2.583, sys 0.006, user+sys 2.589, 99.3 % CPU Time for "DWARF finalize worker": wall 3.142, user 3.094, sys 0.022, user+sys 3.116, 99.2 % CPU Change-Id: I9453589b9005c3226499428ae9cab9f4a8c22904 Approved-By: Tom Tromey <tom@tromey.com>
2025-04-02	Clean up cooked_index::done_reading	Tom Tromey	1	-14/+4
	The cooked index worker maintains the state for the various state transition in the scanner. It is held by the cooked_index while scanning is in progress, then deleted once this has completed. I noticed that none of the arguments to cooked_index::done_reading were really needed -- the cooked_index already has access to the worker should it need it. Removing these parameters makes the code a bit simpler and also cleans up some confusing code around the use of the deferred warnings object. Regression tested on x86-64 Fedora 40. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-04-01	Add cooked_index_worker::done_reading	Tom Tromey	1	-0/+24
	The two readers currently using cooked_index_worker shared some code. This patch factors this out into a new "done_reading" method. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-04-01	Remove cooked_index_worker::result_type	Tom Tromey	1	-6/+17
	cooked_index_worker::result_type is an ad hoc tuple type used for transferring data between phases of the indexer. It's a bit unwieldy and another patch I'm working on would be somewhat nicer without it. This patch removes the type. Now cooked_index_ephemeral objects are transferred instead, which is handy because they already hold the needed state. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-04-01	Update comments from moved methods	Tom Tromey	1	-4/+4
	This updates the "See xyz.h" comments for all the methods that were moved earlier in this series. Perhaps I should have removed them instead. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-04-01	Move cooked_index_worker to cooked-index-worker.[ch]	Tom Tromey	1	-0/+146
	This moves the cooked_index_worker class to cooked-index-worker.[ch]. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-04-01	Rename cooked_index_storage	Tom Tromey	1	-7/+7
	This renames cooked_index_storage to cooked_index_worker_result, making its function more clear. It also updates the class comment to as well. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-04-01	Rename cooked-index-storage.[ch]	Tom Tromey	1	-0/+84
	A discussion with Simon made me realize that cooked_index_storage isn't a very clear name, especially now that it's escaped from read.c. While it does provide some storage (I guess any object does in a sense), it is really a helper for cooked_index_worker -- a temporary object that is destroyed after reading has completed. This patch renames this file. Later patches will rename the class and move cooked_index_worker here, something I think is reasonable given that cooked_index_storage is really something of a helper class for cooked_index_worker. Approved-By: Simon Marchi <simon.marchi@efficios.com>