Remove some includes reported as unused by clangd. Add some includes in
other files that were previously relying on the transitive include.
Change-Id: Ibdd0a998b04d21362a20d0ca8e5267e21e2e133e
If threads are disabled, either by --disable-threading explicitely, or by
missing std::thread support, you get the following ASAN error when
loading symbols:
==7310==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000002128 at pc 0x00000098794a bp 0x7ffe37e6af70 sp 0x7ffe37e6af68
READ of size 1 at 0x614000002128 thread T0
#0 0x987949 in index_cache_store_context::store() const ../../gdb/dwarf2/index-cache.c:163
#1 0x943467 in cooked_index_worker::write_to_cache(cooked_index const*, deferred_warnings*) const ../../gdb/dwarf2/cooked-index.c:601
#2 0x1705e39 in std::function<void ()>::operator()() const /gcc/9/include/c++/9.2.0/bits/std_function.h:690
#3 0x1705e39 in gdb::task_group::impl::~impl() ../../gdbsupport/task-group.cc:38
0x614000002128 is located 232 bytes inside of 408-byte region [0x614000002040,0x6140000021d8)
freed by thread T0 here:
#0 0x7fd75ccf8ea5 in operator delete(void*, unsigned long) ../../.././libsanitizer/asan/asan_new_delete.cc:177
#1 0x9462e5 in cooked_index::index_for_writing() ../../gdb/dwarf2/cooked-index.h:689
#2 0x9462e5 in operator() ../../gdb/dwarf2/cooked-index.c:657
#3 0x9462e5 in _M_invoke /gcc/9/include/c++/9.2.0/bits/std_function.h:300
It's happening because cooked_index_worker::wait always returns true in
this case, which tells cooked_index::wait it can delete the m_state
cooked_index_worker member, but cooked_index_worker::write_to_cache tries
to access it immediately afterwards.
Fixed by making cooked_index_worker::wait only return true if desired_state
is CACHE_DONE, same as if threading was enabled, so m_state will not be
prematurely deleted.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31694
Approved-By: Tom Tromey <tom@tromey.com>
Move some declarations related to the "quit" machinery from defs.h to
event-top.h. Most of the definitions associated to these declarations
are in event-top.c. The exceptions are `quit()` and `maybe_quit()`,
that are defined in utils.c. For consistency, move these two
definitions to event-top.c.
Include "event-top.h" in many files that use these things.
Change-Id: I6594f6df9047a9a480e7b9934275d186afb14378
Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries pointed out that the combination of sharding,
multi-threading, and per-CU "racing" means that sometimes a cross-CU
DIE reference might not be correctly resolved. However, it's
important to handle this correctly, due to some unfortunate aspects of
DWARF.
This patch implements this by arranging to preserve each worker's DIE
map through the end of index finalization. The extra data is
discarded when finalization is done. This approach also allows the
parent name resolution to be sharded, by integrating it into the
existing entry finalization loop.
In an earlier review, I remarked that addrmap couldn't be used here.
However, I was mistaken. A *mutable* addrmap cannot be used, as those
are based on splay trees and restructure the tree even during lookups
(and thus aren't thread-safe). A fixed addrmap, on the other hand, is
just a vector and is thread-safe.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30846
The mingw build currently issues a warning:
./../../src/gdb/utils.h:378:56: warning: ignoring attributes on template argument 'void(const char*, va_list)' {aka 'void(const char*, char*)'} [-Wignored-attributes]
This patch fixes the problem as suggested by Simon:
https://sourceware.org/pipermail/gdb-patches/2024-April/207908.html
...that is, by changing the warning interceptor to a class with a
single 'warn' method.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Now that defs.h, server.h and common-defs.h are included via the
`-include` option, it is no longer necessary for source files to include
them. Remove all the inclusions of these files I could find. Update
the generation scripts where relevant.
Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837
Approved-By: Pedro Alves <pedro@palves.net>
The background DWARF reader changes introduced a race when writing to
the index cache. The problem here is that constructing the
index_cache_store_context object should only happen on the main
thread, to ensure that the various value captures do not race.
This patch adds an assert to the construct to that effect, and then
arranges for this object to be constructed by the cooked_index_worker
constructor -- which is only invoked on the main thread.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31262
I think it is cleaner for 'store' to be a method on
index_cache_store_context rather than on the global index cache
itself. This patch makes this change.
This changes index_cache_store_context to also capture the per-BFD
object when it is constructed. This is used when storing to the
cache, and this approach makes the code a little simpler.
This patch changes the DWARF reader to use the new symbol domains. It
also adjusts many bits of associated code to adapt to this change.
The non-DWARF readers are updated on a best-effort basis. This is
somewhat simpler since most of them only support C and C++. I have no
way to test a few of these.
I went back and forth a few times on how to handle the "tag"
situation. The basic problem is that C has a special namespace for
tags, which is separate from the type namespace. Other languages
don't do this. So, the question is, should a DW_TAG_structure_type
end up in the tag domain, or the type domain, or should it be
language-dependent?
I settled on making it language-dependent using a thought experiment.
Suppose there was a Rust compiler that only emitted nameless
DW_TAG_structure_type objects, and specified all structure type names
using DW_TAG_typedef. This DWARF would be correct, in that it
faithfully represents the source language -- but would not work with a
purely struct-domain implementation in gdb. Therefore gdb would be
wrong.
Now, this approach is a little tricky for C++, which uses tags but
also enters a typedef for them. I notice that some other readers --
like stabsread -- actually emit a typedef symbol as well. And, I
think this is a reasonable approach. It uses more memory, but it
makes the internals simpler. However, DWARF never did this for
whatever reason, and so in the interest of keeping the series slightly
shorter, I've left some C++-specific hacks in place here.
Note that this patch includes language_minimal as a language that uses
tags. I did this to avoid regressing gdb.dwarf2/debug-names-tu.exp,
which doesn't specify the language for a type unit. Arguably this
test case is wrong.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30164
I noticed that cooked_index_worker::start_reading isn't really needed.
This patch removes it, and also removes the SCOPED_EXIT, in favor of a
direct call.
This changes cooked_index_worker to be an abstract base class. The
base class implementation is moved to cooked-index.c, and a concrete
subclass is added to read.c.
This change is preparation for the new .debug_names reader, which will
supply its own concrete implementation of the worker.
The new .debug_names reader will work by creating a cooked index from
.debug_names. This patch updates cooked_index::maybe_write_index to
avoid writing the index in this case.
However, in order to do this in a clean way, the readers are changed
so that a nullptr result from index_for_writing means "cannot be
done", and then the error message is moved into write_dwarf_index
(where it historically lived).
This moves the declaration of cooked_index_functions to
cooked-index.h. This makes it visible for use by the rewritten
.debug_names reader, and it also lets us move the implementation of
make_quick_functions into cooked-index.c, where it really belongs.
This adds a new 'lang' member to cooked_index_entry. This holds the
language of the symbol. This is primarily useful for the new
.debug_names reader, which will not scan the CUs for languages up
front.
This also changes cooked_index_shard::add to return a non-const
pointer. This doesn't impact the current code, but is needed for the
new reader.
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
Currently cooked_index entry creation is either:
- done immediately if the parent_entry is known, or
- deferred if the parent_entry is not yet known, and done later while
resolving the deferred entries.
Instead, create all cooked_index entries immediately, and keep track of which
entries have a parent_entry that needs resolving later using the new
IS_PARENT_DEFERRED flag.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Make cooked_index_entry::parent_entry private, and add member functions to
access it.
Tested on x86_64-linux and ppc64le-linux.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
Make cooked_index_storage::add and cooked_index_entry::add return a
"cooked_index_entry *" instead of a "const cooked_index_entry *".
Tested on x86_64-linux and ppc64le-linux.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
dwarf2_base_index_functions::find_per_cu is documented as using an
unrelocated address. This patch changes the interface to use the
unrelocated_addr type, just to be a bit more type-safe.
Regression tested on x86-64 Fedora 38.
This patch rearranges the DWARF reader so that more work is done in
the background. This is PR symtab/29942.
The idea here is that there is only a small amount of work that must
be done on the main thread when scanning DWARF -- before the main
scan, the only part is mapping the section data.
Currently, the DWARF reader uses the quick_symbol_functions "lazy"
functionality to defer even starting to read. This patch instead
changes the reader to start reading immediately, but doing more in
worker tasks.
Before this patch, "file" on my machine:
(gdb) file /tmp/gdb
2023-10-23 12:29:56.885 - command started
Reading symbols from /tmp/gdb...
2023-10-23 12:29:58.047 - command finished
Command execution time: 5.867228 (cpu), 1.162444 (wall)
After the patch, more work is done in the background and so this takes
a bit less time:
(gdb) file /tmp/gdb
2023-10-23 13:25:51.391 - command started
Reading symbols from /tmp/gdb...
2023-10-23 13:25:51.712 - command finished
Command execution time: 1.894500 (cpu), 0.320306 (wall)
I think this could be further sped up by using the shared library load
map to avoid objfile loops like the one in expand_symtab_containing_pc
-- it seems like the correct objfile could be chosen more directly.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29942
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30174
This changes the cooked index code to wait for threads in its
public-facing API. That is, the waits are done in cooked_index now,
and never in the cooked_index_shard. Centralizing this decision makes
it easier to wait for other events here as well.
The previous patch fixed the immediate performance problem with Ada
name matching, by having a subset of matches call
expand_symtabs_matching rather than expand_matching_symbols. However,
it seemed to me that expand_matching_symbols should not be needed at
all.
To achieve this, this patch changes ada_lookup_name_info::split_name
to use the decoded name, rather than the encoded name. In order to
make this work correctly, a new decoded form is used: one that does
not decode operators (this is already done) and also does not decode
wide characters. The latter change is done so that changes to the Ada
source charset don't affect the DWARF index.
With this in place, we can change ada-lang.c to always use
expand_symtabs_matching rather than expand_matching_symbols.
Initializers in lambda captures were introduced in C++14, and
conditionally used in gdb/cp-support.c and gdb/dwarf2/cooked-index.c.
Since C++17 is now required by GDB, use this feature unconditionally.
Change-Id: I87a3d567941e5c71217538fa75c952e4d421fa1d
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
Given that GDB now requires a C++17, replace all uses of
gdb::string_view with std::string_view.
This change has mostly been done automatically:
- gdb::string_view -> std::string_view
- #include "gdbsupport/gdb_string_view.h" -> #include <string_view>
One things which got brought up during review is that gdb::stging_view
does support being built from "nullptr" while std::sting_view does not.
Two places are manually adjusted to account for this difference:
gdb/tui/tui-io.c:tui_getc_1 and
gdbsupport/format.h:format_piece::format_piece.
The above automatic change transformed
"gdb::to_string (const gdb::string_view &)" into
"gdb::to_string (const std::string_view &)". The various direct users
of this function are now explicitly including
"gdbsupport/gdb_string_view.h". A later patch will remove the users of
gdb::to_string.
The implementation and tests of gdb::string_view are unchanged, they will
be removed in a following patch.
Change-Id: Ibb806a7e9c79eb16a55c87c6e41ad396fecf0207
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
This renames split_style::DOT, to avoid name clashes when building gdb
with an old version of Bison (2.3, the version available on macOS).
In particular the error looks like:
./split-name.h:34:3: error: expected identifier
DOT,
^
m2-exp.c:163:13: note: expanded from macro 'DOT'
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30286
Mark Wielaard pointed out that cooked_index::dump uses PRIx64, and
Andreas Schwab pointed out that gdb already has sect_offset_str. This
patch applies both these observations.
When doing "maint print objfiles" for the exec of test-case
gdb.dwarf2/pr13961.exp, we get:
...
[25] ((cooked_index_entry *) 0x37b25d0)
name: foo
canonical: foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x2a
parent: ((cooked_index_entry *) 0)
[26] ((cooked_index_entry *) 0x37b2630)
name: foo
canonical: foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x25
parent: ((cooked_index_entry *) 0x37b25d0) [foo]
...
By following the parent links in the text, we can conclude that the qualified
name of DIE 0x25 is foo::foo (which is incorrect, that's PR symtab/30739).
But it's not evident, and also hard to verify in a test-case.
Add dumping of the qualified name, such that we have:
...
[25] ((cooked_index_entry *) 0x333b5d0)
name: foo
canonical: foo
qualified: foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x2a
parent: ((cooked_index_entry *) 0)
[26] ((cooked_index_entry *) 0x333b630)
name: foo
canonical: foo
qualified: foo::foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x25
parent: ((cooked_index_entry *) 0x333b5d0) [foo]
...
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
When building with -std=c++11 I run into:
...
gdb/dwarf2/cooked-index.c: In member function \
‘void cooked_index::start_writing_index(dwarf2_per_bfd*)’:
gdb/dwarf2/cooked-index.c:469:10: error: lambda capture initializers only \
available with -std=c++14 or -std=gnu++14 [-Werror]
ctx = std::move (ctx)] ()
^~~
...
Fix this by capturing a copy instead when using -std=c++11:
...
= gdb::thread_pool::g_thread_pool->post_task ([this, per_bfd, ctx] ()
...
Tested by building with and without -stdc=++11 on x86_64-linux.
Reported-By: Tom Tromey <tom@tromey.com>
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Latest libc++[1] causes transitive include to <locale> when
<mutex> or <thread> header is included. This causes
gdb to not build[2] since <locale> defines isupper/islower etc.
functions that are explicitly macroed-out in safe-ctype.h to
prevent their use.
Use the suggestion from libc++ to include <locale> internally when
building in C++ mode to avoid build errors.
Use safe-gdb-ctype.h as the include instead of "safe-ctype.h"
to keep this isolated to gdb since rest of binutils
does not seem to use much C++.
[1]: https://reviews.llvm.org/D144331
[2]: https://issuetracker.google.com/issues/277967395
Tom de Vries pointed out a bug in the index-cache background writer --
sometimes it will fail. He also noted that it fails when the number
of worker threads is set to zero. These turn out to be the same
problem -- the cache can't be written to until the per-BFD's
"index_table" member is set.
This patch avoids the race by rearranging the code slightly, to ensure
the cache cannot possibly be written before the member is set.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30261
Hannes pointed out that cooked_index_shard::do_finalize never
populates the seen_names hash table. This patch adds the necessary
store. This reduces memory use a little for "gdb gdb":
(before) Space used: 28909568 (+0 for this command)
(after) Space used: 28884992 (+0 for this command)
What this means, btw, is that in gdb there are not many symbols that
are both mentioned in many CUs and that also require name
canonicalization. It's possible this would differ in other programs.
Simon points out that the new maint command, intended to fix a
regression, also introduces a new regression in "maint selftest".
This patch fixes the error. I did a full regression test on x86-64
Fedora 36.
Now that index cache files are written in the background, one test in
index-cache.exp is racy -- it assumes that the cache file will have
been written during startup.
This patch fixes the problem by introducing a new maintenance command
to wait for all pending writes to the index cache.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
The new DWARF cooked indexer interacts poorly with the DWARF index
cache. In particular, the cache will require gdb to wait for the
cooked index to be finalized. As this happens in the foreground, it
means that users with this setting enabled will see a slowdown.
This patch changes gdb to write the cache entry a worker thread. (As
usual, in the absence of threads, this work is simply done immediately
in the main thread.)
Some care is taken to ensure that this can't crash, and that gdb will
not exit before the task is complete.
To avoid use-after-free problems, the DWARF per-BFD object explicitly
waits for the index cache task to complete.
To avoid gdb exiting early, an exit observer is used to wait for all
such pending tasks.
In normal use, neither of these waits will be very visible. For users
using "-batch" to pre-generate the index, though, it would be.
However I don't think there is much to be done about this, as it was
the status quo ante.
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
In PR gdb/29854, Simon pointed out that it would be good to be able to
use C-c when the DWARF cooked index is waiting for finalization. The
idea here is to be able to interrupt a command like "break" -- not to
stop the finalization process itself, which runs in a worker thread.
This patch implements this idea, by changing the index wait functions
to, by default, allow a quit. Polling is done, because there doesn't
seem to be a better way to interrupt a wait on a std::future.
For v2, I realized that the thread compatibility code in thread-pool.h
also needed an update.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29854
I propose to rename cooked_index_vector and cooked_index such that the
"main" object, that is the entry point to the index, is called
cooked_index. The fact that the cooked index is implemented as a vector
of smaller indexes is an implementation detail.
This patch renames cooked_index to cooked_index_shard. The following
patch renames cooked_index_vector to cooked_index.
Change-Id: Id650f97dcb23c48f8409fa0974cd093ca0b75177
Approved-By: Tom Tromey <tom@tromey.com>
The i386 builder shows:
../../binutils-gdb/gdb/dwarf2/cooked-index.c: In member function ‘void cooked_index_vector::dump(gdbarch*) const’:
../../binutils-gdb/gdb/dwarf2/cooked-index.c:492:40: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘std::__underlying_type_impl<sect_offset, true>::type’ {aka ‘long long unsigned int’} [-Werror=format=]
492 | gdb_printf (" DIE offset: 0x%lx\n",
| ~~^
| |
| long unsigned int
| %llx
493 | to_underlying (entry->die_offset));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| std::__underlying_type_impl<sect_offset, true>::type {aka long long unsigned int}
The die_offset's underlying type is uint64, so use PRIx64 in the format
string.
Change-Id: Ibdde4c624ed1bb50eced9a514a4e37aec70a1323
As I am investigating a crash I see with the cooked index, I thought it
would be useful to have a way to dump the index contents. For those not
too familiar with it (that includes me), it can help get a feel of what
it contains and how it is structured.
The cooked_index_functions::dump function is called as part of the
"maintenance print objfiles" command. I tried to make the output
well structured and indented to help readability, as this prints a lot
of text.
The dump function first dumps all cooked index entries, like this:
[25] ((cooked_index_entry *) 0x621000121220)
name: __ioinit
canonical: __ioinit
DWARF tag: DW_TAG_variable
flags: 0x2 [IS_STATIC]
DIE offset: 0x21a4
parent: ((cooked_index_entry *) 0x6210000f9610) [std]
Then the information about the main symbol:
main: ((cooked_index_entry *) 0x621000123b40) [main]
And finally the address map contents:
[1] ((addrmap *) 0x6210000f7910)
[0x0] ((dwarf2_per_cu_data *) 0)
[0x118a] ((dwarf2_per_cu_data *) 0x60c000007f00)
[0x1cc7] ((dwarf2_per_cu_data *) 0)
[0x1cc8] ((dwarf2_per_cu_data *) 0x60c000007f00)
[0x1cdf] ((dwarf2_per_cu_data *) 0)
[0x1ce0] ((dwarf2_per_cu_data *) 0x60c000007f00)
The display of address maps above could probably be improved, to show it
more as ranges, but I think this is a reasonable start.
Note that this patch depends on Pedro Alves' patch "enum_flags
to_string" [1]. If my patch is to be merged before Pedro's series, I
will cherry-pick this patch from his series and merge it before mine.
[1] https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-8-pedro@palves.net/
Change-Id: Ida13e479fd4c8d21102ddd732241778bc3b6904a
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>
I noticed that iterating over the index yields non-const
cooked_index_entry objects. However, after finalization, they should
not be modified. This patch enforces this by adding const where
needed.
v2 makes the find, all_entries, and wait methods const as well.
PR c++/29896 points out a regression in the new DWARF reader. It does
not properly handle a case like "break fn", where "fn" is a template
function.
This happens because the new index uses strncasecmp to compare.
However, to make this work correctly, we need a custom function that
ignores template parameters.
This patch adds a custom comparison function and fixes the bug. A new
test case is included.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29896
