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

Age	Commit message (Collapse)	Author	Files	Lines
2023-02-27	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-26	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-25	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-24	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-23	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-22	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-21	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-20	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-19	Bump GDB's version number to 13.1.90.DATE-git.	Joel Brobecker	2	-2/+2
	This commit changes gdb/version.in to 13.1.90.DATE-git. This commit also makes the following changes in gdb/testsuite: * gdb.base/default.exp: Change $_gdb_minor to 2.
2023-02-19	Set GDB version number to 13.1.gdb-13.1-release	Joel Brobecker	1	-1/+1
	This commit changes gdb/version.in to 13.1.
2023-02-19	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-18	Fix "start" for D, Rust, etc	Tom Tromey	7	-25/+161
	The new DWARF indexer broke "start" for some languages. For D, it is broken because, while the code in cooked_index_shard::add specifically excludes Ada, it fails to exclude D. This means that the C "main" will be detected as "main" here -- whereas what is intended is for the code in find_main_name to use d_main_name to find the name. The Rust compiler, on the other hand, uses DW_AT_main_subprogram. However, the code in dwarf2_build_psymtabs_hard fails to create a fully-qualified name, so the name always ends up as plain "main". For D and Ada, a very simple approach suffices: remove the check against "main" from cooked_index_shard::add. This also has the benefit of slightly speeding up DWARF indexing. I assume this approach will work for Pascal and Modula-2 as well, but I don't have a way to test those at present. For Rust, though, this is not sufficient. And, computing the fully-qualified name in dwarf2_build_psymtabs_hard will crash, because cooked_index_entry::full_name uses the canonical name -- and that is not computed until after canonicalization. However, we don't want to wait for canonicalization to be done before computing the main name. That would remove any benefit from doing canonicalization is the background. This patch solves this dilemma by noticing that languages using DW_AT_main_subprogram are, currently, disjoint from languages requiring canonicalization. Because of this, we can add a parameter to full_name to let us avoid crashes, slowdowns, and races here. This is kind of tricky and ugly, so I've tried to comment it sufficiently. While doing this, I had to change gdb.dwarf2/main-subprogram.exp. A different possibility here would be to ignore the canonicalization needs of C in this situation, because those only affect certain types. However, I chose this approach because the test case is artificial anyhow. A long time ago, in an earlier threading attempt, I changed the global current_language to be a function (hidden behind a macro) to let us attempt lazily computing the current language. Perhaps this approach could still be made to work. However, that also seemed rather tricky, more so than this patch. Reviewed-By: Andrew Burgess <aburgess@redhat.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30116 (cherry picked from commit 47fe57c92810c7302bb80eafdec6f4345bcc69c8)
2023-02-18	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-17	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-16	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-15	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-14	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-13	Fix doc build dependencies for --with-system-readline	Keith Seitz	3	-4/+15
	PR build/30108 concerns building gdb documentation with --with-sytem-readline. If the in-tree readline directory is missing, though, the docs will fail to build: make[4]: Entering directory '/home/keiths/work/readline-doc-issue/linux/gdb/doc' make[4]: *** No rule to make target '../../../src/gdb/doc/../../readline/readline/doc/rluser.texi', needed by 'gdb.info'. Stop. The listed file (and hsuser.texi) are conditionally included by gdb.texinfo. When system readline is used, gdb/configure.ac will leave READLINE_TEXI_INCFLAGS empty, causing doc/Makefile.in to output a line to $BUILD/doc/GDBvn.texi with "@set SYSTEM_READLINE". This surpresses the inclusion of the missing files. They are not needed or used in this scenario. However, GDB_DOC_SOURCE_INCLUDES always lists these two files as dependencies, thus provoking the build error whenever readline/ is missing. This patch fixes this by creating (essentially) a conditional setting of the dependencies to be included from readline.
