919adfe840
29082 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Tom Tromey
|
919adfe840 |
Move gdbserver to top level
This patch moves gdbserver to the top level. This patch is as close to a pure move as possible -- gdbserver still builds its own variant of gnulib and gdbsupport. Changing this will be done in a separate patch. [v2] Note that, per Simon's review comment, this patch changes the tree so that gdbserver is not built for or1k or score. This makes sense, because there is apparently not actually a gdbserver port here. [v3] This version of the patch also splits out some configury into a new file, gdbserver/configure.host, so that the top-level configure script can simply rely on it in order to decide whether gdbserver should be built. [v4] This version adds documentation and removes some unnecessary top-level dependencies. [v5] Update docs to mention "make all-gdbserver" and change how top-level configure decides whether to build gdbserver, switching to a single, shared script. Tested by the buildbot. ChangeLog 2020-02-07 Tom Tromey <tom@tromey.com> Pedro Alves <palves@redhat.com> * src-release.sh (GDB_SUPPORT_DIRS): Add gdbserver. * gdbserver: New directory, moved from gdb/gdbserver. * configure.ac (host_tools): Add gdbserver. Only build gdbserver on certain systems. * Makefile.in, configure: Rebuild. * Makefile.def (host_modules, dependencies): Add gdbserver. * MAINTAINERS: Add gdbserver. gdb/ChangeLog 2020-02-07 Tom Tromey <tom@tromey.com> * README: Update gdbserver documentation. * gdbserver: Move to top level. * configure.tgt (build_gdbserver): Remove. * configure.ac: Remove --enable-gdbserver. * configure: Rebuild. * Makefile.in (distclean): Don't mention gdbserver. Change-Id: I826b7565b54604711dc7a11edea0499cd51ff39e |
||
Shahab Vahedi
|
1d5d29e73f |
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. |
||
|
Shahab Vahedi
|
6eb1129ce0 |
gdb: Add myself as one of GDB maintainer
May this be the beginning of a great flow of patches. 2020-02-06 Shahab Vahedi <shahab@synopsys.com> * MAINTAINERS (Write After Approval): Add myself. |
||
Christian Biesinger
|
c6a42d11ac |
Fix base class function call
This was a typo introduced in
|
||
|
Christian Biesinger
|
c8ecdda6b6 |
Fix header guard name in #endif comment
Makes the comment match the macro name in the #define/#ifdef. gdb/ChangeLog: 2020-02-05 Christian Biesinger <cbiesinger@google.com> * ppc-nbsd-tdep.h: Fix macro name in #endif comment. Change-Id: If7b2e49e65495b8eb9ed7b6c9a11277579a93a05 |
||
Maciej W. Rozycki
|
f6480e7000 |
RISC-V/Linux/native: Factor out target description determination
In preparation for RISC-V/Linux `gdbserver' support factor out parts of native target description determination code that can be shared between the programs. gdb/ * nat/riscv-linux-tdesc.h: New file. * nat/riscv-linux-tdesc.c: New file, taking code from... * riscv-linux-nat.c (riscv_linux_nat_target::read_description): ... here. * configure.nat <linux> <riscv*>: Add nat/riscv-linux-tdesc.o to NATDEPFILES. |
||
Andrew Burgess
|
dcc9fbc6da |
gdb/sim: Assert that the simulator ptid is not null_ptid
We assign the simulator inferior a fake ptid. If this ptid is ever set to null_ptid then we are going to run into problems - the simulator ptid is what we return from gdbsim_target::wait, and this in turn is used to look up the inferior data with a call to find_inferior_pid, which asserts the pid is not 0 (which it is in null_pid). This commit adds an assert that the simulator's fake pid is not null_ptid. There should be no user visible changes after this commit. gdb/ChangeLog: * remote-sim.c (sim_inferior_data::sim_inferior_data): Assert that we don't set the fake simulator ptid to the null_ptid. Change-Id: I6e08effe70e70855aea13c9caf4fd6913d5af56d |
||
Simon Marchi
|
719546c44f |
Change ints to bools around thread_info executing/resumed
Switch thread_info::resumed to bool (thread_info::executing already is a bool), and try to change everything more or less related to that to consistently use true/false instead of 1/0. gdb/ChangeLog: * fork-child.c (gdb_startup_inferior): Use bool instead of int. * gdbthread.h (class thread_info) <resumed>: Likewise. * infrun.c (resume_1): Likewise. (proceed): Likewise. (infrun_thread_stop_requested): Likewise. (stop_all_threads): Likewise. (handle_inferior_event): Likewise. (restart_threads): Likewise. (finish_step_over): Likewise. (keep_going_stepped_thread): Likewise. * linux-nat.c (attach_proc_task_lwp_callback): Likewise. (linux_handle_extended_wait): Likewise. * record-btrace.c (get_thread_current_frame_id): Likewise. * record-full.c (record_full_wait_1): Likewise. * remote.c (remote_target::process_initial_stop_replies): Likewise. * target.c (target_resume): Likewise. * thread.c (set_running_thread): Likewise. |
||
Alok Kumar Sharma
|
e409c542cc |
Fixed gdb to print arrays with very high indexes
In the function f77_print_array_1, the variable 'i' which holds the
index is of datatype 'int', while bounds are of datatype LONGEST. Due to
size of int being smaller than LONGEST, the variable 'i' stores
incorrect values for high indexes (higher than max limit of int). Due
to this issue in sources, two abnormal behaviors are seen while printing
arrays with high indexes (please check array-bounds-high.f90) For high
indexes with negative sign, gdb prints empty array even if the array has
elements.
(gdb) p arr
$1 = ()
For high indexes with positive sign, gdb crashes. We have now changed
the datatype of 'i' to LONGEST which is same as datatype of bounds.
gdb/ChangeLog:
* f-valprint.c (f77_print_array_1): Changed datatype of index
variable to LONGEST from int to enable it to contain bound
values correctly.
gdb/testsuite/ChangeLog:
* gdb.fortran/array-bounds-high.exp: New file.
* gdb.fortran/array-bounds-high.f90: New file.
Change-Id: Ie2dce9380a249e634e2684b9c90f225e104369b7
|
||
|
Maciej W. Rozycki
|
ee98c0daf9 |
RISC-V/Linux/native: Determine FLEN dynamically
Fix RISC-V native Linux support to handle a 64-bit FPU (FLEN == 64) with both RV32 and RV64 systems, which is a part of the current Linux ABI for hard-float systems, rather than assuming that (FLEN == XLEN) in target description determination and that (FLEN == 64) in register access. We can do better however and not rely on any particular value of FLEN and probe for it dynamically, by observing that the PTRACE_GETREGSET ptrace(2) call will only accept an exact regset size, and that will reflect FLEN. Therefore iterate over the call in target description determination with a geometrically increasing regset size until a match is marked by a successful ptrace(2) call completion or we run beyond the maximum size we can support. Update register accessors accordingly, using FLEN determined to size the buffer used for NT_PRSTATUS requests and then to exchange data with the regcache. Also handle a glibc bug where ELF_NFPREG is defined in terms of NFPREG, however NFPREG is nowhere defined. gdb/ * riscv-linux-nat.c [!NFPREG] (NFPREG): New macro. (supply_fpregset_regnum, fill_fpregset): Handle regset buffer offsets according to FLEN determined. (riscv_linux_nat_target::read_description): Determine FLEN dynamically. (riscv_linux_nat_target::fetch_registers): Size regset buffer according to FLEN determined. (riscv_linux_nat_target::store_registers): Likewise. |
||
|
Shahab Vahedi
|
aa66aac47b |
gdb: Do not print empty-group regs when printing general ones
When the command "info registers" (same as "info registers general"),
is issued, _all_ the registers from a tdesc XML are printed. This
includes the registers with empty register groups (set as "") which
are supposed to be only printed by "info registers all" (or "info
all-registers").
This bug got introduced after all the overhauls that the
tdesc_register_in_reggroup_p() went through. You can see that the
logic of tdesc_register_in_reggroup_p() did NOT remain the same after
all those changes:
git difftool c9c895b9666..HEAD -- gdb/target-descriptions.c
With the current implementation, when the reg->group is an empty
string, this function returns -1, while in the working revision
(
|
||
Tom Tromey
|
fd9faca826 |
Fix ravenscar-thread.c for multi-target
ravenscar-thread.c needed a change to adapt to multi-target: ravenscar_thread_target::mourn_inferior called the mourn_inferior method on the target beneat -- but when the target beneath was the remote target, this resulted in the ravenscar target being deleted. Switching the order of the calls to unpush_target and the beneath's mourn_inferior fixes this problem. gdb/ChangeLog 2020-01-31 Tom Tromey <tromey@adacore.com> * ravenscar-thread.c (ravenscar_thread_target::mourn_inferior): Call beneath target's mourn_inferior after unpushing. Change-Id: Ia80380515c403adc40505a6b3420c9cb35754370 |
||
|
Andrew Burgess
|
42330a681a |
gdb/tui: Disassembler scrolling of very small programs
In TUI mode, if the disassembly output for the program is less than one screen long, then currently if the user scrolls down until on the last assembly instruction is displayed and then tries to scroll up using Page-Up, the display doesn't update - they are stuck viewing the last line. If the user tries to scroll up using the Up-Arrow, then the display scrolls normally. What is happening is on the Page-Up we ask GDB to scroll backward the same number of lines as the height of the TUI ASM window. The back scanner, which looks for a good place to start disassembling, fails to find a starting address which will provide the requested number of new lines before we get back to the original starting address (which is not surprising, our whole program contains less than a screen height of instructions), as a result the back scanner gives up and returns the original starting address. When we scroll with Up-Arrow we only ask the back scanner to find 1 new instruction, which it manages to do, so this scroll works. The solution here is, when we fail to find enough instructions, to return the lowest address we did manage to find. This will ensure we jump to the lowest possible address in the disassembly output. gdb/ChangeLog: PR tui/9765 * tui/tui-disasm.c (tui_find_disassembly_address): If we don't have enough lines to fill the screen, still return the lowest address we found. gdb/testsuite/ChangeLog: PR tui/9765 * gdb.tui/tui-layout-asm-short-prog.S: New file. * gdb.tui/tui-layout-asm-short-prog.exp: New file. Change-Id: I6a6a7972c68a0559e9717fd8d82870b669a40af3 |
||
|
Andrew Burgess
|
7a27a45bc6 |
gdb/tui: Update help text for scroll commands
GDB has some commands ('+', '-', '<', and '>') for scrolling the SRC
and ASM TUI windows from the CMD window, however the help text for
these commands lists the arguments in the wrong order.
This commit updates the help text to match how GDB actually works, and
also extends the text to describe what the arguments mean, and what
the defaults are.
There should be no change in GDBs functionality after this commit.
gdb/ChangeLog:
* tui/tui-win.c (_initialize_tui_win): Update help text for '+',
'-', '<', and '>' commands.
Change-Id: Ib2624891de1f4ba983838822206304e4c3ed982e
|
||
Pedro Alves
|
c47f70e2ce |
Fix -Werror-stringop error on infcmd.c:construct_inferior_arguments
While testing a GCC 10 build of our git HEAD, Sergio noticed an error
triggered by -Werror-stringop on
infcmd.c:construct_inferior_arguments. One of the things the function
does is calculate the length of the string that will hold the
inferior's arguments. GCC warns us that 'length' can be 0, which can
lead to undesired behaviour:
../../gdb/infcmd.c: In function 'char* construct_inferior_arguments(int, char**)':
../../gdb/infcmd.c:369:17: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
369 | result[0] = '\0';
| ~~~~~~~~~~^~~~~~
../../gdb/infcmd.c:368:33: note: at offset 0 to an object with size 0 allocated by 'xmalloc' here
368 | result = (char *) xmalloc (length);
| ~~~~~~~~^~~~~~~~
The solution here is to assert that 'argc' is greater than 0 on entry,
which makes GCC understand that the loops always run at least once,
and thus 'length' is always > 0.
Tested by rebuilding.
gdb/ChangeLog:
2020-01-29 Pedro Alves <palves@redhat.com>
Sergio Durigan Junior <sergiodj@redhat.com>
* infcmd.c (construct_inferior_arguments): Assert that
'argc' is greater than 0.
Change-Id: Ide8407cbedcb4921de1843a6a15bbcb7676c7d26
|
||
Luis Machado
|
5133a31537 |
Recognize more program breakpoint patterns
New in v3:
- Code cleanups based on reviews.
New in v2:
- Fixed misc problems based on reviews.
- Switched to using gdbarch_program_breakpoint_here_p as opposed to
gdbarch_insn_is_breakpoint.
- Fixed matching of brk instructions. Previously the mask was incorrect, which
was showing up as a few failures in the testsuite. Now it is clean.
- New testcase (separate patch).
- Moved program_breakpoint_here () to arch-utils.c and made it the default
implementation of gdbarch_program_breakpoint_here_p.
--
It was reported to me that program breakpoints (permanent ones inserted into
the code itself) other than the one GDB uses for AArch64 (0xd4200000) do not
generate visible stops when continuing, and GDB will continue spinning
infinitely.
This happens because GDB, upon hitting one of those program breakpoints, thinks
the SIGTRAP came from a delayed breakpoint hit...
(gdb) x/i $pc
=> 0x4005c0 <problem_function>: brk #0x90f
(gdb) c
Continuing.
infrun: clear_proceed_status_thread (process 14198)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming process 14198
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0
infrun: infrun_async(1)
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: 14198.14198.0 [process 14198],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: delayed software breakpoint trap, ignoring
infrun: no stepping, continue
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: 14198.14198.0 [process 14198],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: delayed software breakpoint trap, ignoring
infrun: no stepping, continue
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: 14198.14198.0 [process 14198],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: delayed software breakpoint trap, ignoring
infrun: no stepping, continue
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: 14198.14198.0 [process 14198],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: delayed software breakpoint trap, ignoring
infrun: no stepping, continue
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: 14198.14198.0 [process 14198],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
...
... which is not the case.
If the program breakpoint is one GDB recognizes, then it will stop when it
hits it.
(gdb) x/i $pc
=> 0x4005c0 <problem_function>: brk #0x0
(gdb) c
Continuing.
infrun: clear_proceed_status_thread (process 14193)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming process 14193
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14193] at 0x4005c0
infrun: infrun_async(1)
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: 14193.14193.0 [process 14193],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: random signal (GDB_SIGNAL_TRAP)
infrun: stop_waiting
infrun: stop_all_threads
infrun: stop_all_threads, pass=0, iterations=0
infrun: process 14193 not executing
infrun: stop_all_threads, pass=1, iterations=1
infrun: process 14193 not executing
infrun: stop_all_threads done
Program received signal SIGTRAP, Trace/breakpoint trap.
problem_function () at brk_0.c:7
7 asm("brk %0\n\t" ::"n"(0x0));
infrun: infrun_async(0)
Otherwise GDB will keep trying to resume the inferior and will keep
seeing the SIGTRAP's, without stopping.
To the user it appears GDB has gone into an infinite loop, interruptible only
by Ctrl-C.
Also, windbg seems to use a different variation of AArch64 breakpoint compared
to GDB. This causes problems when debugging Windows on ARM binaries, when
program breakpoints are being used.
The proposed patch creates a new gdbarch method (gdbarch_program_breakpoint_here_p)
that tells GDB whether the underlying instruction is a breakpoint instruction
or not.
This is more general than only checking for the instruction GDB uses as
breakpoint.
The existing logic is still preserved for targets that do not implement this
new gdbarch method.
The end result is like so:
(gdb) x/i $pc
=> 0x4005c0 <problem_function>: brk #0x90f
(gdb) c
Continuing.
infrun: clear_proceed_status_thread (process 16417)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming process 16417
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 16417] at 0x4005c0
infrun: infrun_async(1)
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: 16417.16417.0 [process 16417],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: random signal (GDB_SIGNAL_TRAP)
infrun: stop_waiting
infrun: stop_all_threads
infrun: stop_all_threads, pass=0, iterations=0
infrun: process 16417 not executing
infrun: stop_all_threads, pass=1, iterations=1
infrun: process 16417 not executing
infrun: stop_all_threads done
Program received signal SIGTRAP, Trace/breakpoint trap.
problem_function () at brk.c:7
7 asm("brk %0\n\t" ::"n"(0x900 + 0xf));
infrun: infrun_async(0)
gdb/ChangeLog:
2020-01-29 Luis Machado <luis.machado@linaro.org>
* aarch64-tdep.c (BRK_INSN_MASK): Define to 0xffe0001f.
(BRK_INSN_MASK): Define to 0xd4200000.
(aarch64_program_breakpoint_here_p): New function.
(aarch64_gdbarch_init): Set gdbarch_program_breakpoint_here_p hook.
* arch-utils.c (default_program_breakpoint_here_p): Moved from
breakpoint.c.
* arch-utils.h (default_program_breakpoint_here_p): Moved from
breakpoint.h
* breakpoint.c (bp_loc_is_permanent): Changed return type to bool and
call gdbarch_program_breakpoint_here_p.
(program_breakpoint_here): Moved to arch-utils.c, renamed to
default_program_breakpoint_here_p, changed return type to bool and
simplified.
* breakpoint.h (program_breakpoint_here): Moved prototype to
arch-utils.h, renamed to default_program_breakpoint_here_p and changed
return type to bool.
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (program_breakpoint_here_p): New method.
* infrun.c (handle_signal_stop): Call
gdbarch_program_breakpoint_here_p.
|
||
|
Tom Tromey
|
168f8c6ba0 |
Two minor changes in ctfread.c
I noticed a couple of minor issues in ctfread.c, both fixed by this patch: * ctf_fp_info was not indented properly; and * _initialize_ctfread is no longer needed gdb/ChangeLog 2020-01-26 Tom Tromey <tom@tromey.com> * ctfread.c (struct ctf_fp_info): Reindent. (_initialize_ctfread): Remove. Change-Id: I72707b74bc59e6e426b3a7bc8843d96c0d786f1e |
||
|
Tom Tromey
|
128a391fe4 |
Virtualize "readin" and "compunit_symtab"
This patch removes the "readin" and "compunit_symtab" members from partial_symtab, replacing them with methods. Then it introduces a new "standard_psymtab" class, which restores these members; and changes the symbol readers to use this intermediate class as the base class of their partial symtab subclasses. The reason for this is to make it possible for a symbol reader to implement an alternate mapping between partial and full symbol tables. This is important in order to be able to share psymtabs across objfiles -- whether a psymtab has been "readin" is objfile-dependent, as are the pointers to the full symbol tables. gdb/ChangeLog 2020-01-26 Tom Tromey <tom@tromey.com> * psymtab.c (partial_map_expand_apply) (psym_find_pc_sect_compunit_symtab, psym_lookup_symbol) (psymtab_to_symtab, psym_find_last_source_symtab, dump_psymtab) (psym_print_stats, psym_expand_symtabs_for_function) (psym_map_symbol_filenames, psym_map_matching_symbols) (psym_expand_symtabs_matching) (partial_symtab::read_dependencies, maintenance_info_psymtabs) (maintenance_check_psymtabs): Use new methods. * psympriv.h (struct partial_symtab) <readin_p, get_compunit_symtab>: New methods. <readin, compunit_symtab>: Remove members. (struct standard_psymtab): New. (struct legacy_psymtab): Derive from standard_psymtab. * dwarf2read.h (struct dwarf2_psymtab): Derive from standard_psymtab. * ctfread.c (struct ctf_psymtab): Derive from standard_psymtab. Change-Id: Idb923f196d7e03bf7cb9cfc8134ed06dd3f211ce |
||
|
Tom Tromey
|
0494dbecdf |
Consolidate partial symtab dependency reading
Most of the symbol readers have code to iterate over a partial symtabs dependencies, expanding each one and optionally printing a message. Now that the "second-stage" psymtab expansion is available as a method, these implementations can all be merged. This patch also changes a couple more warnings into assertions. gdb/ChangeLog 2020-01-26 Tom Tromey <tom@tromey.com> * xcoffread.c (xcoff_psymtab_to_symtab_1): Call read_dependencies. Add assert. * psymtab.c (partial_symtab::read_dependencies): New method. * psympriv.h (struct partial_symtab) <read_dependencies>: New method. * mdebugread.c (psymtab_to_symtab_1): Call read_dependencies. * dwarf2read.c (dwarf2_psymtab::expand_psymtab): Call read_dependencies. * dbxread.c (dbx_psymtab_to_symtab_1): Call read_dependencies. Add assert. Change-Id: I8151e05677794e90223edc1a4cb70f7f69137d46 |
||
|
Tom Tromey
|
8566b89b73 |
Introduce partial_symtab::expand_psymtab method
The symbol readers generally used two functions to expand a partial symtab: an outer function (now the "read_symtab" method), and an inner function, typically named something like "psymtab_to_symtab". This patch changes this second step to be a method on partial_symtab, and updates all the callers. For legacy_psymtab, a new function pointer member is introduced. This patch enables a subsequent cleanup. gdb/ChangeLog 2020-01-26 Tom Tromey <tom@tromey.com> * xcoffread.c (xcoff_psymtab_to_symtab_1): Change argument order. Call expand_psymtab. (xcoff_read_symtab): Call expand_psymtab. (xcoff_start_psymtab, xcoff_end_psymtab): Set legacy_expand_psymtab. * psympriv.h (struct partial_symtab) <expand_psymtab>: New method. (struct legacy_psymtab) <expand_psymtab>: Implement. <legacy_expand_psymtab>: New member. * mdebugread.c (mdebug_read_symtab): Call expand_psymtab. (parse_partial_symbols): Set legacy_expand_psymtab. (psymtab_to_symtab_1): Change argument order. Call expand_psymtab. (new_psymtab): Set legacy_expand_psymtab. * dwarf2read.h (struct dwarf2_psymtab) <expand_psymtab>: Declare. * dwarf2read.c (dwarf2_psymtab::read_symtab): Call expand_psymtab. (dwarf2_psymtab::expand_psymtab): Rename from psymtab_to_symtab_1. Call expand_psymtab. * dbxread.c (start_psymtab): Set legacy_expand_psymtab. (dbx_end_psymtab): Likewise. (dbx_psymtab_to_symtab_1): Change argument order. Call expand_psymtab. (dbx_read_symtab): Call expand_psymtab. * ctfread.c (struct ctf_psymtab) <expand_psymtab>: Declare. (ctf_psymtab::expand_psymtab): Rename from psymtab_to_symtab. (ctf_psymtab::read_symtab): Call expand_psymtab. Change-Id: Ic39a2d7aa7b424088d910b59dbd21271fa1c3430 |
||
|
Tom Tromey
|
077cbab270 |
Consolidate psymtab "Reading" messages
Each symbol reader implemented its own "Reading..." messages, and most of them double-checked that a previously-expanded psymtab could not be re-read. This patch consolidates the message-printing, and changes these checks into asserts. gdb/ChangeLog 2020-01-26 Tom Tromey <tom@tromey.com> * xcoffread.c (xcoff_read_symtab): Remove prints. Add assert. * psymtab.c (psymtab_to_symtab): Print verbose "Reading" messages. * mdebugread.c (mdebug_read_symtab): Remove prints. * dwarf2read.c (dwarf2_psymtab::read_symtab): Remove prints. Add assert. * dbxread.c (dbx_read_symtab): Remove prints. Add assert. Change-Id: I795be9710d42708299bb7b44972cffd27aec9413 |
||
|
Tom Tromey
|
891813beaa |
Introduce partial_symtab::read_symtab method
This introduces a new partial_symtab::read_symtab method, and updates the symbol readers to subclass partial_symtab and implement this method. The old read_symtab and read_symtab_private members are removed. In practice, only DWARF and CTF are truly updated to take advantage of the new setup. The other symbol readers are less actively maintained, and so this patch also introduces a "legacy_psymtab", which essentially works the same way as the old partial_symtab. (Note that, without more knowledge of the interaction between these symbol readers, fixing this to remove the new (small) overhead is not trivial, because these readers copy the read_symtab pointer between partial symtabs.) gdb/ChangeLog 2020-01-26 Tom Tromey <tom@tromey.com> * xcoffread.c (this_symtab_psymtab, read_xcoff_symtab) (xcoff_psymtab_to_symtab_1, xcoff_read_symtab) (xcoff_start_psymtab, xcoff_end_psymtab, scan_xcoff_symtab): Use legacy_symtab. * stabsread.h (dbx_end_psymtab): Use legacy_symtab. * psymtab.c (psymtab_to_symtab): Call method. (dump_psymtab): Update. * psympriv.h (struct partial_symtab): Add virtual destructor. <read_symtab>: New method. (struct legacy_symtab): New. * mdebugread.c (mdebug_read_symtab): Use legacy_psymtab. (struct pst_map) <pst>: Now a legacy_psymtab. (parse_procedure, parse_partial_symbols, psymtab_to_symtab_1) (new_psymtab): Use legacy_psymtab. * dwarf2read.h (struct dwarf2_psymtab): New. (struct dwarf2_per_cu_data) <psymtab>: Use it. * dwarf2read.c (dwarf2_create_include_psymtab) (dwarf2_build_include_psymtabs, create_type_unit_group) (create_partial_symtab, process_psymtab_comp_unit_reader) (build_type_psymtabs_reader, build_type_psymtab_dependencies) (set_partial_user): Use dwarf2_psymtab. (dwarf2_psymtab::read_symtab): Rename from dwarf2_read_symtab. (psymtab_to_symtab_1, process_full_comp_unit) (process_full_type_unit, dwarf2_ranges_read) (dwarf2_get_pc_bounds, psymtab_include_file_name) (dwarf_decode_lines): Use dwarf2_psymtab. * dwarf-index-write.c (psym_index_map): Use dwarf2_psymtab. (add_address_entry_worker, write_one_signatured_type) (recursively_count_psymbols, recursively_write_psymbols) (write_one_signatured_type, psyms_seen_size, write_gdbindex) (write_debug_names): Likewise. * dbxread.c (struct header_file_location): Take a legacy_psymtab. <pst>: Now a legacy_psymtab. (find_corresponding_bincl_psymtab): Return a legacy_psymtab. (read_dbx_symtab, start_psymtab, dbx_end_psymtab) (dbx_psymtab_to_symtab_1, read_ofile_symtab): Use legacy_psymtab. * ctfread.c (struct ctf_psymtab): New. (ctf_start_symtab, ctf_end_symtab, psymtab_to_symtab): Take a ctf_psymtab. (ctf_psymtab::read_symtab): Rename from ctf_read_symtab. (create_partial_symtab): Return a ctf_psymtab. (scan_partial_symbols): Update. Change-Id: Ia57a828786867d6ad03200af8f996f48ed15285e |
||
|
Tom Tromey
|
c3693a1d94 |
Turn start_psymtab_common into a constructor
This turns start_psymtab_common into a constructor, and then changes the callers to use "new" directly. This completes the psymtab allocation transition -- now it is possible for symbol readers to subclass struct partial_symtab. gdb/ChangeLog 2020-01-26 Tom Tromey <tom@tromey.com> * xcoffread.c (xcoff_start_psymtab): Use new. * psymtab.c (partial_symtab::partial_symtab): New constructor, renamed from start_psymtab_common. * psympriv.h (struct partial_symtab): Add new constructor. (start_psymtab_common): Don't declare. * mdebugread.c (parse_partial_symbols): Use new. * dwarf2read.c (create_partial_symtab): Use new. * dbxread.c (start_psymtab): Use new. * ctfread.c (create_partial_symtab): Use new. Change-Id: I5a0217bcb52bcfa442559771954bb66bd9ccbf02 |
||
|
Tom Tromey
|
32caafd02b |
Change allocate_psymtab to be a constructor
This is the next step in getting the symbol readers to allocate psymtabs themselves: change allocate_psymtab to be an ordinary constructor, and then use "new" at the previous call sites. Note that this doesn't get us all the way -- start_psymtab_common is still allocating a partial symtab. gdb/ChangeLog 2020-01-26 Tom Tromey <tom@tromey.com> * xcoffread.c (xcoff_end_psymtab): Use new. * psymtab.c (start_psymtab_common): Use new. (partial_symtab::partial_symtab): Rename from allocate_psymtab. Update. * psympriv.h (struct partial_symtab): Add parameters to constructor. Don't inline. (allocate_psymtab): Don't declare. * mdebugread.c (new_psymtab): Use new. * dwarf2read.c (dwarf2_create_include_psymtab): Use new. * dbxread.c (dbx_end_psymtab): Use new. Change-Id: Iffeae64c925050b90b9916cbc36e15b26ff42226 |
||
|
Tom Tromey
|
abaa2f2340 |
Do not allocate psymtabs via psymtab_storage
Currently, partial symbol tables are allocated by a method in psymtab_storage. However, eventually we want to subclass partial symtabs in the symbol readers, so the calls to "new" will have to happen there. This patch is a first step, moving the allocation from psymtab_storage and into allocate_psymtab. gdb/ChangeLog 2020-01-26 Tom Tromey <tom@tromey.com> * psymtab.h (class psymtab_storage) <install_psymtab>: Rename from allocate_psymtab. Update documentation. * psymtab.c (psymtab_storage::install_psymtab): Rename from allocate_psymtab. Do not use new. (allocate_psymtab): Use new. Update. Change-Id: Iba6a9bf3ee1e78062fdb9f007c3010f826f64bc8 |
||
|
Tom Tromey
|
6d94535fc6 |
Change some psymtab fields to bool
This changes a few fields in partial_symtab to have type bool. gdb/ChangeLog 2020-01-26 Tom Tromey <tom@tromey.com> * xcoffread.c (xcoff_psymtab_to_symtab_1): Update. * psymtab.c (psym_print_stats): Update. * psympriv.h (struct partial_symtab) <readin, psymtabs_addrmap_supported, anonymous>: Now bool. * mdebugread.c (psymtab_to_symtab_1): Update. * dwarf2read.c (create_type_unit_group, create_partial_symtab) (build_type_psymtabs_reader, psymtab_to_symtab_1) (process_full_comp_unit, process_full_type_unit): Update. * dbxread.c (dbx_psymtab_to_symtab_1): Update. * ctfread.c (psymtab_to_symtab): Update. Change-Id: I206761d083493589049ea0bc785ed6542339234d |
||
|
Tom Tromey
|
6f17252b76 |
Use new and delete for psymtabs
This changes psymtabs to be allocated with new and destroyed with delete. As a consequence, the psymtab free-list is also removed. The motivation for this is to let symbol readers subclass partial_symtab. gdb/ChangeLog 2020-01-26 Tom Tromey <tom@tromey.com> * mdebugread.c (parse_partial_symbols): Use discard_psymtab. * psymtab.h (class psymtab_storage) <free_psymtabs>: Remove. * psymtab.c (psymtab_storage): Delete psymtabs. (psymtab_storage::allocate_psymtab): Use new. (psymtab_storage::discard_psymtab): Use delete. * psympriv.h (struct partial_symtab): Add constructor and initializers. Change-Id: I4e78ac538fc0ea52b57489c1afb8f935a30941ef |
||
|
Tom Tromey
|
f6f1cebcbe |
Remove an include from machoread.c
machoread.c does not need to include psympriv.h. gdb/ChangeLog 2020-01-26 Tom Tromey <tom@tromey.com> * machoread.c: Do not include psympriv.h. Change-Id: I6362bd2e95e7416cb9bae3d48b69dd6dbe4f2cc8 |
||
Philippe Waroquiers
|
e47e48f6a7 |
Document 'set|show exec-file-mismatch (ask|warn|off)'
Mention in NEWS the new option and the set/show commands. Document in gdb.texinfo the new option and the set/show commands. gdb/ChangeLog 2020-01-25 Philippe Waroquiers <philippe.waroquiers@skynet.be> * NEWS: Mention the new option and the set/show commands. gdb/doc/ChangeLog 2020-01-25 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.texinfo (Attach): Document the new option and the set/show commands. (Connecting): Reference the exec-file-mismatch option. |
||
|
Philippe Waroquiers
|
a2fedca99c |
Implement 'set/show exec-file-mismatch'.
This option allows to tell GDB to detect and possibly handle mismatched exec-files. A recurrent problem with GDB is that GDB uses the wrong exec-file when using the attach/detach commands successively. Also, in case the user specifies a file on the command line but attaches to the wrong PID, this error is not made visible and gives a not user understandable behaviour. For example: $ gdb ... (gdb) atta 2682 ############################################ PID running 'sleepers' executable Attaching to process 2682 [New LWP 2683] [New LWP 2684] [New LWP 2685] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 0x00007f5ff829f603 in select () at ../sysdeps/unix/syscall-template.S:84 84 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) det Detaching from program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 2682 [Inferior 1 (process 2682) detached] (gdb) atta 31069 ############################################ PID running 'gdb' executable Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069 Reading symbols from /lib64/ld-linux-x86-64.so.2... Reading symbols from /usr/lib/debug/.build-id/60/6df9c355103e82140d513bc7a25a635591c153.debug... 0x00007f43c23478a0 in ?? () (gdb) bt #0 0x00007f43c23478a0 in ?? () #1 0x0000558909e3ad91 in ?? () #2 0x0000202962646700 in ?? () #3 0x00007ffc69c74e70 in ?? () #4 0x000055890c1d2350 in ?? () #5 0x0000000000000000 in ?? () (gdb) The second attach has kept the executable of the first attach. (in this case, 31069 is the PID of a GDB, that has nothing to do with the first determined 'sleepers' executable). Similarly, if specifying an executable, but attaching to a wrong pid, we get: gdb /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers ... Reading symbols from /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers... (gdb) atta 31069 ############################################ PID running 'gdb' executable Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069 Reading symbols from /lib64/ld-linux-x86-64.so.2... Reading symbols from /usr/lib/debug/.build-id/60/6df9c355103e82140d513bc7a25a635591c153.debug... 0x00007f43c23478a0 in ?? () (gdb) bt #0 0x00007f43c23478a0 in ?? () #1 0x0000558909e3ad91 in ?? () #2 0x0000202962646700 in ?? () #3 0x00007ffc69c74e70 in ?? () #4 0x000055890c1d2350 in ?? () #5 0x0000000000000000 in ?? () (gdb) And it is unclear to the user what has happened/what is going wrong. This patch series implements a new option: (gdb) apropos exec-file-mismatch set exec-file-mismatch -- Set exec-file-mismatch handling (ask|warn|off). show exec-file-mismatch -- Show exec-file-mismatch handling (ask|warn|off). (gdb) help set exec-file-mismatch Set exec-file-mismatch handling (ask|warn|off). Specifies how to handle a mismatch between the current exec-file name loaded by GDB and the exec-file name automatically determined when attaching to a process: ask - warn the user and ask whether to load the determined exec-file. warn - warn the user, but do not change the exec-file. off - do not check for mismatch. "ask" means: in case of mismatch between the current exec-file name and the automatically determined exec-file name of the PID we are attaching to, give a warning to the user and ask whether to load the automatically determined exec-file. "warn" means: in case of mismatch, just give a warning to the user. "off" means: do not check for mismatch. This fixes PR gdb/17626. There was a previous trial to fix this PR. See https://sourceware.org/ml/gdb-patches/2015-07/msg00118.html This trial was however only fixing the problem for the automatically determined executable files when doing attach. It was differentiating the 'user specified executable files' ("sticky") from the executable files automatically found by GDB. But such user specified sticky executables are in most cases due to a wrong manipulation by the user, giving unexpected results such as backtrace showing no function like in the above example. This patch ensures that whenever a process executable can be determined, that the user is warned if there is a mismatch. The same tests as above then give: (gdb) atta 2682 Attaching to process 2682 [New LWP 2683] [New LWP 2684] [New LWP 2685] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 0x00007f5ff829f603 in select () at ../sysdeps/unix/syscall-template.S:84 84 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) det Detaching from program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 2682 [Inferior 1 (process 2682) detached] (gdb) atta 31069 Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069 warning: Mismatch between current exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers and automatically determined exec-file /bd/home/philippe/gdb/git/build_fixes/gdb/gdb exec-file-mismatch handling is currently "ask" Load new symbol table from "/bd/home/philippe/gdb/git/build_fixes/gdb/gdb"? (y or n) y Reading symbols from /bd/home/philippe/gdb/git/build_fixes/gdb/gdb... Setting up the environment for debugging gdb. ... Reading symbols from /usr/lib/debug/.build-id/60/6df9c355103e82140d513bc7a25a635591c153.debug... 0x00007f43c23478a0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:84 84 ../sysdeps/unix/syscall-template.S: No such file or directory. (top-gdb) bt During symbol reading: incomplete CFI data; unspecified registers (e.g., rax) at 0x7f43c23478ad During symbol reading: unsupported tag: 'DW_TAG_unspecified_type' During symbol reading: cannot get low and high bounds for subprogram DIE at 0x12282a7 During symbol reading: Child DIE 0x12288ba and its abstract origin 0x1228b26 have different parents During symbol reading: DW_AT_call_target target DIE has invalid low pc, for referencing DIE 0x1229540 [in module /bd/home/philippe/gdb/git/build_fixes/gdb/gdb] #0 0x00007f43c23478a0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:84 #1 0x0000558909e3ad91 in poll (__timeout=-1, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46 #2 gdb_wait_for_event (block=block@entry=1) at ../../fixes/gdb/event-loop.c:772 #3 0x0000558909e3aef4 in gdb_do_one_event () at ../../fixes/gdb/event-loop.c:347 #4 0x0000558909e3b085 in gdb_do_one_event () at ../../fixes/gdb/common/common-exceptions.h:219 #5 start_event_loop () at ../../fixes/gdb/event-loop.c:371 During symbol reading: Member function "~_Sp_counted_base" (offset 0x1c69bf7) is virtual but the vtable offset is not specified During symbol reading: Multiple children of DIE 0x1c8f5a0 refer to DIE 0x1c8f0ee as their abstract origin #6 0x0000558909ed3b78 in captured_command_loop () at ../../fixes/gdb/main.c:331 #7 0x0000558909ed4b6d in captured_main (data=<optimized out>) at ../../fixes/gdb/main.c:1174 #8 gdb_main (args=<optimized out>) at ../../fixes/gdb/main.c:1190 #9 0x0000558909c1e9a8 in main (argc=<optimized out>, argv=<optimized out>) at ../../fixes/gdb/gdb.c:32 (top-gdb) gdb /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers ... Reading symbols from /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers... (gdb) atta 31069 Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069 warning: Mismatch between current exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers and automatically determined exec-file /bd/home/philippe/gdb/git/build_fixes/gdb/gdb exec-file-mismatch handling is currently "ask" Load new symbol table from "/bd/home/philippe/gdb/git/build_fixes/gdb/gdb"? (y or n) y Reading symbols from /bd/home/philippe/gdb/git/build_fixes/gdb/gdb... Setting up the environment for debugging gdb. .... In other words, it now works as intuitively expected by the user. If ever the user gave the correct executable on the command line, then attached to the wrong pid, then confirmed loading the wrong executable, the user can simply fix this by detaching, and attaching to the correct pid, GDB will then tell again to the user that the exec-file might better be loaded. The default value of "ask" is chosen instead of e.g. "warn" as in most cases, switching of executable will be the correct action, and in any case, the user can decide to not load the executable, as GDB asks a confirmation to the user to load the new executable. For settings "ask" and "warn", the new function validate_exec_file () tries to get the inferior pid exec file and compares it with the current exec file. In case of mismatch, it warns the user and optionally load the executable. This function is called in the attach_command implementation to cover most cases of attaching to a running process. It must also be called in remote.c, as the attach command is not supported for all types of remote gdbserver. gdb/ChangeLog 2020-01-25 Philippe Waroquiers <philippe.waroquiers@skynet.be> * exec.c (exec_file_mismatch_names, exec_file_mismatch_mode) (show_exec_file_mismatch_command, set_exec_file_mismatch_command) (validate_exec_file): New variables, enums, functions. (exec_file_locate_attach, print_section_info): Style the filenames. (_initialize_exec): Install show_exec_file_mismatch_command and set_exec_file_mismatch_command. * gdbcore.h (validate_exec_file): Declare. * infcmd.c (attach_command): Call validate_exec_file. * remote.c ( remote_target::remote_add_inferior): Likewise. |
||
|
Andrew Burgess
|
7ffa82e122 |
gdb: Better frame tracking for inline frames
This commit improves GDB's handling of inline functions when there are more than one inline function in a stack, so for example if we have a stack like: main -> aaa -> bbb -> ccc -> ddd And aaa, bbb, and ccc are all inline within main GDB should (when given sufficient debug information) be able to step from main through aaa, bbb, and ccc. Unfortunately, this currently doesn't work, here's an example session: (gdb) start Temporary breakpoint 1 at 0x4003b0: file test.c, line 38. Starting program: /project/gdb/tests/inline/test Temporary breakpoint 1, main () at test.c:38 38 global_var = 0; (gdb) step 39 return aaa () + 1; (gdb) step aaa () at test.c:39 39 return aaa () + 1; (gdb) step bbb () at test.c:39 39 return aaa () + 1; (gdb) step ccc () at test.c:39 39 return aaa () + 1; (gdb) step ddd () at test.c:32 32 return global_var; (gdb) bt #0 ddd () at test.c:32 #1 0x00000000004003c1 in ccc () at test.c:39 #2 bbb () at test.c:26 #3 aaa () at test.c:14 #4 main () at test.c:39 Notice that once we get to line 39 in main, GDB keeps reporting line 39 in main as the location despite understanding that the inferior is stepping through the nested inline functions with each use of step. The problem is that as soon as the inferior stops we call skip_inline_frames (from inline-frame.c) which calculates the inferiors current state in relation to inline functions - it figures out if we're in an inline function, and if we are counts how many inline frames there are at the current location. So, in our example above, when we step from line 38 in main to line 39 we stop at a location that is simultaneously in all of main, aaa, bbb, and ccc. The block structure reflects the order in which the functions would be called, with ccc being the most inner block and main being the most outer block. When we stop GDB naturally finds the block for ccc, however within skip_inline_frames we spot that bbb, aaa, and main are super-blocks of the current location and that each layer represents an inline function. The skip_inline_frames then records the depth of inline functions (3 in this case for aaa, bbb, and ccc) and also the symbol of the outermost inline function (in this case 'aaa' as main isn't an inline function, it just has things inline within it). Now GDB understands the stack to be main -> aaa -> bbb -> ccc, however, the state initialised in skip_inline_frames starts off indicating that we should hide 3 frames from the user, so we report that we're in main at line 39. The location of main, line 39 is derived by asking the inline function state for the last symbol in the stack (aaa in this case), and then asking for it's location - the location of an inlined function symbol is its call site, so main, line 39 in this case. If the user then asks GDB to step we don't actually move the inferior at all, instead we spot that we are in an inline function stack, lookup the inline state data, and reduce the skip depth by 1. We then report to the user that GDB has stopped. GDB now understands that we are in 'aaa'. In order to get the precise location we again ask GDB for the last symbol from the inline data structure, and we are again told 'aaa', we then get the location from 'aaa', and report that we are in main, line 39. Hopefully it's clear what the mistake here is, once we've reduced the inline skip depth we should not be using 'aaa' to compute the precise location, instead we should be using 'bbb'. That is what this patch does. Now, when we call skip_inline_frames instead of just recording the last skipped symbol we now record all symbols in the inline frame stack. When we ask GDB for the last skipped symbol we return a symbol based on how many frames we are skipping, not just the last know symbol. With this fix in place, the same session as above now looks much better: (gdb) start Temporary breakpoint 1 at 0x4003b0: file test.c, line 38. Starting program: /project/gdb/tests/inline/test Temporary breakpoint 1, main () at test.c:38 38 global_var = 0; (gdb) s 39 return aaa () + 1; (gdb) s aaa () at test.c:14 14 return bbb () + 1; (gdb) s bbb () at test.c:26 26 return ccc () + 1; (gdb) s ccc () at test.c:20 20 return ddd () + 1; (gdb) s ddd () at test.c:32 32 return global_var; (gdb) bt #0 ddd () at test.c:32 #1 0x00000000004003c1 in ccc () at test.c:20 #2 bbb () at test.c:26 #3 aaa () at test.c:14 #4 main () at test.c:39 gdb/ChangeLog: * frame.c (find_frame_sal): Move call to get_next_frame into more inner scope. * inline-frame.c (inilne_state) <inline_state>: Update argument types. (inilne_state) <skipped_symbol>: Rename to... (inilne_state) <skipped_symbols>: ...this, and change to a vector. (skip_inline_frames): Build vector of skipped symbols and use this to reate the inline_state. (inline_skipped_symbol): Add a comment and some assertions, fetch skipped symbol from the list. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-inline-many-frames.c: New file. * gdb.dwarf2/dw2-inline-many-frames.exp: New file. Change-Id: I99def5ffb44eb9e58cda4b449bf3d91ab0386c62 |
||
|
Andrew Burgess
|
3d92a3e313 |
gdb: Don't reorder line table entries too much when sorting.
Don't reorder line table entries for the same address when sorting the
line table, maintain the compiler given line order. Usually this will
reflect the order in which lines are conceptually encountered at a
given address.
Consider this example:
/* 1 */ volatile int global_var;
/* 2 */ int __attribute__ ((noinline))
/* 3 */ bar ()
/* 4 */ {
/* 5 */ return global_var;
/* 6 */ }
/* 7 */ static inline int __attribute__ ((always_inline))
/* 8 */ foo ()
/* 9 */ {
/* 10 */ return bar ();
/* 11 */ }
/* 12 */ int
/* 13 */ main ()
/* 14 */ {
/* 15 */ global_var = 0;
/* 16 */ return foo ();
/* 17 */ }
GCC 10 currently generates a line table like this (as shown by
objdump):
CU: ./test.c:
File name Line number Starting address
test.c 4 0x4004b0
test.c 5 0x4004b0
test.c 6 0x4004b6
test.c 6 0x4004b7
test.c 14 0x4003b0
test.c 15 0x4003b0
test.c 16 0x4003ba
test.c 10 0x4003ba
test.c 10 0x4003c1
The interesting entries are those for lines 16 and 10 at address
0x4003ba, these represent the call to foo and the inlined body of
foo.
With the current line table sorting GDB builds the line table like
this (as shown by 'maintenance info line-table'):
INDEX LINE ADDRESS
0 14 0x00000000004003b0
1 15 0x00000000004003b0
2 10 0x00000000004003ba
3 16 0x00000000004003ba
4 END 0x00000000004003c1
5 4 0x00000000004004b0
6 5 0x00000000004004b0
7 END 0x00000000004004b7
Notice that entries 2 and 3 for lines 10 and 16 are now in a different
order to the line table as given by the compiler. With this patch
applied the order is now:
INDEX LINE ADDRESS
0 14 0x00000000004003b0
1 15 0x00000000004003b0
2 16 0x00000000004003ba
3 10 0x00000000004003ba
4 END 0x00000000004003c1
5 4 0x00000000004004b0
6 5 0x00000000004004b0
7 END 0x00000000004004b7
Notice that entries 2 and 3 are now in their original order again.
The consequence of the incorrect ordering is that when stepping
through inlined functions GDB will display the wrong line for the
inner most frame. Here's a GDB session before this patch is applied:
Starting program: /home/andrew/tmp/inline/test
Temporary breakpoint 1, main () at test.c:15
15 /* 15 */ global_var = 0;
(gdb) step
16 /* 16 */ return foo ();
(gdb) step
foo () at test.c:16
16 /* 16 */ return foo ();
(gdb) step
bar () at test.c:5
5 /* 5 */ return global_var;
The step from line 15 to 16 was fine, but the next step should have
taken us to line 10, instead we are left at line 16. The final step
to line 5 is as expected.
With this patch applied the session goes better:
Starting program: /home/andrew/tmp/inline/test
Temporary breakpoint 1, main () at test.c:15
15 /* 15 */ global_var = 0;
(gdb) step
16 /* 16 */ return foo ();
(gdb) step
foo () at test.c:10
10 /* 10 */ return bar ();
(gdb) step
bar () at test.c:5
5 /* 5 */ return global_var;
We now visit the lines as 15, 16, 10, 5 as we would like.
The reason for this issue is that the inline frame unwinder is
detecting that foo is inlined in main. When we stop at the shared
address 0x4003ba the inline frame unwinder first shows us the outer
frame, this information is extracted from the DWARF's
DW_TAG_inlined_subroutine entries and passed via GDB's block data.
When we step again the inlined frame unwinder moves us up the call
stack to the inner most frame at which point the frame is displayed as
normal, with the location for the address being looked up in the line
table.
As GDB uses the last line table entry for an address as "the" line to
report for that address it is critical that GDB maintain the order of
the line table entries. In the first case, by reordering the line
table we report the wrong location.
I had to make a small adjustment in find_pc_sect_line in order to
correctly find the previous line in the line table. In some line
tables I was seeing an actual line entry and an end of sequence marker
at the same address, before this commit these would reorder to move
the end of sequence marker before the line entry (end of sequence has
line number 0). Now the end of sequence marker remains in its correct
location, and in order to find a previous line we should step backward
over any end of sequence markers.
As an example, the binary:
gdb/testsuite/outputs/gdb.dwarf2/dw2-ranges-func/dw2-ranges-func-lo-cold
Has this line table before the patch:
INDEX LINE ADDRESS
0 48 0x0000000000400487
1 END 0x000000000040048e
2 52 0x000000000040048e
3 54 0x0000000000400492
4 56 0x0000000000400497
5 END 0x000000000040049a
6 62 0x000000000040049a
7 END 0x00000000004004a1
8 66 0x00000000004004a1
9 68 0x00000000004004a5
10 70 0x00000000004004aa
11 72 0x00000000004004b9
12 END 0x00000000004004bc
13 76 0x00000000004004bc
14 78 0x00000000004004c0
15 80 0x00000000004004c5
16 END 0x00000000004004cc
And after this patch:
INDEX LINE ADDRESS
0 48 0x0000000000400487
1 52 0x000000000040048e
2 END 0x000000000040048e
3 54 0x0000000000400492
4 56 0x0000000000400497
5 END 0x000000000040049a
6 62 0x000000000040049a
7 66 0x00000000004004a1
8 END 0x00000000004004a1
9 68 0x00000000004004a5
10 70 0x00000000004004aa
11 72 0x00000000004004b9
12 END 0x00000000004004bc
13 76 0x00000000004004bc
14 78 0x00000000004004c0
15 80 0x00000000004004c5
16 END 0x00000000004004cc
When calling find_pc_sect_line with the address 0x000000000040048e, in
both cases we find entry #3, we then try to find the previous entry,
which originally found this entry '2 52 0x000000000040048e',
after the patch it finds '2 END 0x000000000040048e', which
cases the lookup to fail.
By skipping the END marker after this patch we get back to the correct
entry, which is now #1: '1 52 0x000000000040048e', and
everything works again.
gdb/ChangeLog:
* buildsym.c (lte_is_less_than): Delete.
(buildsym_compunit::end_symtab_with_blockvector): Create local
lambda function to sort line table entries, and use
std::stable_sort instead of std::sort.
* symtab.c (find_pc_sect_line): Skip backward over end of sequence
markers when looking for a previous line.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-inline-stepping.c: New file.
* gdb.dwarf2/dw2-inline-stepping.exp: New file.
Change-Id: Ia0309494be4cfd9dcc554f30209477f5f040b21b
|
||
|
Andrew Burgess
|
94a72be708 |
gdb: Include end of sequence markers in the line table
In this commit:
commit
|
||
|
Pedro Alves
|
53af73bf5e |
Fix re-runs of a second inferior (PR gdb/25410)
This fixes a latent bug exposed by the multi-target patch ( |
||
|
Christian Biesinger
|
3050c6f4bc |
Make the class name in the definition match the declaration
Fixes a compile error because the class is actually called arm_netbsd_nat_target. gdb/ChangeLog: 2020-01-24 Christian Biesinger <cbiesinger@google.com> * arm-nbsd-nat.c (arm_nbsd_nat_target::fetch_registers): Rename to... (arm_netbsd_nat_target::fetch_registers): ...this. (arm_nbsd_nat_target::store_registers): Rename to... (arm_netbsd_nat_target::store_registers): ...this. Change-Id: Ibebfab9edeff48f54c32d0745afda1d74d31de92 |
||
|
Christian Biesinger
|
73685c7ede |
Define _KERNTYPES in arm-nbsd-nat.c
Fixes the below compile error on ARM NetBSD 9.0_RC1 (the only version I
tested). types.h does not define register_t by default.
We already use this define elsewhere, notably in bsd-kvm.c.
In file included from ../../gdb/arm-nbsd-nat.c:28:
/usr/include/machine/frame.h:54:2: error: unknown type name 'register_t'; did you mean '__register_t'?
register_t tf_spsr;
^
/usr/include/machine/types.h:77:14: note: '__register_t' declared here
typedef int __register_t;
^
There are other compile errors that this does not fix.
gdb/ChangeLog:
2020-01-24 Christian Biesinger <cbiesinger@google.com>
* arm-nbsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
Change-Id: I82c21d38189ee59ea0af2538ba84b771d268722e
|
||
|
Christian Biesinger
|
89203d4062 |
Update comments about removed function
regset_from_core_section doesn't exist anymore; it has been replaced by the iterate_over_regset_sections gdbarch method. Update comments accordingly to not confuse readers. gdb/ChangeLog: 2020-01-24 Christian Biesinger <cbiesinger@google.com> * aarch64-fbsd-tdep.c (aarch64_fbsd_iterate_over_regset_sections): Update comment. * aarch64-linux-tdep.c (aarch64_linux_iterate_over_regset_sections): Likewise. * arm-fbsd-tdep.c (arm_fbsd_iterate_over_regset_sections): Likewise. * gdbcore.h (deprecated_add_core_fns): Update comment to point to the correct replacement (iterate_over_regset_sections). * riscv-fbsd-tdep.c (riscv_fbsd_iterate_over_regset_sections): Update comment. Change-Id: I5eea4d18e15edae5d6dfd5d0d6241e5b2ae40daa |
||
|
Andrew Burgess
|
1ba1ac8801 |
gdb: Enable stdin on exception in execute_gdb_command
This is an update of this patch: https://sourceware.org/ml/gdb-patches/2018-09/msg00884.html This patch attempts to address PR gdb/23718 by re-enabling stdin whenever an exception is caught during gdb.execute(). When Python gdb.execute() is called, an exception could occur (e.g. the target disappearing), which is then converted into a Python exception. If stdin was disabled before the exception is caught, it is not re-enabled, because the exception doesn't propagate to the top level of the event loop, whose catch block would otherwise enable it. The result is that when execution of a Python script completes, GDB does not prompt or accept input, and is effectively hung. This change rectifies the issue by re-enabling stdin in the catch block of execute_gdb_command, prior to converting the exception to a Python exception. Since this patch was originally posted I've added a test, and also I converted the code to re-enable stdin from this: SWITCH_THRU_ALL_UIS () { async_enable_stdin (); } to simply this: async_enable_stdin (); My reasoning is that we only need the SWITCH_THRU_ALL_UIS if, at the time the exception is caught, the current_ui might be different than at the time we called async_disable_stdin. Within python's execute_gdb_command I think it should be impossible to switch current_ui, so the SWITCH_THRU_ALL_UIS isn't needed. gdb/ChangeLog: PR gdb/23718 * gdb/python/python.c (execute_gdb_command): Call async_enable_stdin in catch block. gdb/testsuite/ChangeLog: PR gdb/23718 * gdb.server/server-kill-python.exp: New file. Change-Id: I1cfc36ee9f8484cc1ed82be9be338353db6bc080 |
||
|
Andrew Burgess
|
f3364a6d0f |
gdb: Re-enable stdin for all UIs from start_event_loop
If we catch an exception in start_event_loop's call to gdb_do_one_event, then it is possible that the current_ui has changed since we called async_disable_stdin. If that's the case then calling async_enable_stdin will be called on the wrong UI. To solve this problem we wrap the call to async_enable_stdin with SWITCH_THRU_ALL_UIS, this causes us to try and re-enable stdin for all UIs, which will catch any for which we called async_disable_stdin. gdb/ChangeLog: * event-loop.c (start_event_loop): Wrap async_enable_stdin with SWITCH_THRU_ALL_UIS. gdb/testsuite/ChangeLog: * gdb.server/multi-ui-errors.c: New file. * gdb.server/multi-ui-errors.exp: New file. Change-Id: I1e18deff2e6f4e17f7a13adce3553eb001cad93b |
||
|
Andrew Burgess
|
733d0a6795 |
gdb/tui: asm window handles invalid memory and scrolls better
This started as a patch to enable the asm window to handle attempts to
disassemble invalid memory, but it ended up expanding into a
significant rewrite of how the asm window handles scrolling. These
two things ended up being tied together as it was impossible to
correctly test scrolling into invalid memory when the asm window would
randomly behave weirdly while scrolling.
Things that should work nicely now; scrolling to the bottom or top of
the listing with PageUp, PageDown, Up Arrow, Down Arrow and we should
be able to scroll past small areas of memory that don't have symbols
associated with them. It should also be possible to scroll to the
start of a section even if there's no symbol at the start of the
section.
Adding tests for this scrolling was a little bit of a problem. First
I would have liked to add tests for PageUp / PageDown, but the tuiterm
library we use doesn't support these commands right now due to only
emulating a basic ascii terminal. Changing this to emulate a more
complex terminal would require adding support for more escape sequence
control codes, so I've not tried to tackle that in this patch.
Next, I would have liked to test scrolling to the start or end of the
assembler listing and then trying to scroll even more, however, this
is a problem because in a well behaving GDB a scroll at the start/end
has no effect. What we need to do is:
- Move to start of assembler listing,
- Send scroll up command,
- Wait for all curses output,
- Ensure the assembler listing is unchanged, we're still at the
start of the listing.
The problem is that there is no curses output, so how long do we wait
at step 3? The same problem exists for scrolling to the bottom of the
assembler listing. However, when scrolling down you can at least see
the end coming, so I added a test for this case, however, this feels
like an area of code that is massively under tested.
gdb/ChangeLog:
PR tui/9765
* minsyms.c (lookup_minimal_symbol_by_pc_section): Update header
comment, add extra parameter, and update to store previous symbol
when appropriate.
* minsyms.h (lookup_minimal_symbol_by_pc_section): Update comment,
add extra parameter.
* tui/tui-disasm.c (tui_disassemble): Update header comment,
remove unneeded parameter, add try/catch around gdb_print_insn,
rewrite to add items to asm_lines vector.
(tui_find_backward_disassembly_start_address): New function.
(tui_find_disassembly_address): Updated throughout.
(tui_disasm_window::set_contents): Update for changes to
tui_disassemble.
(tui_disasm_window::do_scroll_vertical): No need to adjust the
number of lines to scroll.
gdb/testsuite/ChangeLog:
PR tui/9765
* gdb.tui/tui-layout-asm.exp: Add scrolling test for asm window.
Change-Id: I323987c8fd316962c937e73c17d952ccd3cfa66c
|
||
Simon Marchi
|
b3b3bada0d |
gdb: introduce objfile text_section_offset and data_section_offset methods
The pattern objfile->section_offsets[SECT_OFF_TEXT (objfile)] ... appears very often, to get the offset of the text section of an objfile. I thought it would be more readable to write it as: objfile->text_section_offset () ... so I added this method and used it where possible. I also added data_section_offset, although it is not used as much. gdb/ChangeLog: * objfiles.h (ALL_OBJFILE_OSECTIONS): Move up. (SECT_OFF_DATA): Likewise. (SECT_OFF_RODATA): Likewise. (SECT_OFF_TEXT): Likewise. (SECT_OFF_BSS): Likewise. (struct objfile) <text_section_offset, data_section_offset>: New methods. * amd64-windows-tdep.c (amd64_windows_find_unwind_info): Use objfile::text_section_offset. * coff-pe-read.c (add_pe_forwarded_sym): Likewise. * coffread.c (coff_symtab_read): Likewise. (enter_linenos): Likewise. (process_coff_symbol): Likewise. * ctfread.c (get_objfile_text_range): Likewise. * dtrace-probe.c (dtrace_probe::get_relocated_address): Use objfile::data_section_offset. * dwarf2-frame.c (execute_cfa_program): Use objfile::text_section_offset. (dwarf2_frame_find_fde): Likewise. * dwarf2read.c (create_addrmap_from_index): Likewise. (create_addrmap_from_aranges): Likewise. (dw2_find_pc_sect_compunit_symtab): Likewise. (process_psymtab_comp_unit_reader): Likewise. (add_partial_symbol): Likewise. (add_partial_subprogram): Likewise. (process_full_comp_unit): Likewise. (read_file_scope): Likewise. (read_func_scope): Likewise. (read_lexical_block_scope): Likewise. (read_call_site_scope): Likewise. (dwarf2_rnglists_process): Likewise. (dwarf2_ranges_process): Likewise. (dwarf2_ranges_read): Likewise. (dwarf_decode_lines_1): Likewise. (new_symbol): Likewise. (dwarf2_fetch_die_loc_sect_off): Likewise. (dwarf2_per_cu_text_offset): Likewise. * hppa-bsd-tdep.c (hppabsd_find_global_pointer): Likewise. * hppa-tdep.c (read_unwind_info): Likewise. * ia64-tdep.c (ia64_find_unwind_table): Likewise. * psympriv.h (struct partial_symtab): Likewise. * psymtab.c (find_pc_sect_psymtab): Likewise. * solib-svr4.c (enable_break): Likewise. * stap-probe.c (relocate_address): Use objfile::data_section_offset. * xcoffread.c (enter_line_range): Use objfile::text_section_offset. (read_xcoff_symtab): Likewise. |
||
|
Simon Marchi
|
ab53f38262 |
gdb: fix variable shadowing error in darwin-nat.c
We encounter this error when building on macOS with GCC.
CXX darwin-nat.o
/src-local/binutils-gdb/gdb/darwin-nat.c: In member function 'ptid_t darwin_nat_target::wait_1(ptid_t, target_waitstatus*)':
/src-local/binutils-gdb/gdb/darwin-nat.c:1264:18: error: declaration of 'inf' shadows a previous local [-Werror=shadow=compatible-local]
for (inferior *inf : all_inferiors (this))
^~~
/src-local/binutils-gdb/gdb/darwin-nat.c:1205:20: note: shadowed declaration is here
struct inferior *inf;
^~~
Fix it by moving the declaration of `inf` in the specific scopes that
need it. I think it's clearer this way anyway, as it shows that it's
not the same `inf` that is used in these different scopes.
Thanks to Iain Sandoe for reporting this. I did not see this error at
first, because I compile with the default system compiler on macOS,
which is clang. The compiler flag we try to enable for this is
`-Wshadow=local`, which is not one recognized by clang. I checked to
see if there would a version of the -Wshadow* warnings [1] we could
enable for clang, that would catch this, but the only one that would is
`-Wshadow` itself, and this is too invasive for us (which is why we
enabled just -Wshadow=local in the first place).
[1] https://clang.llvm.org/docs/DiagnosticsReference.html#wshadow
gdb/ChangeLog:
* darwin-nat.c (darwin_nat_target::wait_1): Move `inf`
declaration to narrower scopes.
|
||
|
Simon Marchi
|
e7eee665a1 |
gdb: fix darwin-nat.c build / adapt to multi-target
The darwin-nat.c file doesn't build since the multi-target changes
(
|
||
Hannes Domani
|
c162ed3e66 |
Cache the text section offset of shared libraries
Each time a dll is loaded, update_solib_list is called. This in turn calls deep down xfer_partial -> windows_xfer_shared_libraries, which calls windows_xfer_shared_library for each loaded dll, and pe_text_section_offset reads the dll for the text section offset. Also if the data provided by xfer_partial is bigger than 4K, then all of this is done for each 4K chunk (see target_read_alloc_1). Caching of the text section offset improves the startup time of an application with >300 dynamically loaded plugins from 2m10s to 10s. And the shutdown time improves from 2m to 2s. gdb/ChangeLog: 2020-01-23 Hannes Domani <ssbssa@yahoo.de> * i386-cygwin-tdep.c (core_process_module_section): Update. * windows-nat.c (struct lm_info_windows): Add text_offset. (windows_xfer_shared_libraries): Update. * windows-tdep.c (windows_xfer_shared_library): Add text_offset_cached argument. * windows-tdep.h (windows_xfer_shared_library): Update. |
||
|
Simon Marchi
|
a12378729f |
gdb: add declaration for _initialize_gdbarch in gdbarch.sh
In commit
gdb: add back declarations for _initialize functions
|
||
|
Simon Marchi
|
b3ee6dd9f2 |
gdb: remove uses of iterate_over_inferiors in remote-sim.c
This removes the two uses of iterate_over_inferiors, in favor of range-based loops. gdb/ChangeLog: * remote-sim.c (check_for_duplicate_sim_descriptor): Remove. (get_sim_inferior_data): Remove use of iterate_over_inferiors, replace with range-based for. (gdbsim_interrupt_inferior): Remove. (gdbsim_target::interrupt): Replace iterate_over_inferiors use with a range-based for. Inline code from gdbsim_interrupt_inferior. |
||
|
Simon Marchi
|
f9fac3c81b |
gdb: fix indentation in infrun.c
I noticed the indentation there was off, this patch fixes it. gdb/ChangeLog: * infrun.c (proceed): Fix indentation. |
||
|
Tom Tromey
|
f6474de9aa |
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
|
||
|
Luis Machado
|
f0c702d4b8 |
Convert an int flag variable to bool
As suggested, the cond variable is really supposed to be a bool. So, make it so. gdb/ChangeLog: 2020-01-21 Luis Machado <luis.machado@linaro.org> * aarch64-tdep.c (struct aarch64_displaced_step_closure) <cond>: Change type to bool. (aarch64_displaced_step_b_cond): Update cond to use bool type. (aarch64_displaced_step_cb): Likewise. (aarch64_displaced_step_tb): Likewise. |
||
|
Luis Machado
|
1ab139e5be |
Add more debugging output to aarch64_displaced_step_fixup
While debugging the step-over-syscall problem, i wanted to see a bit more debugging output to try to determine the root cause. This patch does this. gdb/ChangeLog: 2020-01-21 Luis Machado <luis.machado@linaro.org> * aarch64-tdep.c (aarch64_displaced_step_fixup): Add more debugging output. |