Change all uses of
gdb::unordered_map<string, T>
to
gdb::unordered_string_map<T>
Using unordered_string_map avoids constructing a temporary std::string
(possibly with dynamic allocation) when looking up values from
`const char *`.
I don't see any downsides to using unordered_string_map over
unordered_map, even if all the lookups are done using existing
std::string objects that would be built anyway.
I think there are places where we could refactor the code to avoid
constructing unnecessary std::string objects, but that is out of scope
for this patch.
There should be no change of behavior with this patch.
Change-Id: Ic4df78b97f2755d5821bb66942b9e4d9a79a3dc5
Approved-by: Kevin Buettner <kevinb@redhat.com>
This updates the copyright headers to include 2026. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
This updates the copyright headers to include 2025. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Currently GDB's source cache doesn't track whether the entries within
the cache are styled or not. This is pretty much fine, the assumption
is that any time we are fetching source code, we do so in order to
print it to the terminal, so where possible we always want styling
applied, and if styling is not applied, then it is because that file
cannot be styled for some reason.
Changes to 'set style enabled' cause the source cache to be flushed,
so future calls to fetch source code will regenerate the cache entries
with styling enabled or not as appropriate.
But this all assumes that styling is either on or off, and that
switching between these two states isn't done very often.
However, the Python API allows for individual commands to be executed
with styling turned off via gdb.execute(). See commit:
commit e5348a7ab3
Date: Thu Feb 13 15:39:31 2025 +0000
gdb/python: new styling argument to gdb.execute
Currently the source cache doesn't handle this case. Consider this:
(gdb) list main
... snip, styled source code displayed here ...
(gdb) python gdb.execute("list main", True, False, False)
... snip, styled source code is still shown here ...
In the second case, the final `False` passed to gdb.execute() is
asking for unstyled output.
The problem is that, `get_source_lines` calls `ensure` to prime the
cache for the file in question, then `extract_lines` just pulls the
lines of interest from the cached contents.
In `ensure`, if there is a cache entry for the desired filename, then
that is considered good enough. There is no consideration about
whether the cache entry is styled or not.
This commit aims to fix this, after this commit, the `ensure` function
will make sure that the cache entry used by `get_source_lines` is
styled correctly.
I think there are two approaches I could take:
1. Allow multiple cache entries for a single file, a styled, and
non-styled entry. The `ensure` function would then place the
correct cache entry into the last position so that
`get_source_lines` would use the correct entry, or
2. Have `ensure` recalculate entries if the required styling mode is
different to the styling mode of the current entry.
Approach #1 is better if we are rapidly switching between styling
modes, while #2 might be better if we want to keep more files in the
cache and we only rarely switch styling modes.
In the end I chose approach #2, but the good thing is that the changes
are all contained within the `ensure` function. If in the future we
wanted to change to strategy #1, this could be done transparently to
the rest of GDB.
So after this commit, the `ensure` function checks if styling is
currently possible or not. If it is not, and the current entry is
styled, then the current entry only is dropped from the cache, and a
new, unstyled entry is created. Likewise, if the current entry is
non-styled, but styling is required, we drop one entry and
recalculate.
With this change in place, I have updated set_style_enabled (in
cli/cli-style.c) so the source cache is no longer flushed when the
style settings are changed, the source cache will automatically handle
changes to the style settings now.
This problem was discovered in PR gdb/32676.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32676
Approved-By: Tom Tromey <tom@tromey.com>
This changes source_cache to use gdb::unordered_map and
gdb::unordered_set rather than the std:: variants.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This patch is the result of running check-include-guards.py on the
current tree. Running it a second time causes no changes.
Reviewed-By: Tom de Vries <tdevries@suse.de>
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.
In source_cache::ensure, keep track of which files failed to be styled, and
don't attempt to style them again in case the file dropped out of the cache.
Tested on x86_64-linux.
Reviewed-By: Lancelot Six <lancelot.six@amd.com>
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
Currently, gdb stores the number of lines and an array of file offsets
for the start of each line in struct symtab. This patch moves this
information to the source cache. This has two benefits.
First, it allows gdb to read a source file less frequently.
Currently, a source file may be read multiple times: once when
computing the file offsets, once when highlighting, and then pieces
may be read again while printing source lines. With this change, the
file is read once for its source text and file offsets; and then
perhaps read again if it is evicted from the cache.
Second, if multiple symtabs cover the same source file, then this will
share the file offsets between them. I'm not sure whether this
happens in practice.
gdb/ChangeLog
2019-08-06 Tom Tromey <tromey@adacore.com>
* annotate.c (annotate_source_line): Use g_source_cache.
* source-cache.c (source_cache::get_plain_source_lines): Change
parameters. Populate m_offset_cache.
(source_cache::ensure): New method.
(source_cache::get_line_charpos): New method.
(extract_lines): Move lower. Change parameters.
(source_cache::get_source_lines): Move lower.
* source-cache.h (class source_cache): Update comment.
<get_line_charpos>: New method.
<get_source_lines>: Update comment.
<clear>: Clear m_offset_cache.
<get_plain_source_lines>: Change parameters.
<ensure>: New method
<m_offset_cache>: New member.
* source.c (forget_cached_source_info_for_objfile): Update.
(info_source_command): Use g_source_cache.
(find_source_lines, open_source_file_with_line_charpos): Remove.
(print_source_lines_base, search_command_helper): Use g_source_cache.
* source.h (open_source_file_with_line_charpos): Don't declare.
* symtab.h (struct symtab) <nlines, line_charpos>: Remove.
* tui/tui-source.c (tui_source_window::do_scroll_vertical):
Use g_source_cache.
Currently the source cache will only store highlighted text. However,
there's no reason it could not also store plain text, when styling is
turned off.
This patch makes this change. This also simplifies the source cache
code somewhat.
gdb/ChangeLog
2019-08-06 Tom Tromey <tromey@adacore.com>
* source-cache.c (source_cache::get_plain_source_lines):
Remove "first_line" and "last_line" parameters.
(source_cache::get_source_lines): Cache plain text.
* source-cache.h (class source_cache)
<get_plain_source_lines>: Update.
The source cache was not returning the final \n of the requested range
of lines. This caused regressions with later patches in this series,
so this patch pre-emptively fixes the bug.
This adds a self-test of "extract_lines" to the source cache code. To
make it simpler to test, I changed extract_lines to be a static
function, and changed it's API a bit.
gdb/ChangeLog
2019-08-06 Tom Tromey <tromey@adacore.com>
* source-cache.c (extract_lines): No longer a method.
Changed type of parameter. Include final newline.
(selftests::extract_lines_test): New function.
(_initialize_source_cache): Likewise.
* source-cache.h (class source_cache)
<extract_lines>: Don't declare.
If the first requested line is larger than the number of lines in the
source buffer, source_cache::extract_lines could crash, because it
would try to pass string::npos" to string::substr.
This patch avoids the crash by checking for this case.
This version of the patch changes get_source_lines to return
std::string.
gdb/ChangeLog
2019-03-14 Tom Tromey <tromey@adacore.com>
* source-cache.h (class source_cache) <get_source_lines>: Return
std::string.
* source-cache.c (source_cache::extract_lines): Handle case where
first_pos==npos. Return std::string.
(source_cache::get_source_lines): Update.
A compile in the TUI somehow had "lines" defined as a macro. This
caused a compile error when including source-cache.h after whatever
header did that. I tracked this down to a #define in
/usr/include/term.h, so I just changed source-cache.h to avoid the
clash.
gdb/ChangeLog
2019-01-22 Tom Tromey <tom@tromey.com>
* source-cache.h (class source_cache) <get_source_lines,
get_plain_source_lines, extract_lines>: Rename "lines" parameter.
This commit applies all changes made after running the gdb/copyright.py
script.
Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.
gdb/ChangeLog:
Update copyright year range in all GDB files.
This changes gdb to highlight source using GNU Source Highlight, if it
is available.
This affects the output of the "list" command and also the TUI source
window.
No new test because I didn't see a way to make it work when Source
Highlight is not found.
gdb/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
* utils.h (can_emit_style_escape): Declare.
* utils.c (can_emit_style_escape): No longer static.
* cli/cli-style.c (set_style_enabled): New function.
(_initialize_cli_style): Use it.
* tui/tui-winsource.c (tui_show_source_line): Use tui_puts.
(tui_alloc_source_buffer): Change how source lines are allocated.
* tui/tui-source.c (copy_source_line): New function.
(tui_set_source_content): Use source cache.
* tui/tui-io.h (tui_puts): Update.
* tui/tui-io.c (tui_puts_internal): Add window parameter.
(tui_puts): Likewise.
(tui_redisplay_readline): Update.
* tui/tui-data.c (free_content_elements): Change how source window
contents are freed.
* source.c (forget_cached_source_info): Clear the source cache.
(print_source_lines_base): Use the source cache.
* source-cache.h: New file.
* source-cache.c: New file.
* configure.ac: Check for GNU Source Highlight library.
* configure: Update.
* config.in: Update.
* Makefile.in (SRCHIGH_LIBS, SRCHIGH_CFLAGS): New variables.
(INTERNAL_CFLAGS_BASE): Add SRCHIGH_CFLAGS.
(CLIBS): Add SRCHIGH_LIBS.
(COMMON_SFILES): Add source-cache.c.
(HFILES_NO_SRCDIR): Add source-cache.h.