2023-02-13	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-12	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-11	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-10	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-09	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-08	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-07	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-06	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-05	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-04	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-03	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-02	Bump GDB's version number to 13.0.91.DATE-git.	Joel Brobecker	1	-1/+1
	This commit changes gdb/version.in to 13.0.91.DATE-git.
2023-02-02	Ensure that libbacktrace/allocfail.sh is not deleted when creating release ↵	Nick Clifton	3	-2/+7
	tarballs. * Makefile.am (CLEANFILES): Import patch from upstream to prevent allocafail.sh from being removed when running 'make clean'. (cherry picked from commit edf64cd235f5ecb3725e7cf1ff83bbdb6dd53340)
2023-02-02	Set GDB version number to 13.0.91.	Joel Brobecker	1	-1/+1
	This commit changes gdb/version.in to 13.0.91.
2023-02-02	gdb/NEWS: Change "Changes since GDB 12" to "Changes in GDB 13".	Joel Brobecker	1	-1/+1
	Now that the version number is confirmed to GDB 13, this commit updates the gdb/NEWS file accordingly, as per GDB's release procedures.
2023-02-02	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-02-01	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-01-31	gdb/arm: Use new dwarf2 function cache	Torbjörn SVENSSON	1	-32/+65
	This patch resolves the performance issue reported in pr/29738 by caching the values for the stack pointers for the inner frame. By doing so, the impact can be reduced to checking the state and returning the appropriate value. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
2023-01-31	gdb: dwarf2 generic implementation for caching function data	Torbjörn SVENSSON	2	-2/+95
	When there is no dwarf2 data for a register, a function can be called to provide the value of this register. In some situations, it might not be trivial to determine the value to return and it would cause a performance bottleneck to do the computation each time. This patch allows the called function to have a "cache" object that it can use to store some metadata between calls to reduce the performance impact of the complex logic. The cache object is unique for each function and frame, so if there are more than one function pointer stored in the dwarf2_frame_cache->reg array, then the appropriate pointer will be supplied (the type is not known by the dwarf2 implementation). dwarf2_frame_get_fn_data can be used to retrieve the function unique cache object. dwarf2_frame_allocate_fn_data can be used to allocate and retrieve the function unique cache object. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
2023-01-31	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-01-30	Fix comparator bug in cooked index	Tom Tromey	2	-85/+132
	Simon pointed out that the cooked index template-matching patch introduced a failure in libstdc++ debug mode. In particular, the new code violates the assumption of std::lower_bound and std::upper_bound that the range is sorted with respect to the comparison. When I first debugged this, I thought the problem was unfixable as-is and that a second layer of filtering would have to be done. However, on irc, Simon pointed out that it could perhaps be solved if the comparison function were assured that one operand always came from the index, with the other always being the search string. This patch implements this idea. First, a new mode is introduced: a sorting mode for cooked_index_entry::compare. In this mode, strings are compared case-insensitively, but we're careful to always sort '<' before any other printable character. This way, two names like "func" and "func<param>" will be sorted next to each other -- i.e., "func1" will not be seen between them. This is important when searching. Second, the compare function is changed to work in a strcmp-like way. This makes it easier to test and (IMO) understand. Third, the compare function is modified so that in non-sorting modes, the index entry is always the first argument. This allows consistency in compares. I regression tested this in libstdc++ debug mode on x86-64 Fedora 36. It fixes the crash that Simon saw. This is v2. I believe it addresses the review comments, except for the 'enum class' change, as I mentioned in email on the list. Approved-By: Simon Marchi <simon.marchi@efficios.com> (cherry picked from commit c121e82c39659d1140b1a6a3cfd72c765741b9f5)
2023-01-30	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-01-29	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-01-28	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-01-27	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-01-26	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-01-25	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-01-24	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-01-23	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-01-22	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-01-21	Automatic date update in version.in	GDB Administrator	1	-1/+1

2023-01-20	Automatic date update in version.in	GDB Administrator	1	-1/+1