2018-10-09 22:21:05 -06:00
|
|
|
/* Cache of styled source file text
|
2026-01-05 08:13:29 -07:00
|
|
|
Copyright (C) 2018-2026 Free Software Foundation, Inc.
|
2018-10-09 22:21:05 -06:00
|
|
|
|
|
|
|
|
This file is part of GDB.
|
|
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
|
the Free Software Foundation; either version 3 of the License, or
|
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
|
|
|
|
|
|
|
|
|
#include "source-cache.h"
|
Rename common to gdbsupport
This is the next patch in the ongoing series to move gdbsever to the
top level.
This patch just renames the "common" directory. The idea is to do
this move in two parts: first rename the directory (this patch), then
move the directory to the top. This approach makes the patches a bit
more tractable.
I chose the name "gdbsupport" for the directory. However, as this
patch was largely written by sed, we could pick a new name without too
much difficulty.
Tested by the buildbot.
gdb/ChangeLog
2019-07-09 Tom Tromey <tom@tromey.com>
* contrib/ari/gdb_ari.sh: Change common to gdbsupport.
* configure: Rebuild.
* configure.ac: Change common to gdbsupport.
* gdbsupport: Rename from common.
* acinclude.m4: Change common to gdbsupport.
* Makefile.in (CONFIG_SRC_SUBDIR, COMMON_SFILES)
(HFILES_NO_SRCDIR, stamp-version, ALLDEPFILES): Change common to
gdbsupport.
* aarch64-tdep.c, ada-lang.c, ada-lang.h, agent.c, alloc.c,
amd64-darwin-tdep.c, amd64-dicos-tdep.c, amd64-fbsd-nat.c,
amd64-fbsd-tdep.c, amd64-linux-nat.c, amd64-linux-tdep.c,
amd64-nbsd-tdep.c, amd64-obsd-tdep.c, amd64-sol2-tdep.c,
amd64-tdep.c, amd64-windows-tdep.c, arch-utils.c,
arch/aarch64-insn.c, arch/aarch64.c, arch/aarch64.h, arch/amd64.c,
arch/amd64.h, arch/arm-get-next-pcs.c, arch/arm-linux.c,
arch/arm.c, arch/i386.c, arch/i386.h, arch/ppc-linux-common.c,
arch/riscv.c, arch/riscv.h, arch/tic6x.c, arm-tdep.c, auto-load.c,
auxv.c, ax-gdb.c, ax-general.c, ax.h, breakpoint.c, breakpoint.h,
btrace.c, btrace.h, build-id.c, build-id.h, c-lang.h, charset.c,
charset.h, cli/cli-cmds.c, cli/cli-cmds.h, cli/cli-decode.c,
cli/cli-dump.c, cli/cli-option.h, cli/cli-script.c,
coff-pe-read.c, command.h, compile/compile-c-support.c,
compile/compile-c.h, compile/compile-cplus-symbols.c,
compile/compile-cplus-types.c, compile/compile-cplus.h,
compile/compile-loc2c.c, compile/compile.c, completer.c,
completer.h, contrib/ari/gdb_ari.sh, corefile.c, corelow.c,
cp-support.c, cp-support.h, cp-valprint.c, csky-tdep.c, ctf.c,
darwin-nat.c, debug.c, defs.h, disasm-selftests.c, disasm.c,
disasm.h, dtrace-probe.c, dwarf-index-cache.c,
dwarf-index-cache.h, dwarf-index-write.c, dwarf2-frame.c,
dwarf2expr.c, dwarf2loc.c, dwarf2read.c, event-loop.c,
event-top.c, exceptions.c, exec.c, extension.h, fbsd-nat.c,
features/aarch64-core.c, features/aarch64-fpu.c,
features/aarch64-pauth.c, features/aarch64-sve.c,
features/i386/32bit-avx.c, features/i386/32bit-avx512.c,
features/i386/32bit-core.c, features/i386/32bit-linux.c,
features/i386/32bit-mpx.c, features/i386/32bit-pkeys.c,
features/i386/32bit-segments.c, features/i386/32bit-sse.c,
features/i386/64bit-avx.c, features/i386/64bit-avx512.c,
features/i386/64bit-core.c, features/i386/64bit-linux.c,
features/i386/64bit-mpx.c, features/i386/64bit-pkeys.c,
features/i386/64bit-segments.c, features/i386/64bit-sse.c,
features/i386/x32-core.c, features/riscv/32bit-cpu.c,
features/riscv/32bit-csr.c, features/riscv/32bit-fpu.c,
features/riscv/64bit-cpu.c, features/riscv/64bit-csr.c,
features/riscv/64bit-fpu.c, features/tic6x-c6xp.c,
features/tic6x-core.c, features/tic6x-gp.c, filename-seen-cache.h,
findcmd.c, findvar.c, fork-child.c, gcore.c, gdb_bfd.c, gdb_bfd.h,
gdb_proc_service.h, gdb_regex.c, gdb_select.h, gdb_usleep.c,
gdbarch-selftests.c, gdbthread.h, gdbtypes.h, gnu-nat.c,
go32-nat.c, guile/guile.c, guile/scm-ports.c,
guile/scm-safe-call.c, guile/scm-type.c, i386-fbsd-nat.c,
i386-fbsd-tdep.c, i386-go32-tdep.c, i386-linux-nat.c,
i386-linux-tdep.c, i386-tdep.c, i387-tdep.c,
ia64-libunwind-tdep.c, ia64-linux-nat.c, inf-child.c,
inf-ptrace.c, infcall.c, infcall.h, infcmd.c, inferior-iter.h,
inferior.c, inferior.h, inflow.c, inflow.h, infrun.c, infrun.h,
inline-frame.c, language.h, linespec.c, linux-fork.c, linux-nat.c,
linux-tdep.c, linux-thread-db.c, location.c, machoread.c,
macrotab.h, main.c, maint.c, maint.h, memattr.c, memrange.h,
mi/mi-cmd-break.h, mi/mi-cmd-env.c, mi/mi-cmd-stack.c,
mi/mi-cmd-var.c, mi/mi-interp.c, mi/mi-main.c, mi/mi-parse.h,
minsyms.c, mips-linux-tdep.c, namespace.h,
nat/aarch64-linux-hw-point.c, nat/aarch64-linux-hw-point.h,
nat/aarch64-linux.c, nat/aarch64-sve-linux-ptrace.c,
nat/amd64-linux-siginfo.c, nat/fork-inferior.c,
nat/linux-btrace.c, nat/linux-btrace.h, nat/linux-namespaces.c,
nat/linux-nat.h, nat/linux-osdata.c, nat/linux-personality.c,
nat/linux-procfs.c, nat/linux-ptrace.c, nat/linux-ptrace.h,
nat/linux-waitpid.c, nat/mips-linux-watch.c,
nat/mips-linux-watch.h, nat/ppc-linux.c, nat/x86-dregs.c,
nat/x86-dregs.h, nat/x86-linux-dregs.c, nat/x86-linux.c,
nto-procfs.c, nto-tdep.c, objfile-flags.h, objfiles.c, objfiles.h,
obsd-nat.c, observable.h, osdata.c, p-valprint.c, parse.c,
parser-defs.h, ppc-linux-nat.c, printcmd.c, probe.c, proc-api.c,
procfs.c, producer.c, progspace.h, psymtab.h,
python/py-framefilter.c, python/py-inferior.c, python/py-ref.h,
python/py-type.c, python/python.c, record-btrace.c, record-full.c,
record.c, record.h, regcache-dump.c, regcache.c, regcache.h,
remote-fileio.c, remote-fileio.h, remote-sim.c, remote.c,
riscv-tdep.c, rs6000-aix-tdep.c, rust-exp.y, s12z-tdep.c,
selftest-arch.c, ser-base.c, ser-event.c, ser-pipe.c, ser-tcp.c,
ser-unix.c, skip.c, solib-aix.c, solib-target.c, solib.c,
source-cache.c, source.c, source.h, sparc-nat.c, spu-linux-nat.c,
stack.c, stap-probe.c, symfile-add-flags.h, symfile.c, symfile.h,
symtab.c, symtab.h, target-descriptions.c, target-descriptions.h,
target-memory.c, target.c, target.h, target/waitstatus.c,
target/waitstatus.h, thread-iter.h, thread.c, tilegx-tdep.c,
top.c, top.h, tracefile-tfile.c, tracefile.c, tracepoint.c,
tracepoint.h, tui/tui-io.c, ui-file.c, ui-out.h,
unittests/array-view-selftests.c,
unittests/child-path-selftests.c, unittests/cli-utils-selftests.c,
unittests/common-utils-selftests.c,
unittests/copy_bitwise-selftests.c, unittests/environ-selftests.c,
unittests/format_pieces-selftests.c,
unittests/function-view-selftests.c,
unittests/lookup_name_info-selftests.c,
unittests/memory-map-selftests.c, unittests/memrange-selftests.c,
unittests/mkdir-recursive-selftests.c,
unittests/observable-selftests.c,
unittests/offset-type-selftests.c, unittests/optional-selftests.c,
unittests/parse-connection-spec-selftests.c,
unittests/ptid-selftests.c, unittests/rsp-low-selftests.c,
unittests/scoped_fd-selftests.c,
unittests/scoped_mmap-selftests.c,
unittests/scoped_restore-selftests.c,
unittests/string_view-selftests.c, unittests/style-selftests.c,
unittests/tracepoint-selftests.c, unittests/unpack-selftests.c,
unittests/utils-selftests.c, unittests/xml-utils-selftests.c,
utils.c, utils.h, valarith.c, valops.c, valprint.c, value.c,
value.h, varobj.c, varobj.h, windows-nat.c, x86-linux-nat.c,
xml-support.c, xml-support.h, xml-tdesc.h, xstormy16-tdep.c,
xtensa-linux-nat.c, dwarf2read.h: Change common to gdbsupport.
gdb/gdbserver/ChangeLog
2019-07-09 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* configure.ac: Change common to gdbsupport.
* acinclude.m4: Change common to gdbsupport.
* Makefile.in (SFILES, OBS, GDBREPLAY_OBS, IPA_OBJS)
(version-generated.c, gdbsupport/%-ipa.o, gdbsupport/%.o): Change
common to gdbsupport.
* ax.c, event-loop.c, fork-child.c, gdb_proc_service.h,
gdbreplay.c, gdbthread.h, hostio-errno.c, hostio.c, i387-fp.c,
inferiors.c, inferiors.h, linux-aarch64-tdesc-selftest.c,
linux-amd64-ipa.c, linux-i386-ipa.c, linux-low.c,
linux-tic6x-low.c, linux-x86-low.c, linux-x86-tdesc-selftest.c,
linux-x86-tdesc.c, lynx-i386-low.c, lynx-low.c, mem-break.h,
nto-x86-low.c, regcache.c, regcache.h, remote-utils.c, server.c,
server.h, spu-low.c, symbol.c, target.h, tdesc.c, tdesc.h,
thread-db.c, tracepoint.c, win32-i386-low.c, win32-low.c: Change
common to gdbsupport.
2019-05-05 20:29:24 -06:00
|
|
|
#include "gdbsupport/scoped_fd.h"
|
2018-10-09 22:21:05 -06:00
|
|
|
#include "source.h"
|
|
|
|
|
#include "cli/cli-style.h"
|
Don't include gdbarch.h from defs.h
I touched symtab.h and was surprised to see how many files were
rebuilt. I looked into it a bit, and found that defs.h includes
gdbarch.h, which in turn includes many things.
gdbarch.h is only needed by a minority ofthe files in gdb, so this
patch removes the include from defs.h and updates the fallout.
I did "wc -l" on the files in build/gdb/.deps; this patch reduces the
line count from 139935 to 137030; so there are definitely future
build-time savings here.
Note that while I configured with --enable-targets=all, it's possible
that some *-nat.c file needs an update. I could not test all of
these. The buildbot caught a few problems along these lines.
gdb/ChangeLog
2019-07-10 Tom Tromey <tom@tromey.com>
* defs.h: Don't include gdbarch.h.
* aarch64-ravenscar-thread.c, aarch64-tdep.c, alpha-bsd-tdep.h,
alpha-linux-tdep.c, alpha-mdebug-tdep.c, arch-utils.h, arm-tdep.h,
ax-general.c, btrace.c, buildsym-legacy.c, buildsym.h, c-lang.c,
cli/cli-decode.h, cli/cli-dump.c, cli/cli-script.h,
cli/cli-style.h, coff-pe-read.h, compile/compile-c-support.c,
compile/compile-cplus.h, compile/compile-loc2c.c, corefile.c,
cp-valprint.c, cris-linux-tdep.c, ctf.c, d-lang.c, d-namespace.c,
dcache.c, dicos-tdep.c, dictionary.c, disasm-selftests.c,
dummy-frame.c, dummy-frame.h, dwarf2-frame-tailcall.c,
dwarf2expr.c, expression.h, f-lang.c, frame-base.c,
frame-unwind.c, frv-linux-tdep.c, gdbarch-selftests.c, gdbtypes.h,
go-lang.c, hppa-nbsd-tdep.c, hppa-obsd-tdep.c, i386-dicos-tdep.c,
i386-tdep.h, ia64-vms-tdep.c, interps.h, language.c,
linux-record.c, location.h, m2-lang.c, m32r-linux-tdep.c,
mem-break.c, memattr.c, mn10300-linux-tdep.c, nios2-linux-tdep.c,
objfiles.h, opencl-lang.c, or1k-linux-tdep.c, p-lang.c,
parser-defs.h, ppc-tdep.h, probe.h, python/py-record-btrace.c,
record-btrace.c, record.h, regcache-dump.c, regcache.h,
riscv-fbsd-tdep.c, riscv-linux-tdep.c, rust-exp.y,
sh-linux-tdep.c, sh-nbsd-tdep.c, source-cache.c,
sparc-nbsd-tdep.c, sparc-obsd-tdep.c, sparc-ravenscar-thread.c,
sparc64-fbsd-tdep.c, std-regs.c, target-descriptions.h,
target-float.c, tic6x-linux-tdep.c, tilegx-linux-tdep.c, top.c,
tracefile.c, trad-frame.c, type-stack.h, ui-style.c, utils.c,
utils.h, valarith.c, valprint.c, varobj.c, x86-tdep.c,
xml-support.h, xtensa-linux-tdep.c, cli/cli-cmds.h: Update.
* s390-linux-nat.c, procfs.c, inf-ptrace.c: Likewise.
2019-06-09 15:21:02 -06:00
|
|
|
#include "symtab.h"
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
#include "objfiles.h"
|
|
|
|
|
#include "exec.h"
|
2021-11-26 13:51:36 +00:00
|
|
|
#include "cli/cli-cmds.h"
|
2018-10-09 22:21:05 -06:00
|
|
|
|
|
|
|
|
#ifdef HAVE_SOURCE_HIGHLIGHT
|
2019-03-12 19:47:23 +02:00
|
|
|
/* If Gnulib redirects 'open' and 'close' to its replacements
|
|
|
|
|
'rpl_open' and 'rpl_close' via cpp macros, including <fstream>
|
|
|
|
|
below with those macros in effect will cause unresolved externals
|
|
|
|
|
when GDB is linked. Happens, e.g., in the MinGW build. */
|
|
|
|
|
#undef open
|
|
|
|
|
#undef close
|
2018-10-09 22:21:05 -06:00
|
|
|
#include <sstream>
|
|
|
|
|
#include <srchilite/sourcehighlight.h>
|
|
|
|
|
#include <srchilite/langmap.h>
|
2023-10-20 22:23:13 +02:00
|
|
|
#include <srchilite/settings.h>
|
2018-10-09 22:21:05 -06:00
|
|
|
#endif
|
|
|
|
|
|
2023-10-24 14:31:34 +02:00
|
|
|
#if GDB_SELF_TEST
|
|
|
|
|
#include "gdbsupport/selftest.h"
|
|
|
|
|
#endif
|
|
|
|
|
|
2018-10-09 22:21:05 -06:00
|
|
|
/* The number of source files we'll cache. */
|
|
|
|
|
|
|
|
|
|
#define MAX_ENTRIES 5
|
|
|
|
|
|
|
|
|
|
/* See source-cache.h. */
|
|
|
|
|
|
|
|
|
|
source_cache g_source_cache;
|
|
|
|
|
|
2021-11-26 15:13:43 +00:00
|
|
|
/* When this is true we will use the GNU Source Highlight to add styling to
|
|
|
|
|
source code (assuming the library is available). This is initialized to
|
|
|
|
|
true (if appropriate) in _initialize_source_cache below. */
|
|
|
|
|
|
|
|
|
|
static bool use_gnu_source_highlight;
|
|
|
|
|
|
|
|
|
|
/* The "maint show gnu-source-highlight enabled" command. */
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
show_use_gnu_source_highlight_enabled (struct ui_file *file, int from_tty,
|
|
|
|
|
struct cmd_list_element *c,
|
|
|
|
|
const char *value)
|
|
|
|
|
{
|
2022-01-02 11:46:15 -07:00
|
|
|
gdb_printf (file,
|
|
|
|
|
_("Use of GNU Source Highlight library is \"%s\".\n"),
|
|
|
|
|
value);
|
2021-11-26 15:13:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* The "maint set gnu-source-highlight enabled" command. */
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
set_use_gnu_source_highlight_enabled (const char *ignore_args,
|
|
|
|
|
int from_tty,
|
|
|
|
|
struct cmd_list_element *c)
|
|
|
|
|
{
|
|
|
|
|
#ifndef HAVE_SOURCE_HIGHLIGHT
|
|
|
|
|
/* If the library is not available and the user tried to enable use of
|
|
|
|
|
the library, then disable use of the library, and give an error. */
|
|
|
|
|
if (use_gnu_source_highlight)
|
|
|
|
|
{
|
|
|
|
|
use_gnu_source_highlight = false;
|
|
|
|
|
error (_("the GNU Source Highlight library is not available"));
|
|
|
|
|
}
|
|
|
|
|
#else
|
|
|
|
|
/* We (might) have just changed how we style source code, discard any
|
|
|
|
|
previously cached contents. */
|
|
|
|
|
forget_cached_source_info ();
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-09 22:21:05 -06:00
|
|
|
/* See source-cache.h. */
|
|
|
|
|
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
std::string
|
|
|
|
|
source_cache::get_plain_source_lines (struct symtab *s,
|
|
|
|
|
const std::string &fullname)
|
2018-10-09 22:21:05 -06:00
|
|
|
{
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
scoped_fd desc (open_source_file (s));
|
2018-10-09 22:21:05 -06:00
|
|
|
if (desc.get () < 0)
|
2023-02-09 20:35:32 -05:00
|
|
|
perror_with_name (symtab_to_filename_for_display (s), -desc.get ());
|
2018-10-09 22:21:05 -06:00
|
|
|
|
2019-07-22 12:41:23 -06:00
|
|
|
struct stat st;
|
|
|
|
|
if (fstat (desc.get (), &st) < 0)
|
2018-10-09 22:21:05 -06:00
|
|
|
perror_with_name (symtab_to_filename_for_display (s));
|
|
|
|
|
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
std::string lines;
|
|
|
|
|
lines.resize (st.st_size);
|
|
|
|
|
if (myread (desc.get (), &lines[0], lines.size ()) < 0)
|
2018-10-09 22:21:05 -06:00
|
|
|
perror_with_name (symtab_to_filename_for_display (s));
|
|
|
|
|
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
time_t mtime = 0;
|
2026-06-18 14:39:26 -04:00
|
|
|
if (s->compunit ().objfile () != NULL
|
|
|
|
|
&& s->compunit ().objfile ()->obfd != NULL)
|
|
|
|
|
mtime = s->compunit ().objfile ()->mtime;
|
Remove the exec_bfd macro
This removes the exec_bfd macro, in favor of new accessors on
program_space. In one spot the accessor can't be used; but this is
still a big improvement over the macro, IMO.
gdb/ChangeLog
2020-10-29 Tom Tromey <tom@tromey.com>
* windows-tdep.c (windows_solib_create_inferior_hook): Update.
* symfile.c (reread_symbols): Update.
* symfile-mem.c (add_symbol_file_from_memory_command)
(add_vsyscall_page): Update.
* source-cache.c (source_cache::get_plain_source_lines): Update.
* solib-svr4.c (find_program_interpreter, elf_locate_base)
(svr4_current_sos_direct, svr4_exec_displacement)
(svr4_relocate_main_executable): Update.
(svr4_iterate_over_objfiles_in_search_order): Update.
* solib-frv.c (enable_break2, enable_break): Update.
* solib-dsbt.c (lm_base, enable_break): Update.
* solib-darwin.c (find_program_interpreter)
(darwin_solib_create_inferior_hook): Update.
* sol-thread.c (rw_common, ps_pdmodel): Update.
* rs6000-nat.c (rs6000_nat_target::create_inferior): Update.
* remote.c (compare_sections_command)
(remote_target::trace_set_readonly_regions): Update.
* remote-sim.c (get_sim_inferior_data)
(gdbsim_target::create_inferior, gdbsim_target::create_inferior): Update.
(gdbsim_target_open, gdbsim_target::files_info): Update.
* exec.h (exec_bfd): Remove macro.
* progspace.c (initialize_progspace): Update.
* proc-service.c (ps_addr_to_core_addr, core_addr_to_ps_addr):
Update.
* nto-procfs.c (nto_procfs_target::post_attach)
(nto_procfs_target::create_inferior): Update.
* maint.c (maintenance_info_sections): Update.
* linux-thread-db.c (thread_db_target::get_thread_local_address):
Update.
* infcmd.c (post_create_inferior): Update.
* gcore.c (default_gcore_arch, default_gcore_target): Update.
(objfile_find_memory_regions): Update.
* exec.c (validate_exec_file, exec_file_attach)
(exec_read_partial_read_only, print_section_info): Update.
* corelow.c (core_target_open): Update.
* corefile.c (reopen_exec_file, validate_files): Update.
* arm-tdep.c (gdb_print_insn_arm): Update.
* arch-utils.c (gdbarch_update_p, default_print_insn): Update.
* progspace.h (struct program_space) <exec_bfd, set_exec_bfd>: New
methods.
2020-10-29 15:04:33 -06:00
|
|
|
else if (current_program_space->exec_bfd ())
|
2020-10-29 15:04:33 -06:00
|
|
|
mtime = current_program_space->ebfd_mtime;
|
2018-10-09 22:21:05 -06:00
|
|
|
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
if (mtime && mtime < st.st_mtime)
|
|
|
|
|
warning (_("Source file is more recent than executable."));
|
2018-10-09 22:21:05 -06:00
|
|
|
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
std::vector<off_t> offsets;
|
|
|
|
|
offsets.push_back (0);
|
|
|
|
|
for (size_t offset = lines.find ('\n');
|
|
|
|
|
offset != std::string::npos;
|
|
|
|
|
offset = lines.find ('\n', offset))
|
2018-10-09 22:21:05 -06:00
|
|
|
{
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
++offset;
|
|
|
|
|
/* A newline at the end does not start a new line. It would
|
|
|
|
|
seem simpler to just strip the newline in this function, but
|
|
|
|
|
then "list" won't print the final newline. */
|
|
|
|
|
if (offset != lines.size ())
|
|
|
|
|
offsets.push_back (offset);
|
2018-10-09 22:21:05 -06:00
|
|
|
}
|
|
|
|
|
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
offsets.shrink_to_fit ();
|
|
|
|
|
m_offset_cache.emplace (fullname, std::move (offsets));
|
|
|
|
|
|
|
|
|
|
return lines;
|
2018-10-09 22:21:05 -06:00
|
|
|
}
|
|
|
|
|
|
2018-12-28 21:07:24 -07:00
|
|
|
#ifdef HAVE_SOURCE_HIGHLIGHT
|
|
|
|
|
|
2018-10-09 22:21:05 -06:00
|
|
|
/* Return the Source Highlight language name, given a gdb language
|
|
|
|
|
LANG. Returns NULL if the language is not known. */
|
|
|
|
|
|
|
|
|
|
static const char *
|
|
|
|
|
get_language_name (enum language lang)
|
|
|
|
|
{
|
|
|
|
|
switch (lang)
|
|
|
|
|
{
|
|
|
|
|
case language_c:
|
|
|
|
|
case language_objc:
|
|
|
|
|
return "c.lang";
|
|
|
|
|
|
|
|
|
|
case language_cplus:
|
|
|
|
|
return "cpp.lang";
|
|
|
|
|
|
|
|
|
|
case language_d:
|
|
|
|
|
return "d.lang";
|
|
|
|
|
|
|
|
|
|
case language_go:
|
|
|
|
|
return "go.lang";
|
|
|
|
|
|
|
|
|
|
case language_fortran:
|
|
|
|
|
return "fortran.lang";
|
|
|
|
|
|
|
|
|
|
case language_m2:
|
|
|
|
|
/* Not handled by Source Highlight. */
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case language_asm:
|
|
|
|
|
return "asm.lang";
|
|
|
|
|
|
|
|
|
|
case language_pascal:
|
|
|
|
|
return "pascal.lang";
|
|
|
|
|
|
|
|
|
|
case language_opencl:
|
|
|
|
|
/* Not handled by Source Highlight. */
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case language_rust:
|
2019-06-24 16:02:47 -06:00
|
|
|
return "rust.lang";
|
2018-10-09 22:21:05 -06:00
|
|
|
|
|
|
|
|
case language_ada:
|
|
|
|
|
return "ada.lang";
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
2018-12-28 21:07:24 -07:00
|
|
|
#endif /* HAVE_SOURCE_HIGHLIGHT */
|
|
|
|
|
|
2023-10-17 11:38:06 +02:00
|
|
|
/* Try to highlight CONTENTS from file FULLNAME in language LANG using
|
2024-09-03 17:30:37 +02:00
|
|
|
the GNU source-highlight library. Return true if highlighting
|
2023-10-17 11:38:06 +02:00
|
|
|
succeeded. */
|
|
|
|
|
|
|
|
|
|
static bool
|
|
|
|
|
try_source_highlight (std::string &contents ATTRIBUTE_UNUSED,
|
|
|
|
|
enum language lang ATTRIBUTE_UNUSED,
|
|
|
|
|
const std::string &fullname ATTRIBUTE_UNUSED)
|
|
|
|
|
{
|
|
|
|
|
#ifdef HAVE_SOURCE_HIGHLIGHT
|
|
|
|
|
if (!use_gnu_source_highlight)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
const char *lang_name = get_language_name (lang);
|
|
|
|
|
|
|
|
|
|
/* The global source highlight object, or null if one was
|
|
|
|
|
never constructed. This is stored here rather than in
|
|
|
|
|
the class so that we don't need to include anything or do
|
|
|
|
|
conditional compilation in source-cache.h. */
|
|
|
|
|
static srchilite::SourceHighlight *highlighter;
|
|
|
|
|
|
2023-10-20 22:23:13 +02:00
|
|
|
/* The global source highlight language map object. */
|
|
|
|
|
static srchilite::LangMap *langmap;
|
|
|
|
|
|
2023-10-17 11:38:06 +02:00
|
|
|
bool styled = false;
|
|
|
|
|
try
|
|
|
|
|
{
|
|
|
|
|
if (highlighter == nullptr)
|
|
|
|
|
{
|
|
|
|
|
highlighter = new srchilite::SourceHighlight ("esc.outlang");
|
|
|
|
|
highlighter->setStyleFile ("esc.style");
|
2023-10-20 22:23:13 +02:00
|
|
|
|
|
|
|
|
const std::string &datadir = srchilite::Settings::retrieveDataDir ();
|
|
|
|
|
langmap = new srchilite::LangMap (datadir, "lang.map");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
std::string detected_lang;
|
|
|
|
|
if (lang_name == nullptr)
|
|
|
|
|
{
|
|
|
|
|
detected_lang = langmap->getMappedFileNameFromFileName (fullname);
|
|
|
|
|
if (detected_lang.empty ())
|
|
|
|
|
return false;
|
|
|
|
|
lang_name = detected_lang.c_str ();
|
2023-10-17 11:38:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
std::istringstream input (contents);
|
|
|
|
|
std::ostringstream output;
|
|
|
|
|
highlighter->highlight (input, output, lang_name, fullname);
|
|
|
|
|
contents = std::move (output).str ();
|
|
|
|
|
styled = true;
|
|
|
|
|
}
|
|
|
|
|
catch (...)
|
|
|
|
|
{
|
|
|
|
|
/* Source Highlight will throw an exception if
|
|
|
|
|
highlighting fails. One possible reason it can fail
|
|
|
|
|
is if the language is unknown -- which matters to gdb
|
|
|
|
|
because Rust support wasn't added until after 3.1.8.
|
|
|
|
|
Ignore exceptions here. */
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return styled;
|
|
|
|
|
#else
|
|
|
|
|
return false;
|
|
|
|
|
#endif /* HAVE_SOURCE_HIGHLIGHT */
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-24 14:31:34 +02:00
|
|
|
#ifdef HAVE_SOURCE_HIGHLIGHT
|
|
|
|
|
#if GDB_SELF_TEST
|
|
|
|
|
namespace selftests
|
|
|
|
|
{
|
|
|
|
|
static void gnu_source_highlight_test ()
|
|
|
|
|
{
|
|
|
|
|
const std::string prog
|
|
|
|
|
= ("int\n"
|
|
|
|
|
"foo (void)\n"
|
|
|
|
|
"{\n"
|
|
|
|
|
" return 0;\n"
|
|
|
|
|
"}\n");
|
|
|
|
|
const std::string fullname = "test.c";
|
|
|
|
|
std::string styled_prog;
|
|
|
|
|
|
|
|
|
|
bool res = false;
|
|
|
|
|
bool saw_exception = false;
|
|
|
|
|
styled_prog = prog;
|
|
|
|
|
try
|
|
|
|
|
{
|
|
|
|
|
res = try_source_highlight (styled_prog, language_c, fullname);
|
|
|
|
|
}
|
2024-09-24 13:41:42 +02:00
|
|
|
catch (const gdb_exception &e)
|
|
|
|
|
{
|
|
|
|
|
if (e.reason != RETURN_ERROR)
|
|
|
|
|
throw;
|
|
|
|
|
saw_exception = true;
|
|
|
|
|
}
|
2023-10-24 14:31:34 +02:00
|
|
|
catch (...)
|
|
|
|
|
{
|
|
|
|
|
saw_exception = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SELF_CHECK (!saw_exception);
|
|
|
|
|
if (res)
|
|
|
|
|
SELF_CHECK (prog.size () < styled_prog.size ());
|
|
|
|
|
else
|
|
|
|
|
SELF_CHECK (prog == styled_prog);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
#endif /* GDB_SELF_TEST */
|
|
|
|
|
#endif /* HAVE_SOURCE_HIGHLIGHT */
|
|
|
|
|
|
2018-10-09 22:21:05 -06:00
|
|
|
/* See source-cache.h. */
|
|
|
|
|
|
|
|
|
|
bool
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
source_cache::ensure (struct symtab *s)
|
2018-10-09 22:21:05 -06:00
|
|
|
{
|
2019-07-22 12:41:23 -06:00
|
|
|
std::string fullname = symtab_to_fullname (s);
|
2018-10-09 22:21:05 -06:00
|
|
|
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
size_t size = m_source_map.size ();
|
|
|
|
|
for (int i = 0; i < size; ++i)
|
2019-07-22 12:41:23 -06:00
|
|
|
{
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
if (m_source_map[i].fullname == fullname)
|
2018-10-09 22:21:05 -06:00
|
|
|
{
|
gdb: erase items from the source_cache::m_offset_cache
The source_cache class has two member variables m_source_map, which
stores the file contents, and m_offset_cache, which stores offsets
into the file contents.
As source files are read the contents of the file, as well as the
offset data, are stored in the cache using these two member variables.
Whenever GDB needs either the files contents, or the offset data,
source_cache::ensure is called. This function looks for the file in
m_source_map, and if it's found then this implies the file is also in
m_offset_cache, and we're done.
If the file is not in m_source_map then GDB calls
source_cache::get_plain_source_lines to open the file and read its
contents. ::get_plain_source_lines also calculates the offset data,
which is then inserted into m_offset_cache.
Back in ::ensure, the file contents are added into m_source_map. And
finally, if m_source_map contains more than MAX_ENTRIES, an entry is
removed from m_source_map.
The problem is entries are not removed from m_offset_cache at the same
time.
This means that if a program contains enough source files, GDB will
hold at most MAX_ENTRIES cached source file contents, but can contain
offsets data for every source file.
Now, the offsets data is going to be smaller than the cached file
contents, so maybe there's no harm here. But, when we reload the file
contents we always recalculate the offsets data. And, when we
::get_line_charpos asking for offset data we still call ::ensure which
will ends up loading and caching the file contents.
So, given the current code does the work of reloading the offset data
anyway, we may as well save memory by capping m_offset_cache to
MAX_ENTRIES just like we do m_source_map.
That's what this commit does.
There should be no user visible changes after this commit, except for
ever so slightly lower memory usage in some cases.
2021-11-26 14:34:27 +00:00
|
|
|
/* This should always hold, because we create the file offsets
|
|
|
|
|
when reading the file. */
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
gdb_assert (m_offset_cache.find (fullname)
|
|
|
|
|
!= m_offset_cache.end ());
|
|
|
|
|
/* Not strictly LRU, but at least ensure that the most
|
|
|
|
|
recently used entry is always the last candidate for
|
|
|
|
|
deletion. Note that this property is relied upon by at
|
|
|
|
|
least one caller. */
|
|
|
|
|
if (i != size - 1)
|
|
|
|
|
std::swap (m_source_map[i], m_source_map[size - 1]);
|
gdb: check styled status of source cache entries
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 e5348a7ab3f11f4c096ee4ebcdb9eb2663337357
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>
2025-02-12 14:29:01 +00:00
|
|
|
|
|
|
|
|
/* If the styling status of the cached entry matches our desired
|
|
|
|
|
styling status, or we know this file cannot be styled, in
|
|
|
|
|
which case, this (unstyled) content, is the best we can do. */
|
|
|
|
|
if (((source_styling && gdb_stdout->can_emit_style_escape ())
|
|
|
|
|
== m_source_map[size - 1].styled)
|
|
|
|
|
|| m_no_styling_files.count (fullname) > 0)
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
/* We found a match, but styling status doesn't match the desired
|
|
|
|
|
styling status. We already moved the matching item to the
|
|
|
|
|
back of M_SOURCE_MAP, so drop the entry now, and then
|
|
|
|
|
recompute with the desired styling. */
|
|
|
|
|
m_source_map.pop_back ();
|
|
|
|
|
break;
|
2018-10-09 22:21:05 -06:00
|
|
|
}
|
2019-07-22 12:41:23 -06:00
|
|
|
}
|
2018-10-09 22:21:05 -06:00
|
|
|
|
gdb: Catch exceptions if the source file is not found
The source_cache::ensure method may throw an exception through
the invocation of source_cache::get_plain_source_lines. This
happens when the source file is not found. The expected behaviour
of "ensure" is only returning "true" or "false" according to the
documentation in the header file.
So far, if gdb is in source layout and a file is missing, you see
some outputs like below:
,---------------------------------------------.
| test.c file is loaded in the source window. |
| |
| int main() |
| ... |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| /path/to/crt0.S: No such file or directory. |
| (gdb) p/x $pc |
| $1 = 0x124 |
| (gdb) n |
| /path/to/crt0.S: No such file or directory. |
| (gdb) p/x $pc |
| $2 = 0x128 |
| (gdb) [pressing arrow-down key] |
| (gdb) terminate called after throwing an |
| instance of 'gdb_exception_error' |
`---------------------------------------------'
Other issues have been encountered as well [1].
The patch from Pedro [2] which is about preventing exceptions
from crossing the "readline" mitigates the situation by not
causing gdb crash, but still there are lots of errors printed:
,---------------------------------------------.
| test.c file is loaded in the source window. |
| |
| int main() |
| ... |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-down key] |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-down key] |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-up key] |
| /path/to/crt0.S: No such file or directory. |
`---------------------------------------------'
With the changes of this patch, the behavior is like:
,---------------------------------------------.
| initially, source window is empty because |
| crt0.S is not found and according to the |
| program counter that is the piece of code |
| being executed. |
| |
| later, when we break at main (see commands |
| below), this window will be filled with the |
| the contents of test.c file. |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| (gdb) p/x $pc |
| $1 = 0x124 |
| (gdb) n |
| (gdb) p/x $pc |
| $2 = 0x128 |
| (gdb) b main |
| Breakpoint 1 at 0x334: file test.c, line 8. |
| (gdb) cont |
| Continuing. |
| Breakpoint 1, main () at hello.c:8 |
| (gdb) n |
| (gdb) |
`---------------------------------------------'
There is no crash and the error message is completely
gone. Maybe it is good practice that the error is
shown inside the source window.
I tested this change against gdb.base/list-missing-source.exp
and there was no regression.
[1]
It has also been observed in the past that the register
values are not transferred from qemu's gdb stub, see:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/226
[2]
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=2f267673f0fdee9287e6d404ecd4f2d29da0d2f2
gdb/ChangeLog:
* source-cache.c (source_cache::ensure): Surround
get_plain_source_lines with a try/catch.
(source_cache::get_line_charpos): Get rid of try/catch
and only check for the return value of "ensure".
* tui/tui-source.c (tui_source_window::set_contents):
Simplify "nlines" calculation.
gdb/testsuite/ChangeLog:
* gdb.tui/tui-missing-src.exp: Add the "missing source
file" test for the TUI.
2020-02-06 16:20:37 +01:00
|
|
|
std::string contents;
|
gdb: check styled status of source cache entries
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 e5348a7ab3f11f4c096ee4ebcdb9eb2663337357
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>
2025-02-12 14:29:01 +00:00
|
|
|
bool styled_p = false;
|
gdb: Catch exceptions if the source file is not found
The source_cache::ensure method may throw an exception through
the invocation of source_cache::get_plain_source_lines. This
happens when the source file is not found. The expected behaviour
of "ensure" is only returning "true" or "false" according to the
documentation in the header file.
So far, if gdb is in source layout and a file is missing, you see
some outputs like below:
,---------------------------------------------.
| test.c file is loaded in the source window. |
| |
| int main() |
| ... |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| /path/to/crt0.S: No such file or directory. |
| (gdb) p/x $pc |
| $1 = 0x124 |
| (gdb) n |
| /path/to/crt0.S: No such file or directory. |
| (gdb) p/x $pc |
| $2 = 0x128 |
| (gdb) [pressing arrow-down key] |
| (gdb) terminate called after throwing an |
| instance of 'gdb_exception_error' |
`---------------------------------------------'
Other issues have been encountered as well [1].
The patch from Pedro [2] which is about preventing exceptions
from crossing the "readline" mitigates the situation by not
causing gdb crash, but still there are lots of errors printed:
,---------------------------------------------.
| test.c file is loaded in the source window. |
| |
| int main() |
| ... |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-down key] |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-down key] |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-up key] |
| /path/to/crt0.S: No such file or directory. |
`---------------------------------------------'
With the changes of this patch, the behavior is like:
,---------------------------------------------.
| initially, source window is empty because |
| crt0.S is not found and according to the |
| program counter that is the piece of code |
| being executed. |
| |
| later, when we break at main (see commands |
| below), this window will be filled with the |
| the contents of test.c file. |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| (gdb) p/x $pc |
| $1 = 0x124 |
| (gdb) n |
| (gdb) p/x $pc |
| $2 = 0x128 |
| (gdb) b main |
| Breakpoint 1 at 0x334: file test.c, line 8. |
| (gdb) cont |
| Continuing. |
| Breakpoint 1, main () at hello.c:8 |
| (gdb) n |
| (gdb) |
`---------------------------------------------'
There is no crash and the error message is completely
gone. Maybe it is good practice that the error is
shown inside the source window.
I tested this change against gdb.base/list-missing-source.exp
and there was no regression.
[1]
It has also been observed in the past that the register
values are not transferred from qemu's gdb stub, see:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/226
[2]
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=2f267673f0fdee9287e6d404ecd4f2d29da0d2f2
gdb/ChangeLog:
* source-cache.c (source_cache::ensure): Surround
get_plain_source_lines with a try/catch.
(source_cache::get_line_charpos): Get rid of try/catch
and only check for the return value of "ensure".
* tui/tui-source.c (tui_source_window::set_contents):
Simplify "nlines" calculation.
gdb/testsuite/ChangeLog:
* gdb.tui/tui-missing-src.exp: Add the "missing source
file" test for the TUI.
2020-02-06 16:20:37 +01:00
|
|
|
try
|
|
|
|
|
{
|
|
|
|
|
contents = get_plain_source_lines (s, fullname);
|
|
|
|
|
}
|
|
|
|
|
catch (const gdb_exception_error &e)
|
|
|
|
|
{
|
|
|
|
|
/* If 's' is not found, an exception is thrown. */
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2019-07-22 12:41:23 -06:00
|
|
|
|
2023-10-17 11:38:06 +02:00
|
|
|
if (source_styling && gdb_stdout->can_emit_style_escape ()
|
|
|
|
|
&& m_no_styling_files.count (fullname) == 0)
|
2019-07-22 12:41:23 -06:00
|
|
|
{
|
gdb: check styled status of source cache entries
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 e5348a7ab3f11f4c096ee4ebcdb9eb2663337357
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>
2025-02-12 14:29:01 +00:00
|
|
|
styled_p
|
2023-10-17 11:38:06 +02:00
|
|
|
= try_source_highlight (contents, s->language (), fullname);
|
Allow use of Pygments to colorize source code
While GNU Source Highlight is good, it's also difficult to build and
distribute. For one thing, it needs Boost. For another, it has an
unusual configuration and installation setup.
Pygments, a Python library, doesn't suffer from these issues, and so I
thought it would be a reasonable fallback.
This patch implements this idea. GNU Source Highlight is preferred,
but if it is unavailable (or fails), the extension languages are
tried. This patch also implements support for Pygments.
Something similar could be done for Guile, using:
https://dthompson.us/projects/guile-syntax-highlight.html
However, I don't know enough about Guile internals to make this
happen, so I have not done it here.
gdb/ChangeLog
2020-01-21 Tom Tromey <tromey@adacore.com>
* source-cache.c (source_cache::ensure): Call ext_lang_colorize.
* python/python.c (python_extension_ops): Update.
(gdbpy_colorize): New function.
* python/lib/gdb/__init__.py (colorize): New function.
* extension.h (ext_lang_colorize): Declare.
* extension.c (ext_lang_colorize): New function.
* extension-priv.h (struct extension_language_ops) <colorize>: New
member.
* cli/cli-style.c (_initialize_cli_style): Update help text.
Change-Id: I5e21623ee05f1f66baaa6deaeca78b578c031bf4
2020-01-03 13:59:27 -07:00
|
|
|
|
gdb: check styled status of source cache entries
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 e5348a7ab3f11f4c096ee4ebcdb9eb2663337357
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>
2025-02-12 14:29:01 +00:00
|
|
|
if (!styled_p)
|
Allow use of Pygments to colorize source code
While GNU Source Highlight is good, it's also difficult to build and
distribute. For one thing, it needs Boost. For another, it has an
unusual configuration and installation setup.
Pygments, a Python library, doesn't suffer from these issues, and so I
thought it would be a reasonable fallback.
This patch implements this idea. GNU Source Highlight is preferred,
but if it is unavailable (or fails), the extension languages are
tried. This patch also implements support for Pygments.
Something similar could be done for Guile, using:
https://dthompson.us/projects/guile-syntax-highlight.html
However, I don't know enough about Guile internals to make this
happen, so I have not done it here.
gdb/ChangeLog
2020-01-21 Tom Tromey <tromey@adacore.com>
* source-cache.c (source_cache::ensure): Call ext_lang_colorize.
* python/python.c (python_extension_ops): Update.
(gdbpy_colorize): New function.
* python/lib/gdb/__init__.py (colorize): New function.
* extension.h (ext_lang_colorize): Declare.
* extension.c (ext_lang_colorize): New function.
* extension-priv.h (struct extension_language_ops) <colorize>: New
member.
* cli/cli-style.c (_initialize_cli_style): Update help text.
Change-Id: I5e21623ee05f1f66baaa6deaeca78b578c031bf4
2020-01-03 13:59:27 -07:00
|
|
|
{
|
2023-10-13 09:27:48 +00:00
|
|
|
std::optional<std::string> ext_contents;
|
2025-04-07 22:40:04 +02:00
|
|
|
ext_contents = ext_lang_colorize (fullname, contents,
|
|
|
|
|
s->language ());
|
Allow use of Pygments to colorize source code
While GNU Source Highlight is good, it's also difficult to build and
distribute. For one thing, it needs Boost. For another, it has an
unusual configuration and installation setup.
Pygments, a Python library, doesn't suffer from these issues, and so I
thought it would be a reasonable fallback.
This patch implements this idea. GNU Source Highlight is preferred,
but if it is unavailable (or fails), the extension languages are
tried. This patch also implements support for Pygments.
Something similar could be done for Guile, using:
https://dthompson.us/projects/guile-syntax-highlight.html
However, I don't know enough about Guile internals to make this
happen, so I have not done it here.
gdb/ChangeLog
2020-01-21 Tom Tromey <tromey@adacore.com>
* source-cache.c (source_cache::ensure): Call ext_lang_colorize.
* python/python.c (python_extension_ops): Update.
(gdbpy_colorize): New function.
* python/lib/gdb/__init__.py (colorize): New function.
* extension.h (ext_lang_colorize): Declare.
* extension.c (ext_lang_colorize): New function.
* extension-priv.h (struct extension_language_ops) <colorize>: New
member.
* cli/cli-style.c (_initialize_cli_style): Update help text.
Change-Id: I5e21623ee05f1f66baaa6deaeca78b578c031bf4
2020-01-03 13:59:27 -07:00
|
|
|
if (ext_contents.has_value ())
|
2023-10-17 11:38:06 +02:00
|
|
|
{
|
|
|
|
|
contents = std::move (*ext_contents);
|
gdb: check styled status of source cache entries
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 e5348a7ab3f11f4c096ee4ebcdb9eb2663337357
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>
2025-02-12 14:29:01 +00:00
|
|
|
styled_p = true;
|
2023-10-17 11:38:06 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
gdb: check styled status of source cache entries
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 e5348a7ab3f11f4c096ee4ebcdb9eb2663337357
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>
2025-02-12 14:29:01 +00:00
|
|
|
if (!styled_p)
|
2023-10-17 11:38:06 +02:00
|
|
|
{
|
|
|
|
|
/* Styling failed. Styling can fail for instance for these
|
|
|
|
|
reasons:
|
|
|
|
|
- the language is not supported.
|
|
|
|
|
- the language cannot not be auto-detected from the file name.
|
|
|
|
|
- no stylers available.
|
|
|
|
|
|
|
|
|
|
Since styling failed, don't try styling the file again after it
|
|
|
|
|
drops from the cache.
|
|
|
|
|
|
|
|
|
|
Note that clearing the source cache also clears
|
|
|
|
|
m_no_styling_files. */
|
|
|
|
|
m_no_styling_files.insert (fullname);
|
Allow use of Pygments to colorize source code
While GNU Source Highlight is good, it's also difficult to build and
distribute. For one thing, it needs Boost. For another, it has an
unusual configuration and installation setup.
Pygments, a Python library, doesn't suffer from these issues, and so I
thought it would be a reasonable fallback.
This patch implements this idea. GNU Source Highlight is preferred,
but if it is unavailable (or fails), the extension languages are
tried. This patch also implements support for Pygments.
Something similar could be done for Guile, using:
https://dthompson.us/projects/guile-syntax-highlight.html
However, I don't know enough about Guile internals to make this
happen, so I have not done it here.
gdb/ChangeLog
2020-01-21 Tom Tromey <tromey@adacore.com>
* source-cache.c (source_cache::ensure): Call ext_lang_colorize.
* python/python.c (python_extension_ops): Update.
(gdbpy_colorize): New function.
* python/lib/gdb/__init__.py (colorize): New function.
* extension.h (ext_lang_colorize): Declare.
* extension.c (ext_lang_colorize): New function.
* extension-priv.h (struct extension_language_ops) <colorize>: New
member.
* cli/cli-style.c (_initialize_cli_style): Update help text.
Change-Id: I5e21623ee05f1f66baaa6deaeca78b578c031bf4
2020-01-03 13:59:27 -07:00
|
|
|
}
|
|
|
|
|
}
|
2018-10-09 22:21:05 -06:00
|
|
|
|
gdb: check styled status of source cache entries
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 e5348a7ab3f11f4c096ee4ebcdb9eb2663337357
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>
2025-02-12 14:29:01 +00:00
|
|
|
source_text result
|
|
|
|
|
= { std::move (fullname), std::move (contents), styled_p };
|
2019-07-22 12:41:23 -06:00
|
|
|
m_source_map.push_back (std::move (result));
|
|
|
|
|
|
|
|
|
|
if (m_source_map.size () > MAX_ENTRIES)
|
gdb: erase items from the source_cache::m_offset_cache
The source_cache class has two member variables m_source_map, which
stores the file contents, and m_offset_cache, which stores offsets
into the file contents.
As source files are read the contents of the file, as well as the
offset data, are stored in the cache using these two member variables.
Whenever GDB needs either the files contents, or the offset data,
source_cache::ensure is called. This function looks for the file in
m_source_map, and if it's found then this implies the file is also in
m_offset_cache, and we're done.
If the file is not in m_source_map then GDB calls
source_cache::get_plain_source_lines to open the file and read its
contents. ::get_plain_source_lines also calculates the offset data,
which is then inserted into m_offset_cache.
Back in ::ensure, the file contents are added into m_source_map. And
finally, if m_source_map contains more than MAX_ENTRIES, an entry is
removed from m_source_map.
The problem is entries are not removed from m_offset_cache at the same
time.
This means that if a program contains enough source files, GDB will
hold at most MAX_ENTRIES cached source file contents, but can contain
offsets data for every source file.
Now, the offsets data is going to be smaller than the cached file
contents, so maybe there's no harm here. But, when we reload the file
contents we always recalculate the offsets data. And, when we
::get_line_charpos asking for offset data we still call ::ensure which
will ends up loading and caching the file contents.
So, given the current code does the work of reloading the offset data
anyway, we may as well save memory by capping m_offset_cache to
MAX_ENTRIES just like we do m_source_map.
That's what this commit does.
There should be no user visible changes after this commit, except for
ever so slightly lower memory usage in some cases.
2021-11-26 14:34:27 +00:00
|
|
|
{
|
|
|
|
|
auto iter = m_source_map.begin ();
|
|
|
|
|
m_offset_cache.erase (iter->fullname);
|
|
|
|
|
m_source_map.erase (iter);
|
|
|
|
|
}
|
2019-07-22 12:41:23 -06:00
|
|
|
|
|
|
|
|
return true;
|
2018-10-09 22:21:05 -06:00
|
|
|
}
|
2019-07-23 08:22:50 -06:00
|
|
|
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
/* See source-cache.h. */
|
|
|
|
|
|
|
|
|
|
bool
|
|
|
|
|
source_cache::get_line_charpos (struct symtab *s,
|
|
|
|
|
const std::vector<off_t> **offsets)
|
|
|
|
|
{
|
gdb: Catch exceptions if the source file is not found
The source_cache::ensure method may throw an exception through
the invocation of source_cache::get_plain_source_lines. This
happens when the source file is not found. The expected behaviour
of "ensure" is only returning "true" or "false" according to the
documentation in the header file.
So far, if gdb is in source layout and a file is missing, you see
some outputs like below:
,---------------------------------------------.
| test.c file is loaded in the source window. |
| |
| int main() |
| ... |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| /path/to/crt0.S: No such file or directory. |
| (gdb) p/x $pc |
| $1 = 0x124 |
| (gdb) n |
| /path/to/crt0.S: No such file or directory. |
| (gdb) p/x $pc |
| $2 = 0x128 |
| (gdb) [pressing arrow-down key] |
| (gdb) terminate called after throwing an |
| instance of 'gdb_exception_error' |
`---------------------------------------------'
Other issues have been encountered as well [1].
The patch from Pedro [2] which is about preventing exceptions
from crossing the "readline" mitigates the situation by not
causing gdb crash, but still there are lots of errors printed:
,---------------------------------------------.
| test.c file is loaded in the source window. |
| |
| int main() |
| ... |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-down key] |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-down key] |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-up key] |
| /path/to/crt0.S: No such file or directory. |
`---------------------------------------------'
With the changes of this patch, the behavior is like:
,---------------------------------------------.
| initially, source window is empty because |
| crt0.S is not found and according to the |
| program counter that is the piece of code |
| being executed. |
| |
| later, when we break at main (see commands |
| below), this window will be filled with the |
| the contents of test.c file. |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| (gdb) p/x $pc |
| $1 = 0x124 |
| (gdb) n |
| (gdb) p/x $pc |
| $2 = 0x128 |
| (gdb) b main |
| Breakpoint 1 at 0x334: file test.c, line 8. |
| (gdb) cont |
| Continuing. |
| Breakpoint 1, main () at hello.c:8 |
| (gdb) n |
| (gdb) |
`---------------------------------------------'
There is no crash and the error message is completely
gone. Maybe it is good practice that the error is
shown inside the source window.
I tested this change against gdb.base/list-missing-source.exp
and there was no regression.
[1]
It has also been observed in the past that the register
values are not transferred from qemu's gdb stub, see:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/226
[2]
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=2f267673f0fdee9287e6d404ecd4f2d29da0d2f2
gdb/ChangeLog:
* source-cache.c (source_cache::ensure): Surround
get_plain_source_lines with a try/catch.
(source_cache::get_line_charpos): Get rid of try/catch
and only check for the return value of "ensure".
* tui/tui-source.c (tui_source_window::set_contents):
Simplify "nlines" calculation.
gdb/testsuite/ChangeLog:
* gdb.tui/tui-missing-src.exp: Add the "missing source
file" test for the TUI.
2020-02-06 16:20:37 +01:00
|
|
|
std::string fullname = symtab_to_fullname (s);
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
|
gdb: Catch exceptions if the source file is not found
The source_cache::ensure method may throw an exception through
the invocation of source_cache::get_plain_source_lines. This
happens when the source file is not found. The expected behaviour
of "ensure" is only returning "true" or "false" according to the
documentation in the header file.
So far, if gdb is in source layout and a file is missing, you see
some outputs like below:
,---------------------------------------------.
| test.c file is loaded in the source window. |
| |
| int main() |
| ... |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| /path/to/crt0.S: No such file or directory. |
| (gdb) p/x $pc |
| $1 = 0x124 |
| (gdb) n |
| /path/to/crt0.S: No such file or directory. |
| (gdb) p/x $pc |
| $2 = 0x128 |
| (gdb) [pressing arrow-down key] |
| (gdb) terminate called after throwing an |
| instance of 'gdb_exception_error' |
`---------------------------------------------'
Other issues have been encountered as well [1].
The patch from Pedro [2] which is about preventing exceptions
from crossing the "readline" mitigates the situation by not
causing gdb crash, but still there are lots of errors printed:
,---------------------------------------------.
| test.c file is loaded in the source window. |
| |
| int main() |
| ... |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-down key] |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-down key] |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-up key] |
| /path/to/crt0.S: No such file or directory. |
`---------------------------------------------'
With the changes of this patch, the behavior is like:
,---------------------------------------------.
| initially, source window is empty because |
| crt0.S is not found and according to the |
| program counter that is the piece of code |
| being executed. |
| |
| later, when we break at main (see commands |
| below), this window will be filled with the |
| the contents of test.c file. |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| (gdb) p/x $pc |
| $1 = 0x124 |
| (gdb) n |
| (gdb) p/x $pc |
| $2 = 0x128 |
| (gdb) b main |
| Breakpoint 1 at 0x334: file test.c, line 8. |
| (gdb) cont |
| Continuing. |
| Breakpoint 1, main () at hello.c:8 |
| (gdb) n |
| (gdb) |
`---------------------------------------------'
There is no crash and the error message is completely
gone. Maybe it is good practice that the error is
shown inside the source window.
I tested this change against gdb.base/list-missing-source.exp
and there was no regression.
[1]
It has also been observed in the past that the register
values are not transferred from qemu's gdb stub, see:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/226
[2]
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=2f267673f0fdee9287e6d404ecd4f2d29da0d2f2
gdb/ChangeLog:
* source-cache.c (source_cache::ensure): Surround
get_plain_source_lines with a try/catch.
(source_cache::get_line_charpos): Get rid of try/catch
and only check for the return value of "ensure".
* tui/tui-source.c (tui_source_window::set_contents):
Simplify "nlines" calculation.
gdb/testsuite/ChangeLog:
* gdb.tui/tui-missing-src.exp: Add the "missing source
file" test for the TUI.
2020-02-06 16:20:37 +01:00
|
|
|
auto iter = m_offset_cache.find (fullname);
|
|
|
|
|
if (iter == m_offset_cache.end ())
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
{
|
gdb: Catch exceptions if the source file is not found
The source_cache::ensure method may throw an exception through
the invocation of source_cache::get_plain_source_lines. This
happens when the source file is not found. The expected behaviour
of "ensure" is only returning "true" or "false" according to the
documentation in the header file.
So far, if gdb is in source layout and a file is missing, you see
some outputs like below:
,---------------------------------------------.
| test.c file is loaded in the source window. |
| |
| int main() |
| ... |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| /path/to/crt0.S: No such file or directory. |
| (gdb) p/x $pc |
| $1 = 0x124 |
| (gdb) n |
| /path/to/crt0.S: No such file or directory. |
| (gdb) p/x $pc |
| $2 = 0x128 |
| (gdb) [pressing arrow-down key] |
| (gdb) terminate called after throwing an |
| instance of 'gdb_exception_error' |
`---------------------------------------------'
Other issues have been encountered as well [1].
The patch from Pedro [2] which is about preventing exceptions
from crossing the "readline" mitigates the situation by not
causing gdb crash, but still there are lots of errors printed:
,---------------------------------------------.
| test.c file is loaded in the source window. |
| |
| int main() |
| ... |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-down key] |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-down key] |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-up key] |
| /path/to/crt0.S: No such file or directory. |
`---------------------------------------------'
With the changes of this patch, the behavior is like:
,---------------------------------------------.
| initially, source window is empty because |
| crt0.S is not found and according to the |
| program counter that is the piece of code |
| being executed. |
| |
| later, when we break at main (see commands |
| below), this window will be filled with the |
| the contents of test.c file. |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| (gdb) p/x $pc |
| $1 = 0x124 |
| (gdb) n |
| (gdb) p/x $pc |
| $2 = 0x128 |
| (gdb) b main |
| Breakpoint 1 at 0x334: file test.c, line 8. |
| (gdb) cont |
| Continuing. |
| Breakpoint 1, main () at hello.c:8 |
| (gdb) n |
| (gdb) |
`---------------------------------------------'
There is no crash and the error message is completely
gone. Maybe it is good practice that the error is
shown inside the source window.
I tested this change against gdb.base/list-missing-source.exp
and there was no regression.
[1]
It has also been observed in the past that the register
values are not transferred from qemu's gdb stub, see:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/226
[2]
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=2f267673f0fdee9287e6d404ecd4f2d29da0d2f2
gdb/ChangeLog:
* source-cache.c (source_cache::ensure): Surround
get_plain_source_lines with a try/catch.
(source_cache::get_line_charpos): Get rid of try/catch
and only check for the return value of "ensure".
* tui/tui-source.c (tui_source_window::set_contents):
Simplify "nlines" calculation.
gdb/testsuite/ChangeLog:
* gdb.tui/tui-missing-src.exp: Add the "missing source
file" test for the TUI.
2020-02-06 16:20:37 +01:00
|
|
|
if (!ensure (s))
|
|
|
|
|
return false;
|
|
|
|
|
iter = m_offset_cache.find (fullname);
|
|
|
|
|
/* cache_source_text ensured this was entered. */
|
|
|
|
|
gdb_assert (iter != m_offset_cache.end ());
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
}
|
gdb: Catch exceptions if the source file is not found
The source_cache::ensure method may throw an exception through
the invocation of source_cache::get_plain_source_lines. This
happens when the source file is not found. The expected behaviour
of "ensure" is only returning "true" or "false" according to the
documentation in the header file.
So far, if gdb is in source layout and a file is missing, you see
some outputs like below:
,---------------------------------------------.
| test.c file is loaded in the source window. |
| |
| int main() |
| ... |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| /path/to/crt0.S: No such file or directory. |
| (gdb) p/x $pc |
| $1 = 0x124 |
| (gdb) n |
| /path/to/crt0.S: No such file or directory. |
| (gdb) p/x $pc |
| $2 = 0x128 |
| (gdb) [pressing arrow-down key] |
| (gdb) terminate called after throwing an |
| instance of 'gdb_exception_error' |
`---------------------------------------------'
Other issues have been encountered as well [1].
The patch from Pedro [2] which is about preventing exceptions
from crossing the "readline" mitigates the situation by not
causing gdb crash, but still there are lots of errors printed:
,---------------------------------------------.
| test.c file is loaded in the source window. |
| |
| int main() |
| ... |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-down key] |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-down key] |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-up key] |
| /path/to/crt0.S: No such file or directory. |
`---------------------------------------------'
With the changes of this patch, the behavior is like:
,---------------------------------------------.
| initially, source window is empty because |
| crt0.S is not found and according to the |
| program counter that is the piece of code |
| being executed. |
| |
| later, when we break at main (see commands |
| below), this window will be filled with the |
| the contents of test.c file. |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| (gdb) p/x $pc |
| $1 = 0x124 |
| (gdb) n |
| (gdb) p/x $pc |
| $2 = 0x128 |
| (gdb) b main |
| Breakpoint 1 at 0x334: file test.c, line 8. |
| (gdb) cont |
| Continuing. |
| Breakpoint 1, main () at hello.c:8 |
| (gdb) n |
| (gdb) |
`---------------------------------------------'
There is no crash and the error message is completely
gone. Maybe it is good practice that the error is
shown inside the source window.
I tested this change against gdb.base/list-missing-source.exp
and there was no regression.
[1]
It has also been observed in the past that the register
values are not transferred from qemu's gdb stub, see:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/226
[2]
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=2f267673f0fdee9287e6d404ecd4f2d29da0d2f2
gdb/ChangeLog:
* source-cache.c (source_cache::ensure): Surround
get_plain_source_lines with a try/catch.
(source_cache::get_line_charpos): Get rid of try/catch
and only check for the return value of "ensure".
* tui/tui-source.c (tui_source_window::set_contents):
Simplify "nlines" calculation.
gdb/testsuite/ChangeLog:
* gdb.tui/tui-missing-src.exp: Add the "missing source
file" test for the TUI.
2020-02-06 16:20:37 +01:00
|
|
|
|
|
|
|
|
*offsets = &iter->second;
|
|
|
|
|
return true;
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* A helper function that extracts the desired source lines from TEXT,
|
|
|
|
|
putting them into LINES_OUT. The arguments are as for
|
|
|
|
|
get_source_lines. Returns true on success, false if the line
|
|
|
|
|
numbers are invalid. */
|
|
|
|
|
|
|
|
|
|
static bool
|
|
|
|
|
extract_lines (const std::string &text, int first_line, int last_line,
|
|
|
|
|
std::string *lines_out)
|
|
|
|
|
{
|
|
|
|
|
int lineno = 1;
|
|
|
|
|
std::string::size_type pos = 0;
|
|
|
|
|
std::string::size_type first_pos = std::string::npos;
|
|
|
|
|
|
|
|
|
|
while (pos != std::string::npos && lineno <= last_line)
|
|
|
|
|
{
|
|
|
|
|
std::string::size_type new_pos = text.find ('\n', pos);
|
|
|
|
|
|
|
|
|
|
if (lineno == first_line)
|
|
|
|
|
first_pos = pos;
|
|
|
|
|
|
|
|
|
|
pos = new_pos;
|
|
|
|
|
if (lineno == last_line || pos == std::string::npos)
|
|
|
|
|
{
|
|
|
|
|
/* A newline at the end does not start a new line. */
|
|
|
|
|
if (first_pos == std::string::npos
|
|
|
|
|
|| first_pos == text.size ())
|
|
|
|
|
return false;
|
|
|
|
|
if (pos == std::string::npos)
|
|
|
|
|
pos = text.size ();
|
|
|
|
|
else
|
|
|
|
|
++pos;
|
|
|
|
|
*lines_out = text.substr (first_pos, pos - first_pos);
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
++lineno;
|
|
|
|
|
++pos;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* See source-cache.h. */
|
|
|
|
|
|
|
|
|
|
bool
|
|
|
|
|
source_cache::get_source_lines (struct symtab *s, int first_line,
|
|
|
|
|
int last_line, std::string *lines)
|
|
|
|
|
{
|
|
|
|
|
if (first_line < 1 || last_line < 1 || first_line > last_line)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
if (!ensure (s))
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
return extract_lines (m_source_map.back ().contents,
|
|
|
|
|
first_line, last_line, lines);
|
|
|
|
|
}
|
|
|
|
|
|
2021-11-26 13:51:36 +00:00
|
|
|
/* Implement 'maint flush source-cache' command. */
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
source_cache_flush_command (const char *command, int from_tty)
|
|
|
|
|
{
|
|
|
|
|
forget_cached_source_info ();
|
2022-01-02 11:46:15 -07:00
|
|
|
gdb_printf (_("Source cache flushed.\n"));
|
2021-11-26 13:51:36 +00:00
|
|
|
}
|
|
|
|
|
|
2019-07-23 08:22:50 -06:00
|
|
|
#if GDB_SELF_TEST
|
|
|
|
|
namespace selftests
|
|
|
|
|
{
|
|
|
|
|
static void extract_lines_test ()
|
|
|
|
|
{
|
|
|
|
|
std::string input_text = "abc\ndef\nghi\njkl\n";
|
Add file offsets to the source cache
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.
2019-07-22 14:31:43 -06:00
|
|
|
std::string result;
|
|
|
|
|
|
|
|
|
|
SELF_CHECK (extract_lines (input_text, 1, 1, &result)
|
|
|
|
|
&& result == "abc\n");
|
|
|
|
|
SELF_CHECK (!extract_lines (input_text, 2, 1, &result));
|
|
|
|
|
SELF_CHECK (extract_lines (input_text, 1, 2, &result)
|
|
|
|
|
&& result == "abc\ndef\n");
|
|
|
|
|
SELF_CHECK (extract_lines ("abc", 1, 1, &result)
|
|
|
|
|
&& result == "abc");
|
2019-07-23 08:22:50 -06:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2025-05-22 11:54:16 -06:00
|
|
|
INIT_GDB_FILE (source_cache)
|
2019-07-23 08:22:50 -06:00
|
|
|
{
|
2021-11-26 13:51:36 +00:00
|
|
|
add_cmd ("source-cache", class_maintenance, source_cache_flush_command,
|
|
|
|
|
_("Force gdb to flush its source code cache."),
|
|
|
|
|
&maintenanceflushlist);
|
|
|
|
|
|
2021-11-26 15:13:43 +00:00
|
|
|
/* All the 'maint set|show gnu-source-highlight' sub-commands. */
|
|
|
|
|
static struct cmd_list_element *maint_set_gnu_source_highlight_cmdlist;
|
|
|
|
|
static struct cmd_list_element *maint_show_gnu_source_highlight_cmdlist;
|
|
|
|
|
|
|
|
|
|
/* Adds 'maint set|show gnu-source-highlight'. */
|
|
|
|
|
add_setshow_prefix_cmd ("gnu-source-highlight", class_maintenance,
|
|
|
|
|
_("Set gnu-source-highlight specific variables."),
|
|
|
|
|
_("Show gnu-source-highlight specific variables."),
|
|
|
|
|
&maint_set_gnu_source_highlight_cmdlist,
|
|
|
|
|
&maint_show_gnu_source_highlight_cmdlist,
|
|
|
|
|
&maintenance_set_cmdlist,
|
|
|
|
|
&maintenance_show_cmdlist);
|
|
|
|
|
|
|
|
|
|
/* Adds 'maint set|show gnu-source-highlight enabled'. */
|
|
|
|
|
add_setshow_boolean_cmd ("enabled", class_maintenance,
|
|
|
|
|
&use_gnu_source_highlight, _("\
|
|
|
|
|
Set whether the GNU Source Highlight library should be used."), _("\
|
|
|
|
|
Show whether the GNU Source Highlight library is being used."),_("\
|
|
|
|
|
When enabled, GDB will use the GNU Source Highlight library to apply\n\
|
|
|
|
|
styling to source code lines that are shown."),
|
|
|
|
|
set_use_gnu_source_highlight_enabled,
|
|
|
|
|
show_use_gnu_source_highlight_enabled,
|
|
|
|
|
&maint_set_gnu_source_highlight_cmdlist,
|
|
|
|
|
&maint_show_gnu_source_highlight_cmdlist);
|
|
|
|
|
|
|
|
|
|
/* Enable use of GNU Source Highlight library, if we have it. */
|
|
|
|
|
#ifdef HAVE_SOURCE_HIGHLIGHT
|
|
|
|
|
use_gnu_source_highlight = true;
|
|
|
|
|
#endif
|
|
|
|
|
|
2019-07-23 08:22:50 -06:00
|
|
|
#if GDB_SELF_TEST
|
|
|
|
|
selftests::register_test ("source-cache", selftests::extract_lines_test);
|
2023-10-24 14:31:34 +02:00
|
|
|
#ifdef HAVE_SOURCE_HIGHLIGHT
|
|
|
|
|
selftests::register_test ("gnu-source-highlight",
|
|
|
|
|
selftests::gnu_source_highlight_test);
|
|
|
|
|
#endif
|
2019-07-23 08:22:50 -06:00
|
|
|
#endif
|
|
|
|
|
}
|