Valgrind GDB (vgdb) presents itself as a remote target but works on
the local filesystem. gdb_bfd_open contained a special case to make
vgdb work with "target:" sysroots, but the implementation meant that
GDB would fall back to the local filesystem if *any* to_fileio_open
method failed with ENOSYS for *any* reason. This commit moves the
vgdb special case to remote_filesystem_is_local to allow the fallback
to be restricted only to the specific case that remote file transfer
is unsupported. This commit also adds a warning which is displayed
the first time the fallback is used.
gdb/ChangeLog:
* gdb_bfd.c (gdb_bfd_open): Move vgdb special case to...
* remote.c (remote_filesystem_is_local): ...here.
Patch implementing '@' GDB array operator in GCC has been rejected:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00414.html
and so there is now a GDB tracker to implement it just in GDB:
https://sourceware.org/bugzilla/show_bug.cgi?id=18489
gdb/testsuite/ChangeLog
2015-06-04 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile-print.exp (compile print *vararray@3)
(compile print *vararrayp@3): Change xfail to kfail compile/18489.
When I do something else, I find that gdbarch.c isn't sync'ed with
gdbarch.sh. This patch just move some statements on
stack_frame_destroyed_p some lines below.
gdb:
2015-06-04 Yao Qi <yao.qi@linaro.org>
* gdbarch.c: Regenerate it.
Currently inferior memory is allocated by inferior mmap() but it is never
deallocated; despite the injected objfile incl. its symbols is freed. This was
intentional so that one can do for example:
inferior:
char *str = "foo";
GDB:
(gdb) compile code str = "bar";
I believe later patches will be needed to introduce full control over keeping
vs. discarding the injected module as being discussed in:
compile: objfiles lifetime UI
https://sourceware.org/ml/gdb/2015-04/msg00051.html
Message-ID: <20150429135735.GA16974@host1.jankratochvil.net>
https://sourceware.org/ml/gdb/2015-05/msg00007.html
As decided by Phil it is better not to leak inferior pages as users can
workaround the issue above for example by:
(gdb) compile code str = strdup ("bar");
I have checked that in fact gdb/doc/ (written by Phil) already expects the
injected code will be unmapped so that does not need to be changed:
compile code int ff = 5; p = &ff;
In this example, @code{p} would point to @code{ff} when the
@code{compile} command is executing the source code provided to it.
However, as variables in the (example) program persist with their
assigned values, the variable @code{p} would point to an invalid
location when the command exists.
gdb/ChangeLog
2015-04-28 Jan Kratochvil <jan.kratochvil@redhat.com>
* arch-utils.c (default_infcall_munmap): New.
* arch-utils.h (default_infcall_munmap): New declaration.
* compile/compile-object-load.c (struct munmap_list, munmap_list_add)
(munmap_list_free, munmap_listp_free_cleanup): New.
(struct setup_sections_data): Add field munmap_list_headp.
(setup_sections): Call munmap_list_add.
(compile_object_load): New variable munmap_list_head, initialize
setup_sections_data.munmap_list_headp, return munmap_list_head.
* compile/compile-object-load.h (struct munmap_list): New declaration.
(struct compile_module): Add field munmap_list_head.
(munmap_list_free): New declaration.
* compile/compile-object-run.c (struct do_module_cleanup): Add field
munmap_list_head.
(do_module_cleanup): Call munmap_list_free.
(compile_object_run): Pass munmap_list_head to do_module_cleanup.
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (infcall_munmap): New.
* linux-tdep.c (linux_infcall_munmap): New.
(linux_init_abi): Install it.
gdb/testsuite/ChangeLog
2015-04-28 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile.exp (keep jit in memory): Rename to ...
(do not keep jit in memory): ... this.
(expect 5): Change it to ...
(expect no 5): ... this.
I sent a patch in 2013 for this (incorrectly named =thread-created):
https://cygwin.com/ml/gdb-patches/2013-06/msg00129.html
Tom Tromey was ok with the change, but suggested to add a test as well.
Then I forgot about this patch until today. So here it is again, with the
corresponding test.
The problem is that the =thread-exited event does not appear when detaching
from a local process. It does appear with remote though. It's not a really
big deal, but I'd like it to be consistent.
Tested with local and remote Linux on my Ubuntu 14.04.
gdb/ChangeLog:
PR gdb/15564
* inferior.c (detach_inferior): Call exit_inferior_1 with silent = 0.
gdb/testsuite/ChangeLog:
PR gdb/15564
* gdb.mi/mi-detach.exp: New file.
Initially there is some chain (let's say the longest one
but that doe snot matter). Consequently its elements from the middle are
being removed and there remains only some few unambiguous top and bottom ones.
The original idea why the comparison should be sharp ("<") was that if there
are multiple chains like (0xaddr show jmp instruction address):
main(0x100) -> a(0x200) -> d(0x400)
main(0x100) -> a(0x200) -> c(0x300) -> d(0x400)
then - such situation cannot exist - if two jmp instructions in "a" have the
same address they must also jump to the same address (*).
(*) jump to a computed address would be never considered for the DWARF
tail-call records.
So there could be:
main(0x100) -> a(0x200) -> d(0x400)
main(0x100) -> a(0x270) -> c(0x300) -> d(0x400)
But then "a" frame itself is ambiguous and it must not be displayed.
I did not realize that there can be self-tail-call:
main(0x100) -> a(0x200) -> d(0x400)
main(0x100) -> a(0x280) -> a(0x200) -> d(0x400)
which intersects to:
main(0x100) -> <???>? -> a(0x200) -> d(0x400)
And so if the first chain was chosen the
main(0x100) -> a(0x200) -> d(0x400)
then the final intersection has callers+callees==length.
> for example, if CALLERS is 3 and
> CALLEES is 2, what does the chain look like?
main(0x100) -> x(0x150) -> y(0x200) -> <???>? -> a(0x200) -> d(0x400)
And if LENGTH is 7 then:
call_site[0] = main(0x100)
call_site[1] = x(0x150)
call_site[2] = y(0x200)
call_site[3] = garbage
call_site[4] = garbage
call_site[5] = a(0x200)
call_site[6] = d(0x400)
gdb/ChangeLog
2015-06-01 Andreas Schwab <schwab@linux-m68k.org>
Jan Kratochvil <jan.kratochvil@redhat.com>
PR symtab/18392
* dwarf2-frame-tailcall.c (pretended_chain_levels): Correct
assertion.
* dwarf2loc.c (chain_candidate): Likewise.
gdb/testsuite/ChangeLog
2015-06-01 Jan Kratochvil <jan.kratochvil@redhat.com>
PR symtab/18392
* gdb.arch/amd64-tailcall-self.S: New file.
* gdb.arch/amd64-tailcall-self.c: New file.
* gdb.arch/amd64-tailcall-self.exp: New file.
This patch is to use PTRACE_{G,S}ETREGSET to fetch and store VFP
registers if kernel supports.
gdb:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* arm-linux-nat.c (fetch_vfp_regs): Use PTRACE_GETREGSET.
(store_vfp_regs): Use PTRACE_SETREGSET.
If kernel supports PTRACE_GETREGSET, GDB uses PTRACE_{G,S}ETREGSET
to fetch and store FP registers.
gdb:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* arm-linux-nat.c (fetch_fpregister): Use PTRACE_GETREGSET.
(fetch_fpregs): Likewise.
* arm-linux-nat.c (store_fpregister): Use PTRACE_SETREGSET.
(store_fpregs): Likewise.
If kernel supports PTRACE_GETREGSET, GDB uses PTRACE_{G,S}ETREGSET
to fetch and store GP registers.
gdb:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* arm-linux-nat.c (fetch_register): Use PTRACE_GETREGSET.
(fetch_regs): Likewise.
(store_regs): Use PTRACE_SETREGSET.
(store_register): Likewise.
I'll let arm-linux-nat.c to use PTRACE_GETREGSET if kernel supports,
so this patch is to move have_ptrace_getregset from x86-linux-nat.c
to linux-nat.c.
gdb:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* x86-linux-nat.c (have_ptrace_getregset): Move it to ...
* linux-nat.c: ... here.
* x86-linux-nat.h (have_ptrace_getregset): Move the declaration
to ...
* linux-nat.h: ... here.
Macros PTRACE_GETREGSET and PTRACE_SETREGSET are defined locally in
some places in GDB and GDBserver. This patch is to move them to
nat/linux-ptrace.h to avoid duplication.
gdb:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* amd64-linux-nat.c: Include "nat/linux-ptrace.h".
* i386-linux-nat.c: Likewise.
* nat/linux-ptrace.h (PTRACE_GETREGSET, PTRACE_SETREGSET): Define.
* s390-linux-nat.c: Include "nat/linux-ptrace.h".
(PTRACE_GETREGSET, PTRACE_SETREGSET): Remove.
* x86-linux-nat.c: Include "nat/linux-ptrace.h".
* x86-linux-nat.h (PTRACE_GETREGSET, PTRACE_SETREGSET): Remove.
gdb/gdbserver:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* linux-s390-low.c (PTRACE_GETREGSET, PTRACE_SETREGSET): Remove.
* linux-x86-low.c: Likewise.
gdb/
* go32-nat.c (go32_xfer_memory): Fix the return value to be
compatible to what read_child and write_child return. This
unbreaks that DJGPP build of GDB which was broken since v7.7.
Diagnosis of unexpected input (in this case, in an executable file)
should not crash as if it were a bug in GDB.
gdb/
PR gdb/18464
* osabi.c (generic_elf_osabi_sniff_abi_tag_sections): Use warning
rather than internal_error for an unrecognized value.
Currently access to the last pseudo register is aliased to a1. This is
done by little snippets in the beginning of xtensa_pseudo_register_read
and xtensa_pseudo_register_write that used to do such aliasing for FP
register since bdb4c075a2, but then
FP_ALIAS was expanded into gdbarch_num_regs (current_gdbarch) +
gdbarch_num_pseudo_regs (current_gdbarch) (one register past the last
pseudo register) in 304fe2552d, which
then was changed to the last pseudo register in
94a0e87711.
Drop these snippets.
2015-05-29 Max Filippov <jcmvbkbc@gmail.com>
gdb/
* xtensa-tdep.c (xtensa_pseudo_register_read)
(xtensa_pseudo_register_write): Don't alias last pseudo register
to a1.
The native-extended-gdbserver target now supports fork events and
follow fork, but it does not yet support exec events. Some of the
tests in gdb.base/foll-vfork.exp depend on exec events. This patch
disables those tests for remote targets. We can re-enable these
once the exec event support goes in.
gdb/testsuite/
* gdb.base/foll-vfork.exp (main): Disable exec-dependent
tests for remote targets by checking is_target_gdbserver.
This patch fixes some intermittent test failures in
gdb.base/foll-vfork.exp where a vfork child would be (incorrectly)
resumed when handling the vfork event. In this case the result
was a subsequent event reported to the client side as a SIGTRAP
delivered to the as-yet-unknown child thread.
The new thread was resumed (incorrectly) in linux-low.c when
resume_stopped_resumed_lwps was called from
linux_wait_for_event_filtered after the vfork event had been
handled in handle_extended_wait.
Gdbserver/linux-low.c's add_thread function creates threads with
last_resume_kind == resume_continue by default. This field is
used by resume_stopped_resumed_lwps to decide whether to perform
the resume:
static void
resume_stopped_resumed_lwps (struct inferior_list_entry *entry) {
struct thread_info *thread = (struct thread_info *) entry;
struct lwp_info *lp = get_thread_lwp (thread);
if (lp->stopped
&& !lp->status_pending_p
&& thread->last_resume_kind != resume_stop
&& thread->last_status.kind == TARGET_WAITKIND_IGNORE)
{
So the fix is to make sure to set thread->last_resume_kind to
resume_stop. Here we do that for new fork children in
gdbserver/linux-low.c:handle_extended_wait.
In addition, it seemed prudent to initialize lwp_info.status_pending_p
for the new fork child. I also rearranged the initialization code
so that all of the lwp_info initialization was together, rather than
intermixed with thread_info and process_info initialization.
Tested native, native-gdbserver, native-extended-gdbserver on
x86_64 GNU/Linux.
gdb/gdbserver/
* linux-low.c (handle_extended_wait): Initialize
thread_info.last_resume_kind for new fork children.
This patch fixes a couple of failures in gdb.base/foll-vfork.exp for
extended-remote targets. The failures were the result of the
verbose/debug "Detaching..." messages in infrun.c:follow_fork_inferior
not matching what was expected in the extended-remote case.
The path modifies the ptids used in the messages to ensure that they
print "process nnn" instead of (possibly) "Thread nnn.nnn". The
detach is a process-wide operation, so we need to use a process-
style ptid regardless of what type of ptid target_pid_to_str returns.
Tested on x86_64 GNU/Linux, native, remote, extended-remote.
gdb/
* infrun.c (follow_fork_inferior): Ensure the use of
process-style ptids (pid,0,0) in verbose/debug "Detaching"
messages.
This patch is to remove the global variable arm_linux_has_wmmx_registers
in arm-linux-nat.c, and add a new field have_wmmx_registers in
'struct gdbarch_tdep'.
gdb:
2015-05-28 Yao Qi <yao.qi@linaro.org>
* arm-linux-nat.c (arm_linux_has_wmmx_registers): Remove.
(arm_linux_fetch_inferior_registers): Use
tdep->have_wmmx_registers instead of arm_linux_has_wmmx_registers.
(arm_linux_store_inferior_registers): Likewise.
(arm_linux_read_description): Don't set
arm_linux_has_wmmx_registers.
* arm-tdep.c (arm_gdbarch_init): Set
tdep->have_wmmx_registers according target descriptions.
* arm-tdep.h (struct gdbarch_tdep) <have_wmmx_registers>: New
field.
This patch is to remove the global variable arm_linux_vfp_register_count
from arm-linux-nat.c. This global variable is set when native gdb
looks for the right target description according HWCAP. However,
'struct gdbarch_tdep' has already had a field have_vfp_registers, which
is a boolean about whether target has vfp registers or not. This
patch converts this boolean field to a numeric counter to replace
global variable arm_linux_vfp_register_count.
gdb:
2015-05-28 Yao Qi <yao.qi@linaro.org>
* arm-linux-nat.c (arm_linux_vfp_register_count): Remove.
(fetch_vfp_regs): Use vfp_register_count from gdbarch_tdep
instead of arm_linux_vfp_register_count.
(store_vfp_regs): Likewise.
(arm_linux_fetch_inferior_registers): Likewise.
(arm_linux_store_inferior_registers): Likewise.
(arm_linux_read_description): Don't set
arm_linux_vfp_register_count.
* arm-linux-tdep.c (arm_linux_iterate_over_regset_sections):
Adjust.
* arm-tdep.c (arm_gdbarch_init): Add assert on
vfp_register_count.
* arm-tdep.h (struct gdbarch_tdep) <have_vfp_registers>: Rename
field to vfp_register_count. All users updated.
On ARM systems, gdb must determine which style of breakpoint to use
(see the comments at the beginning of gdb/arm-linux-tdep.c). In
arm_gdbarch_init we only attempt to extract the eabi version from the
ELF binary if it is a ELFOSABI_NONE binary. If the binary is
ELFOSABI_GNU instead, we end up defaulting to the old style OABI
syscall breakpoint instruction. On a Linux kernel built without
CONFIG_OABI_COMPAT, this triggers a SIGILL in ld when attempting to
execute any ELFOSABI_GNU program.
(e.g. https://github.com/raspberrypi/linux/issues/766)
gdb/
2015-05-28 Kyle Huey <me@kylehuey.com> (tiny patch)
* gdb/arm-tdep.c (arm_gdbarch_init): Perform arm_abi detection on
ELFOSABI_GNU binaries.
gdb/ChangeLog:
* dwarf2read.c (lnp_state_machine): New typedef.
(lnp_reader_state): New typedef.
(dwarf_record_line_1): Renamed from dwarf_record_line.
All callers updated.
(dwarf_record_line): New function.
(init_lnp_state_machine): New function.
(check_line_address): Replace p_record_line parameter with state.
All callers updated.
(dwarf_decode_lines_1): Call dwarf_record_line, init_lnp_state_machine.
Update to record state in lnp_state_machine.
We see the following build error:
gdb/aarch64-tdep.c: In function 'aarch64_process_record':
gdb/aarch64-tdep.c:2823:17: error: 'record_buf[0]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
memcpy(®S[0], &RECORD_BUF[0], sizeof(uint32_t)*LENGTH); \
^
gdb/aarch64-tdep.c:3529:12: note: 'record_buf[0]' was declared here
uint32_t record_buf[2];
since record_buf[0] isn't initialized in some paths in which
instruction encodings doesn't exist in current ARMv8 reference manual.
This patch is to let the function return AARCH64_RECORD_UNKNOWN for
these paths.
gdb:
2015-05-27 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (aarch64_record_data_proc_simd_fp): Return
AARCH64_RECORD_UNKNOWN for unknown instruction encoding.
This patch fixes some ARI warnings:
$ bash ./gdb/contrib/ari/gdb_ari.sh -Wall -Werror -Wari gdb/aarch64-tdep.c
gdb/aarch64-tdep.c:3009: code: Do not use &&, or || at the end of a line
gdb/aarch64-tdep.c:3010: code: Do not use &&, or || at the end of a line
gdb/aarch64-tdep.c:3413: code: Do not use &&, or || at the end of a line
gdb/aarch64-tdep.c:3460: code: Do not use &&, or || at the end of a line
This patch moves && from the end of line to the start of the line.
gdb:
2015-05-27 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (aarch64_record_branch_except_sys): Split lines
before operator &&.
(aarch64_record_load_store): Likewise.
gdb/ChangeLog:
* cp-support.c (cp_lookup_rtti_type): Handle the case of NAME being
a typedef.
gdb/testsuite/ChangeLog:
* gdb.cp/iostream.cc: New file.
* gdb.cp/iostream.exp: New file.
This patch adds a test case to test the process record for some of
aarch64 instructions.
In each function, GDB turns on process record, and single step until
program goes to the end of the function. Then, single step backward.
In each of forward single step and backward single step, the contents
of registers are saved, and test compares them. If there is any
differences, a FAIL is emitted.
The test is flexible, and we can test other instructions easily in the
future.
gdb/testsuite:
2015-05-26 Omair Javaid <omair.javaid@linaro.org>
Yao Qi <yao.qi@linaro.org>
* gdb.reverse/aarch64.c: New.
* gdb.reverse/aarch64.exp: New.
This patch enable gdb.reverse tests for aarch64*-linux targets.
With this patch, there are 7 FAILs in gdb.reverse/ tests.
FAIL: gdb.reverse/finish-reverse-bkpt.exp: reverse-finish from void_func trips breakpoint at entry
FAIL: gdb.reverse/finish-reverse-bkpt.exp: no spurious proceed after breakpoint stop
FAIL: gdb.reverse/next-reverse-bkpt-over-sr.exp: reverse-next over call trips user breakpoint at function entry
FAIL: gdb.reverse/step-precsave.exp: reverse step into fn call
FAIL: gdb.reverse/step-precsave.exp: reverse step out of called fn
FAIL: gdb.reverse/step-reverse.exp: reverse step into fn call
FAIL: gdb.reverse/step-reverse.exp: reverse step out of called fn
gdb/testsuite:
2015-05-26 Omair Javaid <omair.javaid@linaro.org>
* lib/gdb.exp (supports_process_record): Return true for aarch64*-linux*.
(supports_reverse): Likewise.
This patch adds the support of aarch64-linux process record and reverse
debugging. The implementation is similar to ARM's counterpart.
2015-05-26 Omair Javaid <omair.javaid@linaro.org>
Yao Qi <yao.qi@linaro.org>
* aarch64-linux-tdep.c: Include linux-record.h and
record-full.h.
(struct linux_record_tdep aarch64_linux_record_tdep): Declare.
(aarch64_syscall): New enum.
(aarch64_canonicalize_syscall): New function.
(aarch64_all_but_pc_registers_record): New function.
(aarch64_linux_syscall_record): New function.
(aarch64_linux_init_abi): Install AArch64 process record
handler. Update to handle syscall recording.
* aarch64-tdep.c: Include record.h and record-full.h.
(submask, bit, bits, REG_ALLOC, MEM_ALLOC): New macros.
(struct aarch64_mem_r): Define.
(aarch64_record_result): New enum.
(struct insn_decode_record): Define.
(insn_decode_record): New typedef.
(aarch64_record_data_proc_reg): New function.
(aarch64_record_data_proc_imm): New function.
(aarch64_record_branch_except_sys): New function.
(aarch64_record_load_store): New function.
(aarch64_record_data_proc_simd_fp): New function.
(aarch64_record_asimd_load_store): New function.
(aarch64_record_decode_insn_handler): New function.
(deallocate_reg_mem): New function.
(aarch64_process_record): New function.
* aarch64-tdep.h (struct gdbarch_tdep) <aarch64_syscall_record>:
New field.
(aarch64_process_record): New extern declaration.
* configure.tgt: Add linux-record.o to gdb_target_obs.
* linux-record.h (struct linux_record_tdep) <arg7>: New field.
This patch adds the NEWS entry for aarch64-linux record replay
support.
It has been reviewed and approved.
gdb:
2015-05-26 Omair Javaid <omair.javaid@linaro.org>
* NEWS: Add a note on process record-replay support on aarch64*-linux*
targets.
We concluded that gdbarch_in_function_epilogue_p is misnamed, since it
returns true if the given PC is one instruction after the one that
destroyed the stack (which isn't necessarily inside an epilogue),
therefore it should be renamed to stack_frame_destroyed_p.
I also took the liberty of renaming the arch-specific implementations to
*_stack_frame_destroyed_p as well for consistency.
gdb:
2015-05-26 Martin Galvan <martin.galvan@tallertechnologies.com>
* amd64-tdep.c: Replace in_function_epilogue_p with
stack_frame_destroyed_p throughout.
* arch-utils.c: Ditto.
* arch-utils.h: Ditto.
* arm-tdep.c: Ditto.
* breakpoint.c: Ditto.
* gdbarch.sh: Ditto.
* hppa-tdep.c: Ditto.
* i386-tdep.c: Ditto.
* mips-tdep.c: Ditto.
* nios2-tdep.c: Ditto.
* rs6000-tdep.c: Ditto.
* s390-linux-tdep.c: Ditto.
* score-tdep.c: Ditto.
* sh-tdep.c: Ditto.
* sparc-tdep.c: Ditto.
* sparc-tdep.h: Ditto.
* sparc64-tdep.c: Ditto.
* spu-tdep.c: Ditto.
* tic6x-tdep.c: Ditto.
* tilegx-tdep.c: Ditto.
* xstormy16-tdep.c: Ditto.
* gdbarch.c, gdbarch.h: Re-generated.
Add new commands to specifically enable and disable tui mode. This is
in addition to the readline bindings, but might be easier for a user to
discover if they accidentally end up in tui mode.
gdb/ChangeLog:
* NEWS: Mention 'tui enable' and 'tui disable'.
* tui/tui.c (tui_enable_command): New function.
(tui_disable_command): New function.
(_initialize_tui): New function.
gdb/doc/ChangeLog:
* gdb.texinfo (TUI): Include 'tui enable' in the introduction.
(TUI Commands): Add 'tui enable' and 'tui disable' details.
Use with_test_prefix to avoid duplicating test names when calling
the procedure test_gdbinit_history_setting multiple times.
gdb/testsuite/ChangeLog:
* gdb.base/gdbinit-history.exp (test_gdbinit_history_setting):
Use with_test_prefix.
Use cleanup to avoid leaking memory if an error occurs during tui
start up.
gdb/ChangeLog:
* tui/tui-layout.c (tui_set_layout_for_display_command): Ensure
buf_ptr is freed.
Calling tui_enable too early in tui_layout_command can leave the tui in
an enabled state if the user has entered an invalid layout name.
Instead postpone the call to tui_enable until later in
tui_set_layout_for_display_command just before the layout is changed.
gdb/ChangeLog:
* tui/tui-layout.c (tui_layout_command): Move call to tui_enable
into ...
(tui_set_layout_for_display_command): ...here, before calling
tui_set_layout. Only set the layout if gdb has not already
entered the TUI_FAILURE state.
Add layout name completion for the layout command.
gdb/ChangeLog:
* tui/tui-layout.c (layout_completer): New function.
(_initialize_tui_layout): Set completer on layout command.
gdb/testsuite/ChangeLog:
* gdb.base/completion.exp: Add test for completion of layout
names.
The layout command supports the layout names $FREGS, $GREGS, $SREGS,
and $REGS. The intention of these layout names was to display the tui
register window with a specific set of registers.
First, these layout names no longer work, and haven't for a while, using
any of them will just result in switching to the general register view.
Second there is already the command 'tui reg GROUP' command to set the
displayed register set to GROUP, so making the layout command also
control the register set feels like unnecessary overloading of the
layout command.
This commit removes all code relating to supporting the register set
specific names from the layout command. Afterwards the user can select
an available layout using the layout command, and control the choice of
register set using the 'tui reg GROUP' command.
gdb/ChangeLog:
* tui/tui-layout.c (tui_set_layout): Remove
tui_register_display_type parameter. Remove all checking of this
parameter, and reindent function. Update header comment.
(tui_set_layout_for_display_command): Rename to...
(tui_set_layout_by_name): ...this, and don't check for different
register class types, don't pass a tui_register_display_type to
tui_set_layout. Update header comment.
(layout_names): Remove register set specific names.
* tui/tui-layout.h (tui_set_layout): Remove
tui_register_display_type parameter.
* tui/tui.c (tui_rl_change_windows): Don't pass a
tui_register_display_type to tui_set_layout.
(tui_rl_delete_other_windows): Likewise.
(tui_enable): Likewise.
* tui/tui-data.h (TUI_FLOAT_REGS_NAME): Remove.
(TUI_FLOAT_REGS_NAME_LOWER): Remove.
(TUI_GENERAL_REGS_NAME): Remove.
(TUI_GENERAL_REGS_NAME_LOWER): Remove.
(TUI_SPECIAL_REGS_NAME): Remove.
(TUI_SPECIAL_REGS_NAME_LOWER): Remove.
(TUI_GENERAL_SPECIAL_REGS_NAME): Remove.
(TUI_GENERAL_SPECIAL_REGS_NAME_LOWER): Remove.
(enum tui_register_display_type): Remove.
(struct tui_layout_def): Remove regs_display_type and
float_regs_display_type fields.
(struct tui_data_info): Remove regs_display_type field.
(tui_layout_command): Use new name for
tui_set_layout_for_display_command.
* tui/tui-data.c (layout_def): Don't initialise removed fields.
(tui_clear_win_detail): Don't initialise removed fields of
win_info.
* tui/tui-regs.c (tui_show_registers): Use new name for
tui_set_layout_for_display_command.
* tui/tui.h (tui_set_layout_for_display_command): Rename
declaration to...
(tui_set_layout_by_name): ...this.
* printcmd.c (display_command): Remove tui related layout call,
and reindent.
Add a new predicate procedure to the gdb.exp library 'skip_tui_tests',
which returns true if the tui is not compiled into gdb.
Make use of this predicate in the gdb.base/tui-layout.exp test as an
example.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (skip_tui_tests): New proc.
* gdb.base/tui-layout.exp: Check skip_tui_tests.
When using a conditional breakpoint where the condition evaluated
to false a large number of times before the program stopped,
a user reported that GDB's memory consumption was growing very
quickly until it ran out of memory.
The problem was tracked down to temporary struct values being created
each time the program stops and handles an inferior event. Because
the breakpoint condition usually evaluates to false, there can be
a fairly large number of such events to be handled before we eventually
return the prompt to the user (which is when we would normally purge
such values).
This patch fixes the issue by making sure that handle_inferior_event
releases all new values created during its execution.
gdb/ChangeLog:
* infrun.c (handle_inferior_event_1): Renames handle_inferior_event.
(handle_inferior_event): New function.
