I noticed that psymtab.c was always copying the search string in
psymtab_search_name, even when it wasn't necessary. This patch
removes this function in favor of using the make_ignore_params feature
of lookup_name_info.
Once I had done that, I noticed that lookup_partial_symbol was
creating a lookup_name_info. However, this function called in loops,
causing even more excess allocation. This patch further fixes this by
hosting the creation of the lookup_name_info into the callers.
gdb/ChangeLog
2020-04-01 Tom Tromey <tromey@adacore.com>
* psymtab.c (psymtab_search_name): Remove function.
(psym_lookup_symbol): Create search name and lookup name here.
(lookup_partial_symbol): Remove "name" parameter; add
lookup_name.
(psym_expand_symtabs_for_function): Update.
py-tui.c can fail to build if the ncurses development headers are not
installed, but if Python was built against ncurses. In this case, the
Python headers will define HAVE_NCURSES_H, confusing gdb_curses.h.
This patch fixes the problem by moving this include inside
"#ifdef TUI".
gdb/ChangeLog
2020-03-31 Joel Jones <joelkevinjones@gmail.com>
PR tui/25597:
* python/py-tui.c: Include gdb_curses.h inside of #ifdef TUI.
I compiled gdb with -fsanitize=undefined and ran the test suite.
A couple of reports came from passing NULL to memcpy, e.g.:
[...]btrace-common.cc:176:13: runtime error: null pointer passed as argument 2, which is declared to never be null
While it would be better to fix this in the standard, in the meantime
it seems easy to avoid this error.
gdb/ChangeLog
2020-03-31 Tom Tromey <tromey@adacore.com>
* dwarf2/abbrev.c (abbrev_table::read): Conditionally call
memcpy.
gdbsupport/ChangeLog
2020-03-31 Tom Tromey <tromey@adacore.com>
* btrace-common.cc (btrace_data_append): Conditionally call
memcpy.
While debugging an Ada regression, I noticed that all the callers of
ada_which_variant_applies desconstruct a value, only to have it be
reconstructed by this function.
This patch removes this inefficiency in favor of simply passing in the
value directly.
Tested on x86-64 Fedora 30.
gdb/ChangeLog
2020-03-30 Tom Tromey <tromey@adacore.com>
* ada-valprint.c (print_variant_part): Update.
* ada-lang.h (ada_which_variant_applies): Update.
* ada-lang.c (ada_which_variant_applies): Remove outer_type and
outer_valaddr parameters; replace with "outer" value parameter.
(to_fixed_variant_branch_type): Update.
This patch fixes some issues with debug register handling for the powerpc
linux native target.
Currently, the target methods for installing and removing hardware
breakpoints and watchpoints in ppc-linux-nat.c affect all threads known to
linux-nat, including threads of different processes.
This patch changes ppc-linux-nat.c so that only the process of
inferior_ptid is affected by these target methods, as GDB expects.
This is done in the same way as various other architectures. The
install/remove target methods only register a hardware breakpoint or
watchpoint, and then send a stop signal to the threads. The debug
registers are only changed with ptrace right before each thread is next
resumed, using low_prepare_to_resume.
There are two interfaces to modify debug registers for linux running on
powerpc, with different sets of ptrace requests:
- PPC_PTRACE_GETHWDBGINFO, PPC_PTRACE_SETHWDEBUG, and
PPC_PTRACE_DELHWDEBUG.
Or
- PTRACE_SET_DEBUGREG and PTRACE_GET_DEBUGREG
The first set (HWDEBUG) is the more flexible one and allows setting
watchpoints with a variable watched region length and, for certain
embedded processors, multiple types of debug registers (e.g. hardware
breakpoints and hardware-assisted conditions for watchpoints).
Currently, server processors only provide one watchpoint. The second one
(DEBUGREG) only allows setting one debug register, a watchpoint, so we
only use it if the first one is not available.
The HWDEBUG interface handles debug registers with slot numbers. Once a
hardware watchpoint or breakpoint is installed (with
PPC_PTRACE_SETHWDEBUG), ptrace returns a slot number. This slot number
can then be used to remove the watchpoint or breakpoint from the inferior
(with PPC_PTRACE_DELHWDEBUG). The first interface also provides a
bitmask of available debug register features, which can be obtained with
PPC_PTRACE_GETHWDBGINFO.
When GDB first tries to use debug registers, we try the first interface
with a ptrace call, and if it isn't available, we fall back to the second
one, if available. We use EIO as an indicator that an interface is not
available in the kernel. For simplicity, with any other error we
immediately assume no interface is available. Unfortunately this means
that if a process is killed by a signal right before we try to detect the
interface, we might get an ESRCH, which would prevent debug registers to
be used in the GDB session. However, it isn't clear that we can safely
raise an exception and try again in the future in all the contexts where
we try to detect the interface.
If the HWDEBUG interface works but provides no feature bits, the target
falls back to the DEBUGREG interface. When the kernel is configured
without CONFIG_HW_BREAKPOINTS (selected by CONFIG_PERF_EVENTS), there is
a bug that causes watchpoints installed with the HWDEBUG interface not to
trigger. When this is the case, the feature bits will be zero, which is
used as the indicator to fall back to the DEBUGREG interface. This isn't
ideal, but has always been the behavior of GDB before this patch, so I
decided not to change it.
A flag indicates for each thread if its debug registers need to be
updated the next time it is resumed. The flag is set whenever the upper
layers request or remove a hardware watchpoint or breakpoint, or when a
new thread is detected. Because some kernel configurations disable
watchpoints after they are hit, we also use the last stop reason of the
LWP to determine whether we should update the debug registers. It isn't
clear that this is also true of BookE hardware breakpoints, but we also
check their stop reason to be on the safe side, since it doesn't hurt.
A map from process numbers to hardware watchpoint or breakpoint objects
keeps track of what has been requested by the upper layers of GDB, since
for GDB installing a hardware watchpoint or breakpoint means doing so for
the whole process.
When using the HWDEBUG interface we also have to keep track of which
slots were last installed in each thread with a map from threads to the
slots, so that they can be removed when needed. When resuming a thread,
we remove all the slots using this map, then we install all the hardware
watchpoints and breakpoints from the per-process map of requests, and
then update the per-thread map accordingly.
This per-thread state is also used for copying the debug register state
after a fork or a clone is detected. The kernel might do this depending
on the configuration. Recent kernels running on server processors that
were configured with CONFIG_PERF_EVENTS (and therefore
CONFIG_HW_BREAKPOINTS) don't copy debug registers across forks and
clones. Recent kernels without CONFIG_HW_BREAKPOINTS copy this state. I
believe that on embedded processors (e.g. a ppc440) the debug register
state is copied, but I haven't been able to test this. To handle both
cases, the per-thread state is always copied when forks and clones are
detected, and when we resume the thread and delete the debug register
slots before updating them, we ignore ENOENT errors.
We don't need to handle this when using the DEBUGREG interface since it
only allows one hardware watchpoint and doesn't return slot numbers, we
just set or clear this watchpoint when needed.
Since we signal running threads to stop after a request is processed, so
that we can update their debug registers when they are next resumed,
there will be a time between signalling the threads and their stop during
which the debug registers haven't been updated, even if the target
methods completed.
The tests in gdb.threads/watchpoint-fork.exp no longer fail with this
patch.
gdb/ChangeLog:
2020-03-30 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* ppc-linux-nat.c: Include <algorithm>, <unordered_map>, and
<list>. Remove inclusion of observable.h.
(PPC_DEBUG_CURRENT_VERSION): Move up define.
(struct arch_lwp_info): New struct.
(class ppc_linux_dreg_interface): New class.
(struct ppc_linux_process_info): New struct.
(struct ppc_linux_nat_target) <low_delete_thread, low_new_fork>
<low_new_clone, low_forget_process, low_prepare_to_resume>
<copy_thread_dreg_state, mark_thread_stale>
<mark_debug_registers_changed, register_hw_breakpoint>
<clear_hw_breakpoint, register_wp, clear_wp>
<can_use_watchpoint_cond_accel, calculate_dvc, check_condition>
<num_memory_accesses, get_trigger_type>
<create_watchpoint_request, hwdebug_point_cmp>
<init_arch_lwp_info, get_arch_lwp_info>
<low_stopped_by_watchpoint, low_stopped_data_address>: Declare as
methods.
<struct ptid_hash>: New inner struct.
<m_dreg_interface, m_process_info, m_installed_hw_bps>: Declare
members.
(saved_dabr_value, hwdebug_info, max_slots_number)
(struct hw_break_tuple, struct thread_points, ppc_threads)
(have_ptrace_hwdebug_interface)
(hwdebug_find_thread_points_by_tid)
(hwdebug_insert_point, hwdebug_remove_point): Remove.
(ppc_linux_nat_target::can_use_hw_breakpoint): Use
m_dreg_interface, remove call to PTRACE_SET_DEBUGREG.
(ppc_linux_nat_target::region_ok_for_hw_watchpoint): Add comment,
use m_dreg_interface.
(hwdebug_point_cmp): Change to...
(ppc_linux_nat_target::hwdebug_point_cmp): ...this method. Use
reference arguments instead of pointers.
(ppc_linux_nat_target::ranged_break_num_registers): Use
m_dreg_interface.
(ppc_linux_nat_target::insert_hw_breakpoint): Add comment, use
m_dreg_interface. Call register_hw_breakpoint.
(ppc_linux_nat_target::remove_hw_breakpoint): Add comment, use
m_dreg_interface. Call clear_hw_breakpoint.
(get_trigger_type): Change to...
(ppc_linux_nat_target::get_trigger_type): ...this method. Add
comment.
(ppc_linux_nat_target::insert_mask_watchpoint): Update comment,
use m_dreg_interface. Call register_hw_breakpoint.
(ppc_linux_nat_target::remove_mask_watchpoint): Update comment,
use m_dreg_interface. Call clear_hw_breakpoint.
(can_use_watchpoint_cond_accel): Change to...
(ppc_linux_nat_target::can_use_watchpoint_cond_accel): ...this
method. Update comment, use m_dreg_interface and
m_process_info.
(calculate_dvc): Change to...
(ppc_linux_nat_target::calculate_dvc): ...this method. Use
m_dreg_interface.
(num_memory_accesses): Change to...
(ppc_linux_nat_target::num_memory_accesses): ...this method.
(check_condition): Change to...
(ppc_linux_nat_target::check_condition): ...this method.
(ppc_linux_nat_target::can_accel_watchpoint_condition): Update
comment, use m_dreg_interface.
(create_watchpoint_request): Change to...
(ppc_linux_nat_target::create_watchpoint_request): ...this
method. Use m_dreg_interface.
(ppc_linux_nat_target::insert_watchpoint): Add comment, use
m_dreg_interface. Call register_hw_breakpoint or register_wp.
(ppc_linux_nat_target::remove_watchpoint): Add comment, use
m_dreg_interface. Call clear_hw_breakpoint or clear_wp.
(ppc_linux_nat_target::low_forget_process)
(ppc_linux_nat_target::low_new_fork)
(ppc_linux_nat_target::low_new_clone)
(ppc_linux_nat_target::low_delete_thread)
(ppc_linux_nat_target::low_prepare_to_resume): New methods.
(ppc_linux_nat_target::low_new_thread): Remove previous logic,
only call mark_thread_stale.
(ppc_linux_thread_exit): Remove.
(ppc_linux_nat_target::stopped_data_address): Change to...
(ppc_linux_nat_target::low_stopped_data_address): This. Add
comment, use m_dreg_interface and m_thread_hw_breakpoints.
(ppc_linux_nat_target::stopped_by_watchpoint): Change to...
(ppc_linux_nat_target::stopped_by_watchpoint): This. Add
comment. Call low_stopped_data_address.
(ppc_linux_nat_target::watchpoint_addr_within_range): Use
m_dreg_interface.
(ppc_linux_nat_target::masked_watch_num_registers): Use
m_dreg_interface.
(ppc_linux_nat_target::copy_thread_dreg_state)
(ppc_linux_nat_target::mark_thread_stale)
(ppc_linux_nat_target::mark_debug_registers_changed)
(ppc_linux_nat_target::register_hw_breakpoint)
(ppc_linux_nat_target::clear_hw_breakpoint)
(ppc_linux_nat_target::register_wp)
(ppc_linux_nat_target::clear_wp)
(ppc_linux_nat_target::init_arch_lwp_info)
(ppc_linux_nat_target::get_arch_lwp_info): New methods.
(_initialize_ppc_linux_nat): Remove observer callback.
This patch adds a low_new_clone method to linux_nat_target, called after
a PTRACE_EVENT_CLONE is detected, similar to how low_new_fork is called
after PTRACE_EVENT_(V)FORK.
This is useful for targets that need to copy state associated with a
thread that is inherited across clones.
gdb/ChangeLog:
2020-03-30 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* linux-nat.h (low_new_clone): New method.
* linux-nat.c (linux_handle_extended_wait): Call low_new_clone.
As I am trying to understand the dynamic of partial_symtab::read_symtab
and partial_symtab::expand_psymtab, I think that renaming these
functions helps make it clear that they are effectively implementations
of the partial_symtab::expand_psymtab method.
gdb/ChangeLog:
* dbxread.c (dbx_psymtab_to_symtab_1): Rename to...
(dbx_expand_psymtab): ... this.
(start_psymtab): Update.
* mdebugread.c (psymtab_to_symtab_1): Rename to...
(mdebug_expand_psymtab): ... this.
(parse_partial_symbols): Update.
(new_psymtab): Update.
* xcoffread.c (xcoff_psymtab_to_symtab_1): Rename to...
(xcoff_expand_psymtab): ... this.
(xcoff_start_psymtab): Update.
This method calls partial_symtab::expand_psymtab on all dependencies of
a psymtab. Given that there is also a partial_symtab::read_symtab
method, I think it would be clearer to name this function
expand_dependencies, rather than read_dependencies.
gdb/ChangeLog:
* psympriv.h (partial_symtab) <read_dependencies>: Rename to...
<expand_dependencies>: ... this.
* psymtab.c (partial_symtab::read_dependencies): Rename to...
(partial_symtab::expand_dependencies): ... this.
* dwarf2/read.c (dwarf2_include_psymtab) <expand_psymtab>:
Update.
(dwarf2_psymtab::expand_psymtab): Update.
* dbxread.c (dbx_psymtab_to_symtab_1): Update.
* mdebugread.c (psymtab_to_symtab_1): Update.
* xcoffread.c (xcoff_psymtab_to_symtab_1): Update.
This function does not add much value, compared to calling the method on
the psymtab_storage object directly.
gdb/ChangeLog:
* psympriv.h (discard_psymtab): Remove.
* dbxread.c (dbx_end_psymtab): Update.
* xcoffread.c (xcoff_end_psymtab): Update.
I noticed that a comment in dwarf2/attribute.h still referred to
dwarf2_get_attr_constant_value. However, this is now a method on
struct attribute.
gdb/ChangeLog
2020-03-28 Tom Tromey <tom@tromey.com>
* dwarf2/attribute.h (struct attribute) <form_is_constant>: Update
comment.
I noticed that the start of read_attribute_reprocess had the wrong
formatting. This patch fixes it.
gdb/ChangeLog
2020-03-28 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (read_attribute_reprocess): Fix formatting.
GetModuleFileNameEx might also return the 64bit system directory for 32bit
programs even for a 32bit gdb:
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x779d0000 0x77b34d20 Yes (*) C:\Windows\SysWOW64\ntdll.dll
0x76850000 0x7694ad9c Yes (*) C:\Windows\syswow64\kernel32.dll
0x75421000 0x75466a18 Yes (*) C:\Windows\syswow64\KernelBase.dll
0x6fbe1000 0x6fcca1c0 Yes (*) C:\Windows\system32\dbghelp.dll
0x76d31000 0x76ddb2c4 Yes (*) C:\Windows\syswow64\msvcrt.dll
So this makes the path conversion for all 32bit programs.
gdb/ChangeLog:
2020-03-27 Hannes Domani <ssbssa@yahoo.de>
* windows-nat.c (windows_add_all_dlls): Fix system dll paths.
FreeBSD's kernel recently added a new ELF auxiliary vector entry
holding a mask of software features provided by the kernel. This
change fixes 'info auxv' to report the name and description for this
vector entry instead of '???'.
include/ChangeLog:
* elf/common.h (AT_FREEBSD_BSDFLAGS): Define.
gdb/ChangeLog:
* fbsd-tdep.c (fbsd_print_auxv_entry): Handle AT_FREEBSD_BSDFLAGS.
This changes dwarf2_get_ref_die_offset and
dwarf2_get_attr_constant_value to be methods on struct attribute.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (handle_data_member_location, dwarf2_add_field)
(mark_common_block_symbol_computed, read_tag_string_type)
(attr_to_dynamic_prop, read_subrange_type): Update.
(dwarf2_get_ref_die_offset, dwarf2_get_attr_constant_value): Move
to be methods on struct attribute.
(skip_one_die, process_imported_unit_die, read_namespace_alias)
(read_call_site_scope, partial_die_info::read)
(partial_die_info::read, lookup_die_type, follow_die_ref):
Update.
* dwarf2/attribute.c (attribute::get_ref_die_offset): New method,
from dwarf2_get_ref_die_offset.
(attribute::constant_value): New method, from
dwarf2_get_attr_constant_value.
* dwarf2/attribute.h (struct attribute) <get_ref_die_offset>:
Declare method.
<constant_value>: New method.
This moves the DWARF debugging functions that stringify various
constants to a new file, dwarf2/stringify.c.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf_unit_type_name, dwarf_tag_name)
(dwarf_attr_name, dwarf_form_name, dwarf_bool_name)
(dwarf_type_encoding_name): Move to stringify.c.
* Makefile.in (COMMON_SFILES): Add dwarf2/stringify.c.
* dwarf2/stringify.c: New file.
* dwarf2/stringify.h: New file.
This rewrites the two new die_info methods to iterate over attributes
rather than to do two separate searches.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/die.h (struct die_info) <addr_base, ranges_base>:
Rewrite.
This changes lookup_addr_base and lookup_ranges_base to be methods on
die_info.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/die.h (struct die_info) <addr_base, ranges_base>: New
methods.
* dwarf2/read.c (lookup_addr_base): Move to die.h.
(lookup_ranges_base): Likewise.
(read_cutu_die_from_dwo, read_full_die_1): Update.
The sibling_die helper function does not seem to add much value,
considering that many other fields of die_info are directly accessed.
So, this removes it.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (read_import_statement, read_file_scope)
(read_type_unit_scope, inherit_abstract_dies, read_func_scope)
(read_lexical_block_scope, read_call_site_scope)
(dwarf2_get_subprogram_pc_bounds, get_scope_pc_bounds)
(handle_struct_member_die, process_structure_scope)
(update_enumeration_type_from_children)
(process_enumeration_scope, read_array_type, read_common_block)
(read_namespace, read_module, read_subroutine_type): Update.
(sibling_die): Remove.
This changes dwarf2_attr_no_follow to be a method on die_info.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (lookup_addr_base, lookup_ranges_base)
(build_type_psymtabs_reader, read_structure_type)
(read_enumeration_type, read_full_die_1): Update.
(dwarf2_attr_no_follow): Move to die.h.
* dwarf2/die.h (struct die_info) <attr>: New method.
This removes dwarf2_cu::base_known, changing base_address to be a
gdb::optional.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (struct dwarf2_cu) <base_known>: Remove.
<base_address>: Now an optional.
(dwarf2_find_base_address, dwarf2_rnglists_process)
(dwarf2_ranges_process, fill_in_loclist_baton)
(dwarf2_symbol_mark_computed): Update.
This moves struct die_info to a new header, dwarf2/die.h.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (struct die_info): Move to die.h.
* dwarf2/die.h: New file.
This moves some more code out of read.c and into line-header.c.
dwarf_decode_line_header is split into two -- the part remaining in
read.c handles interfacing to the dwarf2_cu; while the part in
line-header.c (more or less) purely handles the actual decoding.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/line-header.h (dwarf_decode_line_header): Declare.
* dwarf2/read.c
(dwarf2_statement_list_fits_in_line_number_section_complaint):
Move to line-header.c.
(read_checked_initial_length_and_offset, read_formatted_entries):
Likewise.
(dwarf_decode_line_header): Split into two.
* dwarf2/line-header.c
(dwarf2_statement_list_fits_in_line_number_section_complaint):
Move from read.c.
(read_checked_initial_length_and_offset, read_formatted_entries):
Likewise.
(dwarf_decode_line_header): New function, split from read.c.
This changes read_indirect_line_string to be a method on
dwarf2_per_objfile. This makes it a bit simpler to share between
files.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct dwarf2_per_objfile) <read_line_string>:
Declare method.
* dwarf2/read.c (read_attribute_value): Update.
(dwarf2_per_objfile::read_line_string): Rename from
read_indirect_line_string.
(read_formatted_entries): Update.
One spot in dwarf_decode_macro_bytes could use the existing "objfile"
local variable.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/macro.c (dwarf_decode_macro_bytes): Use objfile local
variable.
This changes the DWARF macro reader to use a const dwarf2_section_info.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/macro.h (dwarf_decode_macros): Make section parameter
const.
* dwarf2/macro.c (skip_form_bytes, skip_unknown_opcode)
(dwarf_decode_macro_bytes, dwarf_decode_macros): Make section
parameter const.
This changes a few line_header methods to be const. In some cases, a
const overload is added.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/line-header.h (struct line_header) <is_valid_file_index,
file_names_size, file_full_name, file_file_name>: Use const.
<file_name_at, file_names>: Add const overload.
* dwarf2/line-header.c (line_header::file_file_name)
(line_header::file_full_name): Update.
This moves some more code out of dwarf2/read.c, introducing new files
dwarf2/macro.c and dwarf2/macro.h.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf2_macro_malformed_definition_complaint)
(macro_start_file, consume_improper_spaces)
(parse_macro_definition, skip_form_bytes, skip_unknown_opcode)
(dwarf_parse_macro_header, dwarf_decode_macro_bytes)
(dwarf_decode_macros): Move to macro.c.
* dwarf2/macro.c: New file.
* dwarf2/macro.h: New file.
* Makefile.in (COMMON_SFILES): Add dwarf2/macro.c.
This moves a string-reading function to be a method on
dwarf2_section_info, and then updates the users.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/section.h (struct dwarf2_section_info) <read_string>: New
method.
* dwarf2/section.c: New method. From
read_indirect_string_at_offset_from.
* dwarf2/read.c (mapped_debug_names::namei_to_name): Update.
(read_indirect_string_at_offset_from): Move to section.c.
(read_indirect_string_at_offset): Rewrite.
(read_indirect_line_string_at_offset): Remove.
(read_indirect_string, read_indirect_line_string)
(dwarf_decode_macro_bytes): Update.
This splits dwarf_decode_macros into two overloads -- one that's
suitable for splitting into a separate file, and one that finds the
correct section and should remain in dwarf2/read.c.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf_decode_macros): Split into two overloads.
This changes dwarf_decode_macro_bytes to accept a buildsym_compunit
rather than a dwarf2_cu. This enables some subsequent changes; and
also makes the function accept a "more specific" parameter.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (macro_start_file): Change "cu" parameter to
"builder".
(dwarf_decode_macro_bytes): Likewise. Add dwarf2_per_objfile
parameter.
(dwarf_decode_macros): Update.
This changes read_indirect_string_from_dwz to be a method on the
dwz_file, and adds a new dwarf2/dwz.c file.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (read_attribute_value): Update.
(read_indirect_string_from_dwz): Move to dwz.c; change into
method.
(dwarf_decode_macro_bytes): Update.
* dwarf2/dwz.h (struct dwz_file) <read_string>: Declare method.
* dwarf2/dwz.c: New file.
* Makefile.in (COMMON_SFILES): Add dwz.c.
I noticed that an error message in compile-object-load.c mentions the
wrong symbol name. The loop just above the error is looking for
COMPILE_I_EXPR_VAL, but the error references COMPILE_I_EXPR_PTR_TYPE.
I'm checking this in as obvious. I don't have a test case -- I
noticed it because another patch I'm working on caused this error to
be thrown, but that was due to regression in my patch.
gdb/ChangeLog
2020-03-25 Tom Tromey <tom@tromey.com>
* compile/compile-object-load.c (get_out_value_type): Mention
correct symbol name in error message.
GetModuleFileNameEx returns for some DLLs of WOW64 processes
the path inside the 64bit system directory instead of the 32bit
syswow64 directory.
Problem happens e.g. with dbghelp.dll:
(gdb) start
Temporary breakpoint 1 at 0x415a00: file fiber.cpp, line 430.
Starting program: C:\src\tests\fiber.exe
warning: `C:\Windows\system32\dbghelp.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
Temporary breakpoint 1, main () at fiber.cpp:430
430 {
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x77070000 0x771d4d20 Yes (*) C:\Windows\SysWOW64\ntdll.dll
0x74dc0000 0x74ebad9c Yes (*) C:\Windows\syswow64\kernel32.dll
0x75341000 0x75386a18 Yes (*) C:\Windows\syswow64\KernelBase.dll
0x6f6a1000 0x6f7c48fc Yes (*) C:\Windows\system32\dbghelp.dll
0x74d01000 0x74dab2c4 Yes (*) C:\Windows\syswow64\msvcrt.dll
(*): Shared library is missing debugging information.
This detects this situation and converts the DLL path to the
syswow64 equivalent.
gdb/ChangeLog:
2020-03-25 Hannes Domani <ssbssa@yahoo.de>
* windows-nat.c (windows_add_all_dlls): Fix system dll paths.
The type struct compunit_symtab contains two fields (disregarding field next)
that express relations with other compunit_symtabs: user and includes.
These fields are currently not printed with "maint info symtabs" and
"maint print symbols".
Fix this such that for "maint info symtabs" we print:
...
{ ((struct compunit_symtab *) 0x23e8450)
debugformat DWARF 2
producer (null)
dirname (null)
blockvector ((struct blockvector *) 0x23e8590)
+ user ((struct compunit_symtab *) 0x2336280)
+ ( includes
+ ((struct compunit_symtab *) 0x23e85e0)
+ ((struct compunit_symtab *) 0x23e8960)
+ )
{ symtab <unknown> ((struct symtab *) 0x23e85b0)
fullname (null)
linetable ((struct linetable *) 0x0)
}
}
...
And for "maint print symbols" we print:
...
-Symtab for file <unknown>
+Symtab for file <unknown> at 0x23e85b0
Read from object file /data/gdb_versions/devel/a.out (0x233ccf0)
Language: c
Blockvector:
block #000, object at 0x23e8530, 0 syms/buckets in 0x0..0x0
block #001, object at 0x23e84d0 under 0x23e8530, 0 syms/buckets in 0x0..0x0
+Compunit user: 0x2336300
+Compunit include: 0x23e8900
+Compunit include: 0x23dd970
...
Note: for user and includes we don't list the actual compunit_symtab address,
but instead the corresponding symtab address, which allows us to find that
symtab elsewhere in the output (given that we also now print the address of
symtabs).
gdb/ChangeLog:
2020-03-25 Tom de Vries <tdevries@suse.de>
* symtab.h (is_main_symtab_of_compunit_symtab): New function.
* symmisc.c (dump_symtab_1): Print user and includes fields.
(maintenance_info_symtabs): Same.
When setting up function parameters we already perform NaN boxing, as
required by the RISC-V ABI, however, we don't do this when writing
values into registers as part of setting up a return value.
This commit moves the NaN boxing code into a small helper function,
and then makes use of this function when setting up function
parameters, and also when setting up return values.
This should resolve this failure:
FAIL: gdb.base/return-nodebug.exp: float: full width of the returned result
gdb/ChangeLog:
PR gdb/25489
* riscv-tdep.c (riscv_arg_info::c_offset): Update comment.
(riscv_regcache_cooked_write): New function.
(riscv_push_dummy_call): Use new function.
(riscv_return_value): Likewise.
The type struct partial_symtab contains two fields (disregarding field next)
that express relations with other symtabs: user and dependencies.
When using "maint print psymbols", we see both the dependencies and the user
fields:
...
Partial symtab for source file (object 0x35ef270)
...
Depends on 0 other partial symtabs.
Shared partial symtab with user 0x35d5f40
...
But with "maint info psymtabs", we only see dependencies:
...
{ psymtab ((struct partial_symtab *) 0x35ef270)
...
dependencies (none)
}
...
Add printing of the user field for "maint info psymtabs", such that we have:
...
{ psymtab ((struct partial_symtab *) 0x35ef270)
...
+ user hello.c ((struct partial_symtab *) 0x35d5f40)
dependencies (none)
}
...
Tested on x86_64-linux.
gdb/ChangeLog:
2020-03-24 Tom de Vries <tdevries@suse.de>
* psymtab.c (maintenance_info_psymtabs): Print user field.
dwarf2_evaluate_property should not modify its "addr_stack"
parameter's contents. This patch makes this part of the API, by
marking it const.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* dwarf2/loc.h (dwarf2_evaluate_property): Make "addr_stack"
const.
* dwarf2/loc.c (dwarf2_evaluate_property): Make "addr_stack"
const.
I stumbled on this snippet in nat/gdb_ptrace.h:
/* Some systems, in particular DEC OSF/1, Digital Unix, Compaq Tru64
or whatever it's called these days, don't provide a prototype for
ptrace. Provide one to silence compiler warnings. */
#ifndef HAVE_DECL_PTRACE
extern PTRACE_TYPE_RET ptrace();
#endif
I believe this is unnecessary today and should be removed. First, the
comment only mentions OSes we don't support (and to be honest, I had
never even heard of).
But most importantly, in C++, a declaration with empty parenthesis
declares a function that accepts no arguments, unlike in C. So if this
declaration was really used, GDB wouldn't build, since all ptrace call
sites pass some arguments. Since we haven't heard anything about this
causing some build failures since we have transitioned to C++, I
conclude that it's not used.
This patch removes it as well as the corresponding configure check.
gdb/ChangeLog:
* ptrace.m4: Don't check for ptrace declaration.
* config.in: Re-generate.
* configure: Re-generate.
* nat/gdb_ptrace.h: Don't declare ptrace if HAVE_DECL_PTRACE is
not defined.
gdbserver/ChangeLog:
* config.in: Re-generate.
* configure: Re-generate.
gdbsupport/ChangeLog:
* config.in: Re-generate.
* configure: Re-generate.
Linux returns long from ptrace(2) and BSDs int.
gdb/ChangeLog:
* amd64-bsd-nat.c (gdb_ptrace): Change return type from `int' to
`PTRACE_TYPE_RET'.
* i386-bsd-nat.c (gdb_ptrace): Likewise.
* sparc-nat.c (gdb_ptrace): Likewise.
* x86-bsd-nat.c (gdb_ptrace): Likewise.
The "restrict" patch added some asserts to c-exp.y, but one spot was
copy-pasted and referred to the wrong table. This was pointed out by
-fsanitize=address. This patch fixes the bug.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* c-exp.y (lex_one_token): Fix assert.
I configured with -fsanitize=address and built gdb. linux-tdep.c and
ada-tasks.c failed to build due to some stringop-truncation errors,
e.g.:
In function ‘char* strncpy(char*, const char*, size_t)’,
inlined from ‘int linux_fill_prpsinfo(elf_internal_linux_prpsinfo*)’ at ../../binutils-gdb/gdb/linux-tdep.c:1742:11,
inlined from ‘char* linux_make_corefile_notes(gdbarch*, bfd*, int*)’ at ../../binutils-gdb/gdb/linux-tdep.c:1878:27:
/usr/include/bits/string_fortified.h:106:34: error: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ specified bound 81 equals destination size [-Werror=stringop-truncation]
This patch fixes the problem by using "sizeof - 1" in the call to
strndup, as recommended in the GCC manual. This doesn't make a
difference here because the next line, in all cases, sets the final
element to '\0' anyway.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* ada-tasks.c (read_atcb): Use smaller length in strncpy call.
* linux-tdep.c (linux_fill_prpsinfo): Use smaller length in
strncpy call.
Andrew Burgess pointed out on irc that "maint info line-table" doesn't
properly align the table headers. This patch fixes the problem by
switching the table to use ui-out.
This required a small tweak to one test case, as ui-out will pad a
field using spaces, even at the end of a line.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* symmisc.c (maintenance_print_one_line_table): Use ui_out.
gdb/testsuite/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* gdb.dwarf2/dw2-ranges-base.exp: Update regular expressions.
The removal of val_print caused a regression in the Ada code. In one
scenario, a variant type would not be properly printed, because the
address of a component was lost. This patch fixes the bug by changing
this API to be value-based. This is cleaner and fixes the bug as a
side effect.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* ada-valprint.c (print_variant_part): Remove parameters; switch
to value-based API.
(print_field_values): Likewise.
(ada_val_print_struct_union): Likewise.
(ada_value_print_1): Update.
gdb/testsuite/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* gdb.ada/sub_variant/subv.adb: New file.
* gdb.ada/sub_variant.exp: New file.
gdb/ChangeLog:
* ppc-nbsd-nat.c (ppc_nbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* ppc-nbsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* hppa-nbsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* (store_registers): Likewise.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* ppc-nbsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* (store_registers): Likewise.
Unlike most other Operating Systems, NetBSD tracks both pid and lwp.
The process id on NetBSD is stored always in the pid field of ptid.
gdb/ChangeLog:
* inf-ptrace.h: Disable get_ptrace_pid on NetBSD.
* inf-ptrace.c: Likewise.
* (gdb_ptrace): Add.
* (inf_ptrace_target::resume): Update.
* (inf_ptrace_target::xfer_partial): Likewise.
* (inf_ptrace_peek_poke): Change argument `pid' to `ptid'.
* (inf_ptrace_peek_poke): Update.
I was doing some SVE tests on system QEMU and noticed quite a few failures
related to inferior function calls. Any attempt to do an inferior function
call would result in the following:
Unable to set VG register.: Success.
This happens because, after an inferior function call, GDB attempts to restore
the regcache state and updates the SVE register in order. Since the Z registers
show up before the VG register, VG is still INVALID by the time the first Z
register is being updated. So when executing the following code in
aarch64_sve_set_vq:
if (reg_buf->get_register_status (AARCH64_SVE_VG_REGNUM) != REG_VALID)
return false;
By returning false, we signal something is wrong, then we get to this:
/* First store vector length to the thread. This is done first to ensure the
ptrace buffers read from the kernel are the correct size. */
if (!aarch64_sve_set_vq (tid, regcache))
perror_with_name (_("Unable to set VG register."));
Ideally we'd always have a valid VG before attempting to set the Z registers,
but in this case the ordering of registers doesn't make that possible.
I considered reordering the registers to put VG before the Z registers, like
the DWARF numbering, but that would break backwards compatibility with
existing implementations. Also, the Z register numbering is pinned to the V
registers, and adding VG before Z would create a gap for non-SVE targets,
since we wouldn't be able to undefine VG for non-SVE targets.
As a compromise, it seems we can safely fetch the VG register value from
ptrace. The value in the kernel is likely the updated value anyway.
This patch fixed all the failures i saw in the testsuite and caused no further
regressions.
gdb/ChangeLog:
2020-03-19 Luis Machado <luis.machado@linaro.org>
* nat/aarch64-sve-linux-ptrace.c (aarch64_sve_set_vq): If vg is not
valid, fetch vg value from ptrace.
Add gdb_ptrace() that wraps the ptrace(2) API and correctly passes
the pid,lwp pair to the calls on NetBSD; and the result of
get_ptrace_pid() on other BSD Operating Systems.
gdb/ChangeLog:
* x86-bsd-nat.c (gdb_ptrace): New.
* (x86bsd_dr_set): Add new argument `ptid'.
* (x86bsd_dr_get, x86bsd_dr_set, x86bsd_dr_set_control,
x86bsd_dr_set_addr): Update.
In this commit:
commit 24ed6739b6
Date: Thu Jan 30 14:35:40 2020 +0000
gdb/remote: Restore support for 'S' stop reply packet
A regression was introduced such that the W and X packets would give a
warning in some cases. The warning was:
warning: multi-threaded target stopped without sending a thread-id, using first non-exited thread
This problem would arise when:
1. The multi-process extensions to the remote protocol were not
being used, and
2. The inferior has multiple threads.
In this case when the W (or X) packet arrives the ptid of the
stop_reply is set to null_ptid, then when we arrive in
process_stop_reply GDB spots that we have multiple non-exited theads,
but the stop event didn't specify a thread-id.
The problem with this is that the W (and X) packets are actually
process wide events, they apply to all threads. So not specifying a
thread-id is not a problem, in fact, the best these packets allow is
for the remote to specify a process-id, not a thread-id.
If we look at how the W (and X) packets deal with a specified
process-id, then what happens is GDB sets to stop_reply ptid to a
value which indicates all threads in the process, this is done by
creating a value `ptid_t (pid)`, which sets the pid field of the
ptid_t, but leaves the tid field as 0, indicating all threads.
So, this commit does the same thing for the case where there is not
process-id specified. In process_stop_reply we not distinguish
between stop events that apply to all threads, and those that apply to
only one. If the stop event applies to only one thread then we treat
it as before. If, however, the stop event applies to all threads,
then we find the first non-exited thread, and use the pid from this
thread to create a `ptid_t (pid)` value.
If the target has multiple inferiors, and receives a process wide
event without specifying a process-id GDB now gives this warning:
warning: multi-inferior target stopped without sending a process-id, using first non-exited inferior
gdb/ChangeLog:
* remote.c (remote_target::process_stop_reply): Handle events for
all threads differently.
gdb/testsuite/ChangeLog:
* gdb.server/exit-multiple-threads.c: New file.
* gdb.server/exit-multiple-threads.exp: New file.
Consider debugging the following C++ program:
struct object
{ int a; };
typedef object *object_p;
static int
get_value (object_p obj)
{
return obj->a;
}
int
main ()
{
object obj;
obj.a = 0;
return get_value (&obj);
}
Now in a GDB session:
(gdb) complete break get_value
break get_value(object*)
break get_value(object_p)
Or:
(gdb) break get_va<TAB>
(gdb) break get_value(object<RETURN>
Function "get_value(object" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
The reason this happens is that we add completions based on the
msymbol names and on the symbol names. For C++ both of these names
include the parameter list, however, the msymbol names have some
differences from the symbol names, for example:
+ typedefs are resolved,
+ whitespace rules are different around pointers,
+ the 'const' keyword is placed differently.
What this means is that the msymbol names and symbol names appear to
be completely different to GDB's completion tracker, and therefore to
readline when it offers the completions.
This commit builds on the previous commit which reworked the
completion_tracker class. It is now trivial to add a
remove_completion member function, this is then used along with
cp_canonicalize_string_no_typedefs to remove the msymbol aliases from
the completion tracker as we add the symbol names.
Now, for the above program GDB only presents a single completion for
'get_value', which is 'get_value(object_p)'.
It is still possible to reference the symbol using the msymbol name,
so a user can manually type out 'break get_value (object *)' if they
wish and will get the expected behaviour.
I did consider adding an option to make this alias exclusion optional,
in the end I didn't bother as I didn't think it would be very useful,
but I can easily add such an option if people think it would be
useful.
gdb/ChangeLog:
* completer.c (completion_tracker::remove_completion): Define new
function.
* completer.h (completion_tracker::remove_completion): Declare new
function.
* symtab.c (completion_list_add_symbol): Remove aliasing msymbols
when adding a C++ function symbol.
gdb/testsuite/ChangeLog:
* gdb.linespec/cp-completion-aliases.cc: New file.
* gdb.linespec/cp-completion-aliases.exp: New file.
Change-Id: Ie5c7c9fc8ecf973072cfb4a9650867104bf7f50c
In this commit I rewrite how the completion tracker tracks the
completions, and builds its lowest common denominator (LCD) string.
The LCD string is now built lazily when required, and we only track
the completions in one place, the hash table, rather than maintaining
a separate vector of completions.
The motivation for these changes is that the next commit will add the
ability to remove completions from the list, removing a completion
will invalidate the LCD string, so we need to keep hold of enough
information to recompute the LCD string as needed.
Additionally, keeping the completions in a vector makes removing a
completion expensive, so better to only keep the completions in the
hash table.
This commit doesn't add any new functionality itself, and there should
be no user visible changes after this commit.
For testing, I ran the testsuite as usual, but I also ran some manual
completion tests under valgrind, and didn't get any reports about
leaked memory.
gdb/ChangeLog:
* completer.c (completion_tracker::completion_hash_entry): Define
new class.
(advance_to_filename_complete_word_point): Call
recompute_lowest_common_denominator.
(completion_tracker::completion_tracker): Call discard_completions
to setup the hash table.
(completion_tracker::discard_completions): Allow for being called
from the constructor, pass new equal function, and element deleter
when constructing the hash table. Initialise new class member
variables.
(completion_tracker::maybe_add_completion): Remove use of
m_entries_vec, and store more information into m_entries_hash.
(completion_tracker::recompute_lcd_visitor): New function, most
content taken from...
(completion_tracker::recompute_lowest_common_denominator):
...here, this now just visits each item in the hash calling the
above visitor.
(completion_tracker::build_completion_result): Remove use of
m_entries_vec, call recompute_lowest_common_denominator.
* completer.h (completion_tracker::have_completions): Remove use
of m_entries_vec.
(completion_tracker::completion_hash_entry): Declare new class.
(completion_tracker::recompute_lowest_common_denominator): Change
function signature.
(completion_tracker::recompute_lcd_visitor): Declare new function.
(completion_tracker::m_entries_vec): Delete.
(completion_tracker::m_entries_hash): Initialize to NULL.
(completion_tracker::m_lowest_common_denominator_valid): New
member variable.
(completion_tracker::m_lowest_common_denominator_max_length): New
member variable.
Change-Id: I9d1db52c489ca0041b8959ca0d53b7d3af8aea72
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
Define gdb_ptrace() a wrapper function for ptrace(2) that properly passes
the pid,lwp pair on NetBSD and the result of get_ptrace_pid() for others.
gdb/ChangeLog:
* i386-bsd-nat.c (gdb_ptrace): New.
* (i386bsd_fetch_inferior_registers,
i386bsd_store_inferior_registers) Switch from pid_t to ptid_t.
* (i386bsd_fetch_inferior_registers,
i386bsd_store_inferior_registers) Use gdb_ptrace.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
Define gdb_ptrace() a wrapper function for ptrace(2) that properly passes
the pid,lwp pair on NetBSD and the result of get_ptrace_pid() for others.
gdb/ChangeLog:
* amd64-bsd-nat.c (gdb_ptrace): New.
* (amd64bsd_fetch_inferior_registers,
amd64bsd_store_inferior_registers) Switch from pid_t to ptid_t.
* (amd64bsd_fetch_inferior_registers,
amd64bsd_store_inferior_registers) Use gdb_ptrace.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
Define gdb_ptrace() a wrapper function for ptrace(2) that properly passes
the pid,lwp pair on NetBSD and the result of get_ptrace_pid() for others.
gdb/ChangeLog:
* sparc-nat.c (gdb_ptrace): New.
* sparc-nat.c (sparc_fetch_inferior_registers)
(sparc_store_inferior_registers) Remove obsolete comment.
* sparc-nat.c (sparc_fetch_inferior_registers)
(sparc_store_inferior_registers) Switch from pid_t to ptid_t.
* sparc-nat.c (sparc_fetch_inferior_registers)
(sparc_store_inferior_registers) Use gdb_ptrace.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* sh-nbsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* sh-nbsd-nat.c (store_registers): Likewise.
gdb/ChangeLog:
* sh-nbsd-nat.c (sh_nbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* sh-nbsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
procfs on NetBSD is optional and not recommended.
* nbsd-nat.c: Include <sys/types.h>, <sys/ptrace.h> and
<sys/sysctl.h>.
* nbsd-nat.c (nbsd_nat_target::pid_to_exec_file): Rewrite.
The DWARF standard appendix E.1 describes techniques that can be used for
compression and deduplication: DIEs can be factored out into a new compilation
unit, and referenced using DW_FORM_ref_addr.
Such a new compilation unit can either use a DW_TAG_compile_unit or
DW_TAG_partial_unit. If a DW_TAG_compile_unit is used, its contents is
evaluated by consumers as though it were an ordinary compilation unit. If a
DW_TAG_partial_unit is used, it's only considered by consumers in the context
of a DW_TAG_imported_unit.
An example of when DW_TAG_partial_unit is required is when the factored out
DIEs are not top-level, f.i. because they were children of a namespace. In
such a case the corresponding DW_TAG_imported_unit will occur as child of the
namespace.
In the case of factoring out DIEs from c++ compilation units, we can factor
out into a new DW_TAG_compile_unit, and no DW_TAG_imported_unit is required.
This begs the question how to interpret a top-level DW_TAG_imported_unit of a
c++ DW_TAG_compile_unit compilation unit. The semantics of
DW_TAG_imported_unit describe that the imported unit logically appears at the
point of the DW_TAG_imported_unit entry. But it's not clear what the effect
should be in this case, since all the imported DIEs are already globally
visible anyway, due to the use of DW_TAG_compile_unit.
So, skip top-level imports of c++ DW_TAG_compile_unit compilation units in
process_imported_unit_die.
Using the cc1 binary from PR23710 comment 1 and setting a breakpoint on do_rpo_vn:
...
$ gdb \
-batch \
-iex "maint set dwarf max-cache-age 316" \
-iex "set language c++" \
-ex "b do_rpo_vn" \
cc1
...
we get a 8.1% reduction in execution time, due to reducing the number of
partial symtabs expanded into full symtabs from 212 to 175.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-03-17 Tom de Vries <tdevries@suse.de>
PR gdb/23710
* dwarf2/read.h (struct dwarf2_per_cu_data): Add unit_type and lang
fields.
* dwarf2/read.c (process_psymtab_comp_unit): Initialize unit_type and lang
fields.
(process_imported_unit_die): Skip import of c++ CUs.
The val_print removal series introduced a new possibly-uninitialized
warning in p-valprint.c. Examination of the code shows that the
warning does not indicate a real bug, so this patch silences the
warning by setting the variable in the catch clause of a try/catch.
(The obvious initialization did not work due to a "goto" in this
function.)
gdb/ChangeLog
2020-03-16 Tom Tromey <tom@tromey.com>
* p-valprint.c (pascal_object_print_value): Initialize
base_value.
This patch replaces usage of target descriptions in ARC, where the whole
description is fixed in XML, with new target descriptions where XML describes
individual features, and GDB assembles those features into actual target
description.
v2:
Removed arc.c from ALLDEPFILES in gdb/Makefile.in.
Removed vim modeline from arc-tdep.c to have it in a separate patch.
Removed braces from one line "if/else".
Undid the type change for "jb_pc" (kept it as "int").
Joined the unnecessary line breaks into one line.
No more moving around arm targets in gdb/features/Makefile.
Changed pattern checking for ARC features from "arc/{aux,core}" to "arc/".
v3:
Added include gaurds to arc.h.
Added arc_read_description to _create_ target descriptions less.
v4:
Got rid of ARC_SYS_TYPE_NONE.
Renamed ARC_SYS_TYPE_INVALID to ARC_SYS_TYPE_NUM.
Fixed a few indentations/curly braces.
Converted arc_sys_type_to_str from a macro to an inline function.
gdb/ChangeLog:
2020-03-16 Anton Kolesov <anton.kolesov@synopsys.com>
Shahab Vahedi <shahab@synopsys.com>
* Makefile.in: Add arch/arc.o
* configure.tgt: Likewise.
* arc-tdep.c (arc_tdesc_init): Use arc_read_description.
(_initialize_arc_tdep): Don't initialize old target descriptions.
(arc_read_description): New function to cache target descriptions.
* arc-tdep.h (arc_read_description): Add proto type.
* arch/arc.c: New file.
* arch/arc.h: Likewise.
* features/Makefile: Replace old target descriptions with new.
* features/arc-arcompact.c: Remove.
* features/arc-arcompact.xml: Likewise.
* features/arc-v2.c: Likewise
* features/arc-v2.xml: Likewise
* features/arc/aux-arcompact.xml: New file.
* features/arc/aux-v2.xml: Likewise.
* features/arc/core-arcompact.xml: Likewise.
* features/arc/core-v2.xml: Likewise.
* features/arc/aux-arcompact.c: Generate.
* features/arc/aux-v2.c: Likewise.
* features/arc/core-arcompact.c: Likewise.
* features/arc/core-v2.c: Likewise.
* target-descriptions (maint_print_c_tdesc_cmd): Support ARC features.
PR gdb/25663 points out that dwarf2_name will cache a value in the
bcache and then return a substring. However, this substring return is
only done on the branch that caches the value -- so if the function is
called twice with the same arguments, it will return different values.
This patch fixes this problem.
This area is strange. We cache the entire demangled string, but only
return the suffix. I looked at caching just the suffix, but it turns
out that anonymous_struct_prefix assumes that the entire string is
stored. Also weird is that this code is demangling the linkage name
and then storing the demangled form back into the linkage name
attribute -- that seems bad, because what if some code wants to find
the actual linkage name?
Fixing these issues was non-trivial, though; and in the meantime this
patch seems like an improvement. Regression tested on x86-64
Fedora 30.
gdb/ChangeLog
2020-03-16 Tom Tromey <tromey@adacore.com>
PR gdb/25663:
* dwarf2/read.c (dwarf2_name): Strip leading namespaces after
putting value into bcache.
On Windows x86-64 (when building with MinGW), the size of the "long"
type is 32 bits. amd64_windows_init_abi therefore does:
set_gdbarch_long_bit (gdbarch, 32);
This is also used when the chosen OS ABI is Cygwin, where the "long"
type is 64 bits. GDB therefore gets sizeof(long) wrong when using the
builtin long type:
$ ./gdb -nx --data-directory=data-directory -batch -ex "set architecture i386:x86-64" -ex "set osabi Cygwin" -ex "print sizeof(long)"
The target architecture is assumed to be i386:x86-64
$1 = 4
This patch makes GDB avoid setting the size of the long type to 32 bits
when using the Cygwin OS ABI. it will inherit the value set in
amd64_init_abi.
With this patch, I get:
$ ./gdb -nx --data-directory=data-directory -batch -ex "set architecture i386:x86-64" -ex "set osabi Cygwin" -ex "print sizeof(long)"
The target architecture is assumed to be i386:x86-64
$1 = 8
gdb/ChangeLog:
PR gdb/21500
* amd64-windows-tdep.c (amd64_windows_init_abi): Rename
to...
(amd64_windows_init_abi_common): ... this. Don't set size of
long type.
(amd64_windows_init_abi): New function.
(amd64_cygwin_init_abi): New function.
(_initialize_amd64_windows_tdep): Use amd64_cygwin_init_abi for
the Cygwin OS ABI.
* i386-windows-tdep.c (_initialize_i386_windows_tdep): Clarify
comment.
Before this patch, the "Windows" OS ABI is selected for all Windows
executables, including Cygwin ones. This patch makes GDB differentiate
Cygwin binaries from non-Cygwin ones, and selects the "Cygwin" OS ABI
for the Cygwin ones.
To check whether a Windows PE executable is a Cygwin one, we check the
library list in the .idata section, see if it contains "cygwin1.dll".
I had to add code to parse the .idata section, because BFD doesn't seem
to expose this information. BFD does parse this information, but only
to print it in textual form (function pe_print_idata):
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/peXXigen.c;h=e42d646552a0ca1e856e082256cd3d943b54ddf0;hb=HEAD#l1261
Here's the relevant portion of the PE format documentation:
https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-idata-section
This page was also useful:
https://blog.kowalczyk.info/articles/pefileformat.html#9ccef823-67e7-4372-9172-045d7b1fb006
With this patch applied, this is what I get:
(gdb) file some_mingw_x86_64_binary.exe
Reading symbols from some_mingw_x86_64_binary.exe...
(gdb) show osabi
The current OS ABI is "auto" (currently "Windows").
The default OS ABI is "GNU/Linux".
(gdb) file some_mingw_i386_binary.exe
Reading symbols from some_mingw_i386_binary.exe...
(gdb) show osabi
The current OS ABI is "auto" (currently "Windows").
The default OS ABI is "GNU/Linux".
(gdb) file some_cygwin_x86_64_binary.exe
Reading symbols from some_cygwin_x86_64_binary.exe...
(gdb) show osabi
The current OS ABI is "auto" (currently "Cygwin").
The default OS ABI is "GNU/Linux".
gdb/ChangeLog:
* windows-tdep.h (is_linked_with_cygwin_dll): New declaration.
* windows-tdep.c (CYGWIN_DLL_NAME): New.
(pe_import_directory_entry): New struct type.
(is_linked_with_cygwin_dll): New function.
* amd64-windows-tdep.c (amd64_windows_osabi_sniffer): Select
GDB_OSABI_CYGWIN if the BFD is linked with the Cygwin DLL.
* i386-windows-tdep.c (i386_windows_osabi_sniffer): Likewise.
i386-cygwin-tdep.c has just been renamed to i386-windows-tdep.c, this
patch now renames everything in it that is not Cygwin-specific to
replace "cygwin" with "windows".
Note that I did not rename i386_cygwin_core_osabi_sniffer, since that
appears to be Cygwin-specific.
gdb/ChangeLog:
* i386-windows-tdep.c: Mass-rename "cygwin" to "windows", except
i386_cygwin_core_osabi_sniffer.
Since this file contains things that apply not only to Cygwin binaries,
but also to non-Cygwin Windows binaries, I think it would make more
sense for it to be called i386-windows-tdep.c. It is analogous to
amd64-windows-tdep.c, which we already have.
gdb/ChangeLog:
* i386-cygwin-tdep.c: Rename to...
* i386-windows-tdep.c: ... this.
* Makefile.in (ALL_TARGET_OBS): Rename i386-cygwin-tdep.c to
i386-windows-tdep.c.
* configure.tgt: Likewise.
GDB currently uses the "Cygwin" OS ABI (GDB_OSABI_CYGWIN) for everything
related to Windows. If you build a GDB for a MinGW or Cygwin target, it
will have "Cygwin" as the default OS ABI in both cases (see
configure.tgt). If you load either a MinGW or Cygwin binary, the
"Cygwin" OS ABI will be selected in both cases.
This is misleading, because Cygwin binaries are a subset of the binaries
running on Windows. When building something with MinGW, the resulting
binary has nothing to do with Cygwin. Cygwin binaries are only special
in that they are Windows binaries that link to the cygwin1.dll library
(if my understanding is correct).
Looking at i386-cygwin-tdep.c, we can see that GDB does nothing
different when dealing with Cygwin binaries versus non-Cygwin Windows
binaries. However, there is at least one known bug which would require
us to make a distinction between the two OS ABIs, and that is the size
of the built-in "long" type on x86-64. On native Windows, this is 4,
whereas on Cygwin it's 8.
So, this patch adds a new OS ABI, "Windows", and makes GDB use it for
i386 and x86-64 PE executables, instead of the "Cygwin" OS ABI. A
subsequent patch will improve the OS ABI detection so that GDB
differentiates the non-Cygwin Windows binaries from the Cygwin Windows
binaries, and applies the "Cygwin" OS ABI for the latter.
The default OS ABI remains "Cygwin" for the GDBs built with a Cygwin
target.
I've decided to split the i386_cygwin_osabi_sniffer function in two,
I think it's cleaner to have a separate sniffer for Windows binaries and
Cygwin cores, each checking one specific thing.
gdb/ChangeLog:
* osabi.h (enum gdb_osabi): Add GDB_OSABI_WINDOWS.
* osabi.c (gdb_osabi_names): Add "Windows".
* i386-cygwin-tdep.c (i386_cygwin_osabi_sniffer): Return
GDB_OSABI_WINDOWS when the binary's target is "pei-i386".
(i386_cygwin_core_osabi_sniffer): New function, extracted from
i386_cygwin_osabi_sniffer.
(_initialize_i386_cygwin_tdep): Register OS ABI
GDB_OSABI_WINDOWS for i386.
* amd64-windows-tdep.c (amd64_windows_osabi_sniffer): Return
GDB_OSABI_WINDOWS when the binary's target is "pei-x86-64".
(_initialize_amd64_windows_tdep): Register OS ABI GDB_OSABI_WINDOWS
for x86-64.
* configure.tgt: Use GDB_OSABI_WINDOWS as the default OS ABI
when the target matches '*-*-mingw*'.
I think it makes sense to have it there instead of in the catch-all
defs.h.
gdb/ChangeLog:
* defs.h (enum gdb_osabi): Move to...
* osabi.h (enum gdb_osabi): ... here.
* gdbarch.sh: Include osabi.h in gdbarch.h.
* gdbarch.h: Re-generate.
If I generate two Windows PE executables, one 32 bits and one 64 bits:
$ x86_64-w64-mingw32-gcc test.c -g3 -O0 -o test_64
$ i686-w64-mingw32-gcc test.c -g3 -O0 -o test_32
$ file test_64
test_64: PE32+ executable (console) x86-64, for MS Windows
$ file test_32
test_32: PE32 executable (console) Intel 80386, for MS Windows
When I load the 32 bits binary in my GNU/Linux-hosted GDB, the osabi is
correctly recognized as "Cygwin":
$ ./gdb --data-directory=data-directory -nx test_32
(gdb) show osabi
The current OS ABI is "auto" (currently "Cygwin").
When I load the 64 bits binary in GDB, the osabi is incorrectly
recognized as "GNU/Linux":
$ ./gdb --data-directory=data-directory -nx test_64
(gdb) show osabi
The current OS ABI is "auto" (currently "GNU/Linux").
The 32 bits one gets recognized by the i386_cygwin_osabi_sniffer
function, by its target name:
if (strcmp (target_name, "pei-i386") == 0)
return GDB_OSABI_CYGWIN;
The target name for the 64 bits binaries is "pei-x86-64". It doesn't
get recognized by any osabi sniffer, so GDB falls back on its default
osabi, "GNU/Linux".
This patch adds an osabi sniffer function for the Windows 64 bits
executables in amd64-windows-tdep.c. With it, the osabi is recognized
as "Cygwin", just like with the 32 bits binary.
Note that it may seems strange to have a binary generated by MinGW
(which has nothing to do with Cygwin) be recognized as a Cygwin binary.
This is indeed not accurate, but at the moment GDB uses the Cygwin for
everything Windows. Subsequent patches will add a separate "Windows" OS
ABI for Windows binaries that are not Cygwin binaries.
gdb/ChangeLog:
* amd64-windows-tdep.c (amd64_windows_osabi_sniffer): New
function.
(_initialize_amd64_windows_tdep): Register osabi sniffer.
A user noticed that "watch -location" would fail with a "restrict"
pointer. The issue here is that if the DWARF mentions "restrict", gdb
will put this into the type name -- but then the C parser will not be
able to parse this type.
This patch adds support for "restrict" and "_Atomic" to the C parser.
C++ doesn't have "restrict", but does have some GCC extensions. The
type printer is changed to handle this difference as well, so that
watch expressions will work properly.
gdb/ChangeLog
2020-03-14 Tom Tromey <tom@tromey.com>
* c-typeprint.c (cp_type_print_method_args): Print "__restrict__"
for C++.
(c_type_print_modifier): Likewise. Add "language" parameter.
(c_type_print_varspec_prefix, c_type_print_base_struct_union)
(c_type_print_base_1): Update.
* type-stack.h (enum type_pieces) <tp_atomic, tp_restrict>: New
constants.
* type-stack.c (type_stack::insert): Handle tp_atomic and
tp_restrict.
(type_stack::follow_type_instance_flags): Likewise.
(type_stack::follow_types): Likewise. Merge type-following code.
* c-exp.y (RESTRICT, ATOMIC): New tokens.
(space_identifier, cv_with_space_id)
(const_or_volatile_or_space_identifier_noopt)
(const_or_volatile_or_space_identifier): Remove.
(single_qualifier, qualifier_seq_noopt, qualifier_seq): New
rules.
(ptr_operator, typebase): Update.
(enum token_flag) <FLAG_C>: New constant.
(ident_tokens): Add "restrict", "__restrict__", "__restrict", and
"_Atomic".
(lex_one_token): Handle FLAG_C.
gdb/testsuite/ChangeLog
2020-03-14 Tom Tromey <tom@tromey.com>
* gdb.base/cvexpr.exp: Add test for _Atomic and restrict.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* m68k-bsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* m68k-bsd-nat.c (store_registers): Likewise.
gdb/ChangeLog:
* m68k-bsd-nat.c (m68k_bsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* m68k-bsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* m68k-bsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* alpha-bsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* alpha-bsd-nat.c (store_registers): Likewise.
gdb/ChangeLog:
* alpha-bsd-nat.c (alpha_netbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* alpha-bsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* alpha-bsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
gdb/ChangeLog:
* arm-nbsd-nat.c (arm_netbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* arm-nbsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
NetBSD ptrace(2) PT_GETDBREGS/PT_SETDBREGS accepts thread id (LWP)
as the 4th argument for threads.
gdb/ChangeLog:
* x86-bsd-nat.c (x86bsd_dr_get): New variable lwp and pass
it to the ptrace call.
* x86-bsd-nat.c (x86bsd_dr_set): Likewise.
ptrace(2) PT_GETREGS/PT_SETREGS accepts thread id (LWP) as the 4th
argument for threads.
gdb/ChangeLog:
* vax-bsd-nat.c (vaxbsd_supply_gregset): New variable lwp and pass
it to the ptrace call.
* vax-bsd-nat.c (vaxbsd_collect_gregset): Likewise.
gdb/ChangeLog:
* vax-bsd-nat.c (vax_bsd_nat_target): Inherit from nbsd_nat_target
instead of inf_ptrace_target.
* vax-bsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* mips-nbsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* ppc-nbsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* vax-bsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
This changes the extension language pretty-printers to use the value
API.
Note that new functions were needed, for both Guile and Python.
Currently both languages always wrap values by removing the values
from the value chain. This makes sense to avoid strange behavior with
watchpoints, and to avoid excessive memory use. However, when
printing, it's important to leave the passed-in value untouched, in
case pretty-printing does nothing -- that way the caller can still
access it.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (do_val_print): Update.
* python/python-internal.h (gdbpy_apply_val_pretty_printer): Take
a struct value.
(value_to_value_object_no_release): Declare.
* python/py-value.c (value_to_value_object_no_release): New
function.
* python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Take a
struct value.
* guile/scm-value.c (vlscm_scm_from_value_no_release): New
function.
* guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer): Take
a struct value.
* guile/guile-internal.h (vlscm_scm_from_value_no_release):
Declare.
(gdbscm_apply_val_pretty_printer): Take a struct value.
* extension.h (apply_ext_lang_val_pretty_printer): Take a struct
value.
* extension.c (apply_ext_lang_val_pretty_printer): Take a struct
value.
* extension-priv.h (struct extension_language_ops)
<apply_val_pretty_printer>: Take a struct value.
* cp-valprint.c (cp_print_value): Create a struct value.
(cp_print_value): Update.
This converts print_field_values to use the value-based API, by having
it call common_val_print rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (print_field_values): Call common_val_print.
This adds ada_value_print_array, a value-based analogue of
ada_val_print_array. It also removes some unused parameters from a
couple of helper functions.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (val_print_packed_array_elements): Remove
bitoffset and val parameters. Call common_val_print.
(ada_val_print_string): Remove offset, address, and original_value
parameters.
(ada_val_print_array): Update.
(ada_value_print_array): New function.
(ada_value_print_1): Call it.
This converts ada_value_print to the value-based API by using
common_val_print rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_value_print): Use common_val_print.
This converts ada_val_print_ref to the value-based API by using
common_val_print rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_val_print_ref): Use common_val_print.
This adds ada_value_print_num, a value-based analogue of
ada_val_print_num.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_value_print_num): New function.
(ada_value_print_1): Use it.
This rewrites the TYPE_CODE_FLT case in ada_value_print_1 to be purely
value-based.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_value_print_1) <TYPE_CODE_FLT>: Rewrite.
This adds ada_value_print_ptr, a value-based analogue of
ada_val_print_ptr.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_value_print_ptr): New function.
(ada_value_print_1): Use it.
This rewrites ada_value_print_inner, introducing a new
ada_value_print_1, an analogue of ada_val_print_1. Because it was
simple to do, this also converts ada_val_print_gnat_array to be
valued-based and updates the uses.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_val_print_gnat_array): Take a struct value;
call common_val_print.
(ada_val_print_1): Update.
(ada_value_print_1): New function.
(ada_value_print_inner): Rewrite.
This adds cp_print_value, a value-based analogue of cp_print_val, and
changes cp_print_value_fields to use it.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* cp-valprint.c (cp_print_value_fields): Update.
(cp_print_value): New function.
This adds cp_print_value_fields and c_value_print_struct, value-based
analogues of the corresponding val-printing functions. Note that the
Modula-2 printing code also calls cp_print_val_fields, and so is
updated to call the function function.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* m2-valprint.c (m2_value_print_inner): Use
cp_print_value_fields.
* cp-valprint.c (cp_print_value_fields): New function.
* c-valprint.c (c_value_print_struct): New function.
(c_value_print_inner): Use c_value_print_struct.
* c-lang.h (cp_print_value_fields): Declare.
This adds c_value_print_array, a value-based analogue of
c_val_print_array.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print_array): New function.
(c_value_print_inner): Use it.
This adds c_value_print_memberptr, a value-based analogue of
c_val_print_memberptr.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print_memberptr): New function.
(c_value_print_inner): Use it.
This adds c_value_print_int, a value-based analogue of
c_val_print_int.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print_int): New function.
(c_value_print_inner): Use it.
This adds c_value_print_ptr, a value-based analogue of
c_val_print_ptr.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print_ptr): New function.
(c_value_print_inner): Use it.
This rewrites c_value_print_inner, copying in the body of
c_val_print_inner and adusting as needed. This will form the base of
future changes to fully convert this to using the value-based API
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print_inner): Rewrite.
This adds generic_value_print_complex, a value-based analogue of
generic_val_print_complex.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print_complex): New function.
(generic_value_print): Use it.
This changes generic_val_print_float not to call
val_print_scalar_formatted. This lets generic_value_print then use
value_print_scalar_formatted instead.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_val_print_float): Don't call
val_print_scalar_formatted.
(generic_val_print, generic_value_print): Update.
This adds generic_value_print_char, a value-based analogue of
generic_val_print_char.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print_char): New function
(generic_value_print): Use it.
This adds generic_value_print_int, a value-based analogue of
generic_val_print_int.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print_int): New function.
(generic_value_print): Use it.
This adds generic_value_print_bool, a value-based analogue of
generic_val_print_bool.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print_bool): New function.
(generic_value_print): Use it.
This removes the call to val_print_scalar_formatted from
generic_val_print_func, allowing generic_value_print to call the
value-based variant instead.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_val_print_func): Simplify.
(generic_val_print, generic_value_print): Update.
This remove generic_val_print_flags in favor of using the value-based
API where possible.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_val_print_flags): Remove.
(generic_val_print, generic_value_print): Update.
(val_print_type_code_flags): Add original_value parameter.
This removes a call to val_print_scalar_formatted from
generic_val_print_enum, preferring to do the work in the callers.
This lets generic_value_print use the value-based API.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_val_print): Update.
(generic_value_print): Update.
* valprint.c (generic_val_print_enum): Don't call
val_print_scalar_formatted.
This introduces generic_value_print_ptr, a value-based analogue of
generic_val_print_ptr, and changes generic_value_print to use it.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print): Call generic_value_print_ptr.
* valprint.c (generic_value_print_ptr): New function.
This rewrites generic_value_print, by copying in the body of
generic_val_print and making the needed adjustments.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print): Rewrite.
This finishes the conversion of Pascal to the value-based API, by
introducing two more value-based analogues of existing val-print
functions.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* p-valprint.c (pascal_object_print_value_fields)
(pascal_object_print_value): New functions.
This rewrites pascal_value_print_inner, copying in the body of
pascal_val_print_inner and adusting as needed. This will form the
base of future changes to fully convert this to using the value-based
API.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* p-valprint.c (pascal_value_print_inner): Rewrite.
This finishes the conversion of the Fortran printing code to the
value-based API. The body of f_val_print is copied into
f_value_print_innner, and then modified as needed to use the value
API.
Note that not all calls must be updated. For example, f77_print_array
remains "val-like", because it does not result in any calls to
val_print (f77_print_array_1 calls common_val_print, which is
nominally value-based).
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* f-valprint.c (f_value_print_innner): Rewrite.
This finishes the conversion of Modula-2 printing to the value-based
API. It does so by copying the body of m2_val_print into
m2_value_print_inner, and then introducing new functions as needed to
use the value API.
The "val_" API code continues to exist, because it's still possible
for it to be called via some paths. This code will all be removed at
the end of the series.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* m2-valprint.c (m2_print_unbounded_array): New overload.
(m2_print_unbounded_array): Update.
(m2_print_array_contents): Take a struct value.
(m2_value_print_inner): Rewrite.
As with Rust and Go, it was straightforward to convert D to the
value-based API directly.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* d-valprint.c (dynamic_array_type): Call d_value_print_inner.
(d_value_print_inner): New function.
* d-lang.h (d_value_print_inner): Declare.
* d-lang.c (d_language_defn): Use d_value_print_inner.
This introduces go_value_print_inner, a modified copy of go_val_print.
Unlike some of the other languages, Go was straightforward to convert
to the value-based API all at once, so this patch takes that approach.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* go-valprint.c (go_value_print_inner): New function.
* go-lang.h (go_value_print_inner): Declare.
* go-lang.c (go_language_defn): Use go_value_print_inner.
For Rust, it was simple to convert the printing code to the
value-based API all at once.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* rust-lang.c (val_print_struct, rust_print_enum): Use the value
API.
(rust_val_print): Rewrite.
(rust_value_print_inner): New function, from rust_val_print.
(rust_language_defn): Use rust_value_print_inner.
This introduces c_value_print_inner, which implements the
la_value_print_inner method for the C family of languages. In this
patch, it is just a simple wrapper of c_val_print. However,
subsequent patches will convert it to use the value API. The
transformation is done this way to make each patch easier to review.
Future patches will apply this same treatment to other languages as
well.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* opencl-lang.c (opencl_language_defn): Use c_value_print_inner.
* objc-lang.c (objc_language_defn): Use c_value_print_inner.
* c-valprint.c (c_value_print_inner): New function.
* c-lang.h (c_value_print_inner): Declare.
* c-lang.c (c_language_defn, cplus_language_defn)
(asm_language_defn, minimal_language_defn): Use
c_value_print_inner.
pascal_object_print_value_fields is only needed in p-valprint.c, so
make it static.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* p-valprint.c (pascal_object_print_value_fields): Now static.
* p-lang.h (pascal_object_print_value_fields): Don't declare.
This slightly simplifies c_val_print_array by moving a variable to a
more inner scope and removing a dead assignment.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_val_print_array): Simplify.
This introduces value_print_array_elements, which is an analogue of
val_print_array_elements that uses the value API.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (value_print_array_elements): New function.
* valprint.h (value_print_array_elements): Declare.
A couple of spots could be easily converted to use
value_print_scalar_formatted. This patch makes this change.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* printcmd.c (print_formatted): Use value_print_scalar_formatted.
* mips-tdep.c (mips_print_register): Use
value_print_scalar_formatted.
This introduces a value_print_scalar_formatted, which is an analogue
of val_print_scalar_formatted that uses the value API.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.h (value_print_scalar_formatted): Declare.
* valprint.c (value_print_scalar_formatted): New function.
This introduces generic_value_print, which is a value-based analogue
to generic_val_print. For now this is unused and simply calls
generic_val_print, but subsequent patches will both change this
function to work using the value API directly, and convert callers of
generic_val_print to call this instead.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.h (generic_value_print): Declare.
* valprint.c (generic_value_print): New function.
The plan for removing val_print is, essentially, to first duplicate
printing code as needed to use the value API; and then remove the
val_print code. This makes it possible to do the changes
incrementally while keeping everything working.
This adds a new la_value_print_inner function pointer to struct
language_defn. Eventually this will replace la_val_print. This patch
also changes printing to prefer this API, when available -- but no
language defines it yet.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (do_val_print): Call la_value_print_inner, if
available.
* rust-lang.c (rust_language_defn): Update.
* p-lang.c (pascal_language_defn): Update.
* opencl-lang.c (opencl_language_defn): Update.
* objc-lang.c (objc_language_defn): Update.
* m2-lang.c (m2_language_defn): Update.
* language.h (struct language_defn) <la_value_print_inner>: New
member.
* language.c (unknown_language_defn, auto_language_defn): Update.
* go-lang.c (go_language_defn): Update.
* f-lang.c (f_language_defn): Update.
* d-lang.c (d_language_defn): Update.
* c-lang.c (c_language_defn, cplus_language_defn)
(asm_language_defn, minimal_language_defn): Update.
* ada-lang.c (ada_language_defn): Update.
This changes c_value_print to call common_val_print. This is more
complicated than the usual sort of common_val_print change, due to the
handling of RTTI.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print): Use common_val_print.
gdb/testsuite/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* gdb.base/printcmds.exp (test_print_strings): Add regression
test.
* gdb.base/printcmds.c (charptr): New typedef.
(teststring2): New global.
This changes a spot in cp-valprint.c to use common_val_print rather
than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* cp-valprint.c (cp_print_static_field): Use common_val_print.
This changes a couple spots in f-valprint.c to use common_val_print
rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* f-valprint.c (f77_print_array_1, f_val_print): Use
common_val_print.
This changes some spots in riscv-tdep.c to use common_val_print rather
than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* riscv-tdep.c (riscv_print_one_register_info): Use
common_val_print.
This changes a spot in mi-main.c to use common_val_print rather than
val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* mi/mi-main.c (output_register): Use common_val_print.
This changes some spots in infcmd.c to use common_val_print (which,
despite its name, is a value-based API) rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* infcmd.c (default_print_one_register_info): Use
common_val_print.
A (much) later patch will remove the call to value_check_printable
from common_val_print. This will needed to preserve some details of
how optimized-out structures are printed.
However, doing this will also break dw2-op-out-param.exp. Making the
change causes "bt" to print:
However, the test wants to see:
... operand2=<optimized out>
That is, a wholly-optimized out structure should not print its fields.
So, this patch introduces a new common_val_print_checked, which calls
value_check_printable first, and then arranges to use it in the one
spot that affects the test suite.
I was not completely sure if it would be preferable to change the
test. However, I reasoned that, assuming this output was intentional
in the first place, in a backtrace space is at a premium and so this
is a reasonable approach. In other spots calling common_val_print,
this behavior is probably unintended, or at least a "don't care".
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.h (common_val_print_checked): Declare.
* valprint.c (common_val_print_checked): New function.
* stack.c (print_frame_arg): Use common_val_print_checked.
This changes val_print and common_val_print to use a new helper
function. A theme in the coming patches is that calls to val_print
itself should be removed. This is the first such patch; at the end of
the series, we'll remove val_print and simplify do_val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (do_val_print): New function, from val_print.
(val_print): Use do_val_print.
(common_val_print): Use do_val_print.
Switching the low-level printing to use the value API means we will be
using more temporary values. This adds a scoped_value_mark to
value_print, so that these intermediates are destroyed in a timely
way.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (value_print): Use scoped_value_mark.
Consider test-case gdb.dwarf2/imported-unit.exp.
It contains a CU with type int:
...
<0><129>: Abbrev Number: 2 (DW_TAG_compile_unit)
<12a> DW_AT_language : 4 (C++)
<12b> DW_AT_name : imported_unit.c
<1><13b>: Abbrev Number: 3 (DW_TAG_base_type)
<13c> DW_AT_byte_size : 4
<13d> DW_AT_encoding : 5 (signed)
<13e> DW_AT_name : int
...
which is imported in another CU:
...
<0><d2>: Abbrev Number: 2 (DW_TAG_compile_unit)
<d3> DW_AT_language : 4 (C++)
<d4> DW_AT_name : <artificial>
<1><e1>: Abbrev Number: 3 (DW_TAG_imported_unit)
<e2> DW_AT_import : <0x129> [Abbrev Number: 2]
...
However, if we print the partial symbols:
...
$ gdb -batch imported-unit -ex "maint print psymbols"
...
we see type int both in the importing CU:
...
Partial symtab for source file <artificial>@0xc7 (object 0x29f9b80)
...
Depends on 1 other partial symtabs.
0 0x2a24240 imported_unit.c
Global partial symbols:
`main', function, 0x4004b2
Static partial symbols:
`int', type, 0x0
...
and in the imported CU:
...
Partial symtab for source file imported_unit.c (object 0x2a24240)
...
Depends on 0 other partial symtabs.
Shared partial symtab with user 0x29f9b80
Static partial symbols:
`int', type, 0x0
...
This is an artefact resulting from the fact that all CUs in an objfile
share the same storage array for static partial symbols (and another array for
global partial symbols), using a range to describe their symbols.
Then when scanning the partial symbols of a CU and encountering an import, either:
- the referred CU has not been parsed yet, and will be parsed, and the range of
static partial symbols of the referred CU will be a subrange of the range of
static partial symbols of this CU, or
- the referred CU has already been parsed, and the range of static partial
symbols of the referred CU will not be a subrange of the range of static
partial symbols of this CU.
This is inconsistent handling, and confuses the notion of a symbol belonging to
a single symtab.
Furthermore, it might slow down searches, given that the symbol needs to be
skipped twice.
Finally, the same issue holds for global partial symbols, where the range of a
CU is sorted after parsing is finished. Obviously sorting the range of a CU
may invalidate subranges, effectively moving symbols in and out of imported
CUs.
Fix this for both static and global partial symbols, by gathering partial
symbols in a per-CU vector, and adding those symbols to the per-objfile
storage only once complete.
Tested on x86_64-linux, with native and board cc-with-dwz and cc-with-dwz-m.
gdb/ChangeLog:
2020-03-13 Tom de Vries <tdevries@suse.de>
PR symtab/25646
* psymtab.c (partial_symtab::partial_symtab): Don't set
globals_offset and statics_offset. Push element onto
current_global_psymbols and current_static_psymbols stacks.
(concat): New function.
(end_psymtab_common): Set globals_offset and statics_offset. Pop
element from current_global_psymbols and current_static_psymbols
stacks. Concat popped elements to global_psymbols and
static_symbols.
(add_psymbol_to_list): Use current_global_psymbols and
current_static_psymbols stacks.
* psymtab.h (class psymtab_storage): Add current_global_psymbols and
current_static_psymbols fields.
gdb/testsuite/ChangeLog:
2020-03-13 Tom de Vries <tdevries@suse.de>
PR symtab/25646
* gdb.dwarf2/imported-unit.exp: Add test.
There are no more callers to deprecated_add_core_fns, now that I have
removed the usage from CRIS and ARM/NetBSD. So this patch cleans up
all the related code and makes corelow.c a lot more readable.
gdb/ChangeLog:
2020-03-12 Christian Biesinger <cbiesinger@google.com>
* corelow.c (sniff_core_bfd): Remove.
(class core_target) <m_core_vec>: Remove.
(core_target::core_target): Update.
(core_file_fns): Remove.
(deprecated_add_core_fns): Remove.
(default_core_sniffer): Remove.
(sniff_core_bfd): Remove.
(default_check_format): Remove.
(gdb_check_format): Remove.
(core_target_open): Update.
(core_target::get_core_register_section): Update.
(get_core_registers_cb): Update.
(core_target::fetch_registers): Update.
* gdbcore.h (struct core_fns): Remove.
(deprecated_add_core_fns): Remove.
(default_core_sniffer): Remove.
(default_check_format): Remove.
Some arm-tdep.c data structures use a bfd_vma. A couple of spots will
warn about an implicit narrowing cast when building a gdb where
CORE_ADDR is 64-bit but bfd_vma is 32-bit.
This patch silences these warnings by changing the types in question
to CORE_ADDR.
gdb/ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* arm-tdep.c (struct arm_mapping_symbol) <value>: Now a
CORE_ADDR.
(struct arm_exidx_entry) <addr>: Now a CORE_ADDR.
A few spots in gdb use sprintf_vma to print a CORE_ADDR. This will
fail on a 32-bit build once CORE_ADDR is always a 64-bit type.
This patch replaces these calls with phex instead.
gdb/ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* remote.c (remote_target::download_tracepoint)
(remote_target::enable_tracepoint)
(remote_target::disable_tracepoint): Use phex, not sprintf_vma.
* breakpoint.c (print_recreate_masked_watchpoint): Use phex, not
sprintf_vma.
symfile-mem.c has some assertions about the size of various types, to
ensure that gdb and BFD don't get out of sync in a way that would
cause bugs.
Once CORE_ADDR is always 64-bit, one of these assertions can fail for
a 32-bit BFD build. However, the real requirement here is just that
CORE_ADDR is wider -- because this code promotes a bfd_vma to a
CORE_ADDR.
This patch corrects the assert.
gdb/ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* symfile-mem.c: Update CORE_ADDR size assert.
The selftest.m4 file is used by gdb, gdbserver and gdbsupport, I think
it belongs in gdbsupport.
gdb/ChangeLog:
* selftest.m4: Move to gdbsupport/.
* acinclude.m4: Update path to selftest.m4.
gdbserver/ChangeLog:
* acinclude.m4: Update path to selftest.m4.
gdbsupport/ChangeLog:
* selftest.m4: Moved from gdb/.
* acinclude.m4: Update path to selftest.m4.
While working on the preceding selftests patches, I noticed that some
selftests-specific files are included in the build even when selftests
are disabled, namely disasm-selftest.c and gdbarch-selftests.c. These
files are entirely #if'ed out when building with selftests disabled.
This is not a huge problem, but I think it would make more sense if
these files were simply not built.
With this patch, I propose to put all the selftests-specific source
files into a SELFTESTS_SRCS Makefile variable (even selftest-arch.c,
which is currently added by the configure script).
gdb/ChangeLog:
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Rename to...
(SELFTESTS_SRCS): ... this. Add disasm-selftests.c,
gdbarch-selfselftests.c and selftest-arch.c.
(SUBDIR_UNITTESTS_OBS): Rename to...
(SELFTESTS_OBS): ... this.
(COMMON_SFILES): Remove disasm-selftests.c and
gdbarch-selftests.c.
* configure.ac: Don't add selftest-arch.{c,o} to
CONFIG_{SRCS,OBS}.
* disasm-selftests.c, gdbarch-selftests.c: Remove GDB_SELF_TEST
preprocessor conditions.
The same is done for gdb, gdbserver and gdbsupport. I therefore think
it makes sense to move that to GDB_AC_COMMON.
It is required to move the call to GDB_AC_COMMON so it is before
GDB_AC_SELFTEST in gdbserver/configure.ac, otherwise the $development
variable isn't set when the code behind GDB_AC_SELFTEST executes.
gdb/ChangeLog:
* configure.ac: Don't source bfd/development.sh.
* selftest.m4: Modify comment.
* configure: Re-generate.
gdbserver/ChangeLog:
* configure.ac: Don't source bfd/development.sh, move
GDB_AC_COMMON higher.
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure.ac: Don't source bfd/development.sh.
* common.m4: Source bfd/development.sh.
* configure: Re-generate.
Before commit 3d1e5a43cb ("gdbsupport/configure.ac: source
development.sh"), the GDB build in non-development mode (turn
development to false in bfd/development.sh if you want to try) was
broken because the gdbsupport configure script didn't source
bfd/development.sh to set the development variable.
Since the GDB_AC_SELFTEST macro relies on the `development` variable, I
propose to modify it such that it errors out if $development does not
have an expected value of "true" or "false". This could prevent a
future similar problem from happening while refactoring the configure
scripts. It would have caught the problem fixed by the patch mentioned
earlier.
gdb/ChangeLog:
* selftest.m4 (GDB_AC_SELFTEST): Error out if $development is
not "true" or "false".
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure: Re-generate.
This is in preparation for deleting deprecated_add_core_fns and
related code.
As a side-effect, this makes it possible to read NetBSD/ARM
core files on non-NetBSD/ARM platforms, subject to PR corefiles/25638.
I have removed this comment:
- /* This is ok: we're running native... */
Since we are using the gdbarch from the regcache, we should be
guaranteed to be calling the right function here, so it shouldn't
matter whether we are running native.
Tested by reading a NetBSD/ARM core file on Linux/x86-64 and NetBSD/ARM;
the "info registers" output matches the one from the system GDB.
gdb/ChangeLog:
2020-03-12 Christian Biesinger <cbiesinger@google.com>
* Makefile.in (HFILES_NO_SRCDIR): Add new arm-nbsd-tdep.h file.
* arm-nbsd-nat.c (arm_supply_gregset): Moved to arm-nbsd-tdep and
renamed to arm_nbsd_supply_gregset.
(fetch_register): Update to call arm_nbsd_supply_gregset.
(fetch_regs): Remove in favor of fetch_register with a -1 regno.
(arm_netbsd_nat_target::fetch_registers): Update.
(fetch_elfcore_registers): Removed.
(_initialize_arm_netbsd_nat): Removed call to deprecated_add_core_fns.
* arm-nbsd-tdep.c (struct arm_nbsd_reg): New struct.
(arm_nbsd_supply_gregset): Moved from arm-nbsd-nat.c and updated to
not require NetBSD system headers.
(arm_nbsd_regset): New struct.
(arm_nbsd_iterate_over_regset_sections): New function.
(arm_netbsd_init_abi_common): Updated to call
set_gdbarch_iterate_over_regset_sections.
* arm-nbsd-tdep.h: New file.
A patch somewhat like this patch has been in Fedora GDB for well over
a decade. The Fedora patch was written by Jan Kratochvil. The Fedora
version prints a warning and attempts to continue. This version will
error out, fatally. An earlier version of this patch was more like
the Fedora version than this one. Simon Marchi recommended use of an
assertion to test for the infinite recursion; I decided to use an
explicit test (with an "if" statement) along with a call to
internal_error() if the condition is met. This way, I could include
a plea to file a bug report.
It was motivated by a customer reported bug (back in 2006!) which
showed infinite mutual recursion between find_pc_sect_line and
find_pc_line. Here is a portion of the backtrace from the bug report:
(gdb) bt
#0 0x00000000004450a4 in lookup_minimal_symbol_by_pc_section (
pc=251700325328, section=0x570f500) at gdb/minsyms.c:484
#1 0x00000000004bbfb2 in find_pc_sect_line (pc=251700325328,
section=0x570f500, notcurrent=0) at gdb/symtab.c:2057
#2 0x00000000004bc480 in find_pc_line (pc=251700325328, notcurrent=0)
at gdb/symtab.c:2232
#3 0x00000000004bc1ff in find_pc_sect_line (pc=251700325328,
section=0x570f500, notcurrent=0) at gdb/symtab.c:2081
... (lots and lots of the same two functions with the same parameters)
#1070 0x00000000004bc480 in find_pc_line (pc=251700325328, notcurrent=0)
at gdb/symtab.c:2232
#1071 0x00000000004bc1ff in find_pc_sect_line (pc=251700325328,
section=0x570f500, notcurrent=0) at gdb/symtab.c:2081
#1072 0x00000000004bc480 in find_pc_line (pc=251700325328, notcurrent=0)
at gdb/symtab.c:2232
#1073 0x00000000004bc1ff in find_pc_sect_line (pc=251700325328,
section=0x570f500, notcurrent=0) at gdb/symtab.c:2081
#1074 0x00000000004bc480 in find_pc_line (pc=251700325328, notcurrent=0)
at gdb/symtab.c:2232
#1075 0x00000000004bc1ff in find_pc_sect_line (pc=251696794399,
section=0x59b0df8, notcurrent=0) at gdb/symtab.c:2081
#1076 0x00000000004bc480 in find_pc_line (pc=251696794399, notcurrent=0)
at gdb/symtab.c:2232
#1077 0x000000000055550e in find_frame_sal (frame=0xb3f3e0, sal=0x7fff1d1a8200)
at gdb/frame.c:1392
#1078 0x00000000004d86fd in set_current_sal_from_frame (frame=0x1648, center=1)
at gdb/stack.c:379
#1079 0x00000000004cf137 in normal_stop () at gdb/infrun.c:3147
...
The test case was a large application. Attempts were made to make a
small(er) test case, but those attempts were not successful.
Therefore, I cannot provide a new test for this patch.
That said, we ought to guard against recursively calling
find_pc_sect_line (via find_pc_line) with the identical PC value that
it had been called with. Should this happen, infinite recursion (as
shown in the above backtrace) is the result. This patch prevents
that from happening.
If this should happens, there is a bug somewhere, perhaps in GDB, perhaps
in some other part of the toolchain or a library. We error out fatally
with a message briefly describing the condition along with a plea to file
a bug report.
I spent some time looking at the surrounding code and commentary which
handle the case of PC being in a stub/trampoline. It first appeared
in the public GDB repository in April, 1999. The ChangeLog entry for
this commit is from 1998-12-31. The relevant portion is:
(find_pc_sect_line): Return correct information if pc is in import
or export stub (trampoline).
What's remarkable about the overall ChangeLog entry is that it's over
2500+ lines long! I believe that this was part of the infamous "HP
merge" (in which insufficient due diligence was given in accepting
a large batch of changes from an outside source). In the years that
followed, much of this code was either significantly revised or
outright removed.
For this particular case, I'm grateful that extensive comments were
provided by "RT". (I haven't been able to figure out who RT is/was.)
I've decided against attempting to revise this stub/trampoline handling
code any further than adding Jan's test which prevents an obvious case
of infinite recursion.
I've tested on Fedora 31, x86-64. I see no regressions. I've also
searched the logfile for the new message, but as expected, no message
was found (which is good).
gdb/ChangeLog:
* symtab.c (find_pc_sect_line): Add check which prevents infinite
recursion.
Change-Id: I595470be6ab5f61ca7e4e9e70c61a252c0deaeaa
While compiling with clang, I noticed it didn't catch cases where my
function declaration didn't match my function definition. This is
normally caught by gcc with -Wmissing-declarations.
On clang, this is caught by -Wmissing-prototypes instead.
Note that on gcc, -Wmissing-prototypes also exists, but is only valid
for C and Objective-C. It gets correctly rejected by the configure
script since gcc rejects it with:
cc1plus: error: command line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++ -Werror
So this warning flag ends up not used for gcc (which is what we want).
gdb/ChangeLog:
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure: Re-generate.
* warning.m4: Enable -Wmissing-prototypes.
A comment in ada-typeprint.c mentions the Unchecked_Variant pragma.
However, this does not exist, and the comment should actually mention
Unchecked_Union.
gdb/ChangeLog
2020-03-11 Tom Tromey <tromey@adacore.com>
* ada-typeprint.c (print_choices): Fix comment.
This commit:
commit 8c95582da8
Date: Mon Dec 30 21:04:51 2019 +0000
gdb: Add support for tracking the DWARF line table is-stmt field
Introduced an invalid memory access, by reading outside the bounds of
an array.
This would cause this valgrind error:
==7633== Invalid read of size 4
==7633== at 0x4D002C: buildsym_compunit::record_line(subfile*, int, unsigned long, bool) (buildsym.c:688)
==7633== by 0x5F60A5: dwarf_record_line_1(gdbarch*, subfile*, unsigned int, unsigned long, bool, dwarf2_cu*) (read.c:19956)
==7633== by 0x5F63B0: lnp_state_machine::record_line(bool) (read.c:20024)
==7633== by 0x5F5DD5: lnp_state_machine::handle_special_opcode(unsigned char) (read.c:19851)
==7633== by 0x5F6706: dwarf_decode_lines_1(line_header*, dwarf2_cu*, int, unsigned long) (read.c:20135)
==7633== by 0x5F6C57: dwarf_decode_lines(line_header*, char const*, dwarf2_cu*, dwarf2_psymtab*, unsigned long, int) (read.c:20328)
==7633== by 0x5DF5F1: handle_DW_AT_stmt_list(die_info*, dwarf2_cu*, char const*, unsigned long) (read.c:10748)
==7633== by 0x5DF823: read_file_scope(die_info*, dwarf2_cu*) (read.c:10796)
==7633== by 0x5DDA63: process_die(die_info*, dwarf2_cu*) (read.c:9815)
==7633== by 0x5DD44A: process_full_comp_unit(dwarf2_per_cu_data*, language) (read.c:9580)
==7633== by 0x5DAB58: process_queue(dwarf2_per_objfile*) (read.c:8867)
==7633== by 0x5CB30E: dw2_do_instantiate_symtab(dwarf2_per_cu_data*, bool) (read.c:2374)
==7633== Address 0xa467f48 is 8 bytes before a block of size 16,024 alloc'd
==7633== at 0x4C2CDCB: malloc (vg_replace_malloc.c:299)
==7633== by 0x451FC4: xmalloc (alloc.c:60)
==7633== by 0x4CFFDF: buildsym_compunit::record_line(subfile*, int, unsigned long, bool) (buildsym.c:678)
==7633== by 0x5F60A5: dwarf_record_line_1(gdbarch*, subfile*, unsigned int, unsigned long, bool, dwarf2_cu*) (read.c:19956)
==7633== by 0x5F63B0: lnp_state_machine::record_line(bool) (read.c:20024)
==7633== by 0x5F5DD5: lnp_state_machine::handle_special_opcode(unsigned char) (read.c:19851)
==7633== by 0x5F6706: dwarf_decode_lines_1(line_header*, dwarf2_cu*, int, unsigned long) (read.c:20135)
==7633== by 0x5F6C57: dwarf_decode_lines(line_header*, char const*, dwarf2_cu*, dwarf2_psymtab*, unsigned long, int) (read.c:20328)
==7633== by 0x5DF5F1: handle_DW_AT_stmt_list(die_info*, dwarf2_cu*, char const*, unsigned long) (read.c:10748)
==7633== by 0x5DF823: read_file_scope(die_info*, dwarf2_cu*) (read.c:10796)
==7633== by 0x5DDA63: process_die(die_info*, dwarf2_cu*) (read.c:9815)
==7633== by 0x5DD44A: process_full_comp_unit(dwarf2_per_cu_data*, language) (read.c:9580)
gdb/ChangeLog:
* buildsyms.c (buildsym_compunit::record_line): Avoid accessing
previous item in the list, when the list has no items.
When using the executable from test-case gdb.ada/access_to_packed_array.exp
(read-in using -readnow) and printing the symbols using "maint print symbols",
we run into a segv:
...
$ gdb -readnow -batch access_to_packed_array/foo -ex "maint print symbols"
...
info: array (<>) of character; computed at runtime
ptr: range 0 .. 2147483647; computed at runtime
Aborted (core dumped)
...
What happens is that dwarf2_evaluate_property gets called and sets the local
frame variable to the current frame, which happens to be NULL. Subsequently
the PROP_LOCLIST handling code is executed, where get_frame_address_in_block
gets called with argument NULL, and the segv is triggered.
Fix this by handling a NULL frame in the PROP_LOCLIST handling code in
dwarf2_evaluate_property.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-03-11 Tom de Vries <tdevries@suse.de>
* dwarf2/loc.c (dwarf2_evaluate_property): Handle NULL frame in
PROP_LOCLIST handling code.
gdb/testsuite/ChangeLog:
2020-03-11 Tom de Vries <tdevries@suse.de>
* gdb.ada/access_to_packed_array.exp: Test printing of expanded
symtabs.
This commit brings support for the DWARF line table is_stmt field to
GDB. The is_stmt field is used by the compiler when a single source
line is split into multiple assembler instructions, especially if the
assembler instructions are interleaved with instruction from other
source lines.
The compiler will set the is_stmt flag false from some instructions
from the source lines, these instructions are not a good place to
insert a breakpoint in order to stop at the source line.
Instructions which are marked with the is_stmt flag true are a good
place to insert a breakpoint for that source line.
Currently GDB ignores all instructions for which is_stmt is false.
This is fine in a lot of cases, however, there are some cases where
this means the debug experience is not as good as it could be.
Consider stopping at a random instruction, currently this instruction
will be attributed to the last line table entry before this point for
which is_stmt was true - as these are the only line table entries that
GDB tracks. This can easily be incorrect in code with even a low
level of optimisation.
With is_stmt tracking in place, when stopping at a random instruction
we now attribute the instruction back to the real source line, even
when is_stmt is false for that instruction in the line table.
When inserting breakpoints we still select line table entries for
which is_stmt is true, so the breakpoint placing behaviour should not
change.
When stepping though code (at the line level, not the instruction
level) we will still stop at instruction where is_stmt is true, I
think this is more likely to be the desired behaviour.
Instruction stepping is, of course, unchanged, stepping one
instruction at a time, but we should now report more accurate line
table information with each instruction step.
The original motivation for this work was a patch posted by Bernd
here:
https://sourceware.org/ml/gdb-patches/2019-11/msg00792.html
As part of that thread it was suggested that many issues would be
resolved if GDB supported line table views, this isn't something I've
attempted in this patch, though reading the spec, it seems like this
would be a useful feature to support in GDB in the future. The spec
is here:
http://dwarfstd.org/ShowIssue.php?issue=170427.1
And Bernd gives a brief description of the benefits here:
https://sourceware.org/ml/gdb-patches/2020-01/msg00147.html
With that all said, I think that there is benefit to having proper
is_stmt support regardless of whether we have views support, so I
think we should consider getting this in first, and then building view
support on top of this.
The gdb.cp/step-and-next-inline.exp test is based off a test proposed
by Bernd Edlinger in this message:
https://sourceware.org/ml/gdb-patches/2019-12/msg00842.html
gdb/ChangeLog:
* buildsym-legacy.c (record_line): Pass extra parameter to
record_line.
* buildsym.c (buildsym_compunit::record_line): Take an extra
parameter, reduce duplication in the line table, and record the
is_stmt flag in the line table.
* buildsym.h (buildsym_compunit::record_line): Add extra
parameter.
* disasm.c (do_mixed_source_and_assembly_deprecated): Ignore
non-statement lines.
* dwarf2/read.c (dwarf_record_line_1): Add extra parameter, pass
this to the symtab builder.
(dwarf_finish_line): Pass extra parameter to dwarf_record_line_1.
(lnp_state_machine::record_line): Pass a suitable is_stmt flag
through to dwarf_record_line_1.
* infrun.c (process_event_stop_test): When stepping, don't stop at
a non-statement instruction, and only refresh the step info when
we land in the middle of a line's range. Also add an extra
comment.
* jit.c (jit_symtab_line_mapping_add_impl): Initialise is_stmt
field.
* record-btrace.c (btrace_find_line_range): Only record lines
marked as is-statement.
* stack.c (frame_show_address): Show the frame address if we are
in a non-statement sal.
* symmisc.c (dump_symtab_1): Print the is_stmt flag.
(maintenance_print_one_line_table): Print a header for the is_stmt
column, and include is_stmt information in the output.
* symtab.c (find_pc_sect_line): Find lines marked as statements in
preference to non-statements.
(find_pcs_for_symtab_line): Prefer is-statement entries.
(find_line_common): Likewise.
* symtab.h (struct linetable_entry): Add is_stmt field.
(struct symtab_and_line): Likewise.
* xcoffread.c (arrange_linetable): Initialise is_stmt field when
arranging the line table.
gdb/testsuite/ChangeLog:
* gdb.cp/step-and-next-inline.cc: New file.
* gdb.cp/step-and-next-inline.exp: New file.
* gdb.cp/step-and-next-inline.h: New file.
* gdb.dwarf2/dw2-is-stmt.c: New file.
* gdb.dwarf2/dw2-is-stmt.exp: New file.
* gdb.dwarf2/dw2-is-stmt-2.c: New file.
* gdb.dwarf2/dw2-is-stmt-2.exp: New file.
* gdb.dwarf2/dw2-ranges-base.exp: Update line table pattern.
Gcc supports an option -feliminate-dwarf2-dups (up until gcc-7, removed in
gcc-8).
When running tests with target board unix/-feliminate-dwarf2-dups, we run
into:
...
(gdb) PASS: gdb.ada/arraydim.exp: print m'length(3)
ptype global_3dim_for_gdb_testing^M
type = array (Unexpected type in ada_discrete_type_low_bound.^M
(gdb) FAIL: gdb.ada/arraydim.exp: ptype global_3dim_for_gdb_testing
...
The DWARF for the variable global_3dim_for_gdb_testing looks as follows:
...
<0><824>: Abbrev Number: 1 (DW_TAG_compile_unit)
<825> DW_AT_name : src/gdb/testsuite/gdb.ada/arraydim/inc.c
<1><832>: Abbrev Number: 2 (DW_TAG_array_type)
<833> DW_AT_type : <0x874>
<2><837>: Abbrev Number: 3 (DW_TAG_subrange_type)
<838> DW_AT_type : <0x84a>
<83c> DW_AT_upper_bound : 0
<2><83d>: Abbrev Number: 3 (DW_TAG_subrange_type)
<83e> DW_AT_type : <0x84a>
<842> DW_AT_upper_bound : 1
<2><843>: Abbrev Number: 3 (DW_TAG_subrange_type)
<844> DW_AT_type : <0x84a>
<848> DW_AT_upper_bound : 2
<2><849>: Abbrev Number: 0
<1><84a>: Abbrev Number: 4 (DW_TAG_typedef)
<84b> DW_AT_type : <0x86d>
<1><84f>: Abbrev Number: 0
<0><85b>: Abbrev Number: 5 (DW_TAG_compile_unit)
<861> DW_AT_name : src/gdb/testsuite/gdb.ada/arraydim/inc.c
<1><86d>: Abbrev Number: 6 (DW_TAG_base_type)
<86e> DW_AT_byte_size : 8
<86f> DW_AT_encoding : 7 (unsigned)
<870> DW_AT_name : long unsigned int
<1><874>: Abbrev Number: 7 (DW_TAG_base_type)
<875> DW_AT_byte_size : 4
<876> DW_AT_encoding : 5 (signed)
<877> DW_AT_name : int
<1><87b>: Abbrev Number: 8 (DW_TAG_variable)
<87c> DW_AT_name : global_3dim_for_gdb_testing
<882> DW_AT_type : <0x832>
<886> DW_AT_external : 1
...
The DWARF contains an anonymous typedef at 0x84a, referring to 0x86d.
Strictly speaking, the anonymous typedef is illegal DWARF, because a
DW_TAG_typedef is defined to have an DW_AT_name attribute containing the name
of the typedef as it appears in the source program.
The DWARF reading code creates a corresponding type for this typedef, which
goes on to confuse the code handling arrays.
Rather than trying to support the type representing this anonymous typedef in
all the locations where it causes problems, fix this by treating the anonymous
typedef as a forwarder DIE in the DWARF reader.
Tested on x86_64-linux, with target boards unix and
unix/-feliminate-dwarf2-dups.
This fixes ~85 failures for unix/-feliminate-dwarf2-dups.
gdb/ChangeLog:
2020-03-07 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (read_typedef): Treat anonymous typedef as forwarder
DIE.
While working on complex number support, I found a couple of
apparently obsolete coments. This removes them.
2020-03-07 Tom Tromey <tom@tromey.com>
* valops.c (value_literal_complex): Remove obsolete comment.
* gdbtypes.h (enum type_code) <TYPE_CODE_FLT>: Remove obsolete
comment.
[ Migrating this from Gerrit: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/321 ]
I noticed that some functions in infcmd and infrun call each other and
all call inferior_thread, while they could just get the thread_info
pointer from their caller. That means less calls to inferior_thread, so
less reliance on global state, since inferior_thread reads
inferior_ptid.
The paths I am unsure about are:
- fetch_inferior_event calls...
- step_command_fsm::should_stop calls...
- prepare_one_step
and
- process_event_stop_test calls...
- set_step_info
Before this patch, prepare_one_step gets the thread pointer using
inferior_thread. After this patch, it gets it from the
execution_control_state structure in fetch_inferior_event. Are we sure
that the thread from the execution_control_state structure is the same
as the one inferior_thread would return? This code path is used when a
thread completes a step, but the user had specified a step count (e.g.
"step 5") so we decide to do one more step. It would be strange (and
even a bug I suppose) if the thread in the ecs structure in
fetch_inferior_event was not the same thread that is prepared to stepped
by prepare_one_step. So I believe passing the ecs thread is fine.
The same logic applies to process_event_stop_test calling
set_step_info.
gdb/ChangeLog:
* infrun.h: Forward-declare thread_info.
(set_step_info): Add thread_info parameter, add doc.
* infrun.c (set_step_info): Add thread_info parameter, move doc
to header.
* infrun.c (process_event_stop_test): Pass thread to
set_step_info call.
* infcmd.c (set_step_frame): Add thread_info pointer, pass it to
set_step_info.
(prepare_one_step): Add thread_info parameter, pass it to
set_step_frame and prepare_one_step (recursive) call.
(step_1): Pass thread to prepare_one_step call.
(step_command_fsm::should_stop): Pass thread to
prepare_one_step.
(until_next_fsm): Pass thread to set_step_frame call.
(finish_command): Pass thread to set_step_info call.
The target_get_tib_address call always fails in this case, and there is an
error when changing the program with the file command:
(gdb) file allocer64.exe
Reading symbols from allocer64.exe...
You can't do that when your target is `exec'
Now it will skip this part, there is no need to rebase the executable without
an inferior anyways.
gdb/ChangeLog:
2020-03-06 Hannes Domani <ssbssa@yahoo.de>
* windows-tdep.c (windows_solib_create_inferior_hook):
Check if inferior is running.
Replace "the the" by "the".
gdb/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* NEWS: Fix "the the".
* ctfread.c: Same.
gdb/doc/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* gdb.texinfo: Fix "the the".
gdb/testsuite/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* README: Fix "the the".
* gdb.base/dprintf.exp: Same.
Using verbose, we get some detail on symbol loading:
...
$ gdb a.out -iex "set verbose on"
Reading symbols from a.out...
Reading in symbols for /home/vries/hello.c...done.
(gdb)
...
And using debug symtab-create, much more detail:
...
$ gdb a.out -iex "set verbose on" -iex "set debug symtab-create 1"
Reading symbols from a.out...
Reading minimal symbols of objfile /data/gdb_versions/devel/lto/a.out ...
Installing 30 minimal symbols of objfile /data/gdb_versions/devel/lto/a.out.
Done reading minimal symbols.
Creating one or more psymtabs for objfile /data/gdb_versions/devel/lto/a.out ...
Created psymtab 0x35a3de0 for module ../sysdeps/x86_64/start.S.
Created psymtab 0x353e4e0 for module init.c.
Created psymtab 0x353e560 for module ../sysdeps/x86_64/crti.S.
Created psymtab 0x353e5e0 for module /home/vries/hello.c.
Created psymtab 0x35bd530 for module elf-init.c.
Created psymtab 0x35bd5b0 for module ../sysdeps/x86_64/crtn.S.
Reading in symbols for /home/vries/hello.c...Created compunit symtab 0x354bd20 for hello.c.
done.
(gdb)
...
The "Created compunit symtab" message gets inbetween the "Reading in symbols"
and the trailing "done.". [ Strictly speaking this is a regression since
commit faa17681cc "Make gdb_flush also flush the wrap buffer", but the
same problem happens when using -batch before this commit. ]
Fix this by removing the trailing "done." altogether, such that we get:
...
Created psymtab 0x3590520 for module ../sysdeps/x86_64/crtn.S.
Reading in symbols for /home/vries/hello.c...
Created compunit symtab 0x359dd20 for hello.c.
(gdb)
...
[ Alternatively, we could fix this emitting a "Done reading in symbols" line
or some such, like is done for minimal symbols. See above. ]
[ Note: Removing the trailing "done." for the "Reading symbols from" message
was done in commit 3453e7e409 'Clean up "Reading symbols" output'. ]
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* psymtab.c (psymtab_to_symtab): Don't print "done.".
Copy the .dir-locls.el file from gdb/ to gdbserver/ and gdbsupport/ so
that we get the GNU/GDB style when editing these files in Emacs.
I initially wanted to remove the (c-mode . ((mode . c++))) that
switches c-mode files into c++-mode as we store C++ code in *.cc files
in the gdbserver/ directory, unlike gdb/ where we use *.c, however, I
was forgetting about the header files - we still use *.h for our C++
header files, so for now I left the settings in place to open all C
files in c++-mode.
We now have three copies of this file, which are all identical. It
would be nice if we could remove this duplication, however, for now we
haven't found a good way to do this.
Some options considered were:
1. Use symlinks to only have one copy of the file. This was
rejected as not all targets support symlinks in the way.
2. Have two of the .dir-locals.el files contain some mechanism by
which the third copy of the file is sourced. Though this would, in
theory, be possible, it would involve some advanced Emacs scripting,
would be fragile, and a maintenance burdon.
3. Move the .dir-locals up into top level src/ directory, then use
Emacs dir-locals directory pattern matching to only apply the rules
for the three directories we care about. The problem is that each
directory has to be listed separately, so we still end up having to
duplicate all the rules.
In the end, it was decided that having three copies of the file,
though not ideal, is probably easiest for now. This was all discussed
in this mailing list thread:
https://sourceware.org/ml/gdb-patches/2020-03/msg00024.html
The copyright date in the new files is left as for gdb/.dir-locals.el,
as the new files are a copy of the old, this is inline with this rule:
https://sourceware.org/gdb/wiki/ContributionChecklist#Copyright_Header
gdb/ChangeLog:
* .dir-locals.el: Add a comment referencing the other copies of
this file.
gdbserver/ChangeLog:
* .dir-locals.el: New file.
gdbsupport/ChangeLog:
* .dir-locals.el: New file.
Create .gitattributes files in gdb/, gdbserver/, and gdbsupport/.
The files specify cpp-style diffs for .h and .c files. This is
particularly helpful if a class in a header file is modified.
For instance, if the `stop_requested` field of `thread_info` in
gdb/gdbthread.h is modified, we get the following diff with
'git diff' (using git version 2.17.1):
@@ -379,7 +379,7 @@ public:
struct target_waitstatus pending_follow;
/* True if this thread has been explicitly requested to stop. */
- int stop_requested = 0;
+ bool stop_requested = 0;
/* The initiating frame of a nexting operation, used for deciding
which exceptions to intercept. If it is null_frame_id no
Note that the context of the change shows up as 'public:'; not so
useful. With the .gitattributes file, we get:
@@ -379,7 +379,7 @@ class thread_info : public refcounted_object
struct target_waitstatus pending_follow;
/* True if this thread has been explicitly requested to stop. */
- int stop_requested = 0;
+ bool stop_requested = 0;
/* The initiating frame of a nexting operation, used for deciding
which exceptions to intercept. If it is null_frame_id no
The context is successfully shown as 'class thread_info'.
This patch creates a .gitattributes file per each of gdb, gdbserver,
and gdbsupport folders. An alternative would be to define the
attributes in the root folder -- this would impact all the top-level
folders, though. I opted for the more conservative approach.
gdb/ChangeLog:
2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* .gitattributes: New file.
gdbserver/ChangeLog:
2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* .gitattributes: New file.
gdbsupport/ChangeLog:
2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* .gitattributes: New file.
This introduces a string cache on the per-BFD object, replacing the
macro and filename caches. Both of these caches just store strings,
so this consolidation by itself saves a little memory (about the size
of a bcache per objfile).
Then this patch switches some allocations on the objfile obstack to
use this bcache instead. This saves more space; and turns out to be a
bit faster as well.
Here are the before and after "maint time" + "maint space" results of
"file ./gdb":
Command execution time: 4.664021 (cpu), 4.728518 (wall)
Space used: 39190528 (+29212672 for this command)
Command execution time: 4.216209 (cpu), 4.107023 (wall)
Space used: 36667392 (+26689536 for this command)
The main interface to the string cache is a new pair of overloaded
methods, objfile::intern.
gdb/ChangeLog
2020-03-04 Tom Tromey <tom@tromey.com>
* symmisc.c (print_symbol_bcache_statistics)
(print_objfile_statistics): Update.
* symfile.c (allocate_symtab): Use intern.
* psymtab.c (partial_symtab::partial_symtab): Use intern.
* objfiles.h (struct objfile_per_bfd_storage) <filename_cache,
macro_cache>: Remove.
<string_cache>: New member.
(struct objfile) <intern>: New methods.
* elfread.c (elf_symtab_read): Use intern.
* dwarf2/read.c (fixup_go_packaging): Intern package name.
(dwarf2_compute_name, dwarf2_physname)
(create_dwo_unit_in_dwp_v1, create_dwo_unit_in_dwp_v2): Intern
names.
(guess_partial_die_structure_name): Update.
(partial_die_info::fixup): Intern name.
(dwarf2_canonicalize_name): Change parameter to objfile. Intern
name.
(dwarf2_name): Intern name. Update.
* buildsym.c (buildsym_compunit::get_macro_table): Use
string_cache.
I noticed that gnutarget was not "const". Since writing through this
pointer would probably be a bug, I think it ought to be. This patch
makes the change.
gdb/ChangeLog
2020-03-04 Tom Tromey <tom@tromey.com>
* jit.c (bfd_open_from_target_memory): Make "target" const.
* corefile.c (gnutarget): Now const.
* gdbcore.h (gnutarget): Now const.
Revert the change since it breaks existing behavior of "info registers"
for some architectures. At least AArch64 and ARM are impacted by this change.
gdb/ChangeLog:
2020-03-04 Luis Machado <luis.machado@linaro.org>
Revert aa66aac47b due to regressions
in "info registers" for AArch64/ARM.
The change caused "info registers" to not print GPR's.
gdb/ChangeLog:
2020-02-01 Shahab Vahedi <shahab@synopsys.com>
* target-descriptions.c (tdesc_register_in_reggroup_p): Return 0
when reg->group is empty and reggroup is not.
A customer reported a failure to unwind in a certain core dump. A
lengthy investigation showed that the problem came from the
interaction between the tailcall and inline frame sniffers.
Normally, the regular DWARF unwinder may discover a chain of tail
calls ending in the current frame. In this case, it sets a member on
the dwarf2_frame_cache object, so that a subsequent call into the
tailcall sniffer will create the tailcall frames.
However, in this scenario, what happened is that the DWARF unwinder
did find tailcall frames -- but then the PC of the first such frame
was recognized and claimed by the inline frame sniffer.
This then caused unwinding to go astray further up the stack.
This patch fixes the problem by arranging for the tailcall sniffer to
be called before the inline sniffer. This way, if a DWARF frame has
tailcall information, the tailcalls will always be processed first.
This is safe to do, because the tailcall sniffer can only claim a
frame if the previous frame did in fact find this information. (So,
for example, if no DWARF frame is ever found, then this sniffer will
never trigger.)
This patch also partially reverts:
commit 1ec56e88aa
Author: Pedro Alves <palves@redhat.com>
Date: Fri Nov 22 13:17:46 2013 +0000
Eliminate dwarf2_frame_cache recursion, don't unwind from the dwarf2 sniffer (move dwarf2_tailcall_sniffer_first elsewhere).
That patch moved the call to dwarf2_tailcall_sniffer_first out of
dwarf2_frame_cache, and into dwarf2_frame_prev_register. However, in
this situation, this is too late -- by the time
dwarf2_frame_prev_register is called, the frame in question is already
recognized by the inline frame sniffer.
Rather than fully revert that patch, though, this just arranges to
call dwarf2_tailcall_sniffer_first from dwarf2_frame_cache -- which is
called shortly after the DWARF frame sniffer succeeds, via
compute_frame_id.
I don't know how to write a test case for this.
gdb/ChangeLog
2020-03-03 Tom Tromey <tromey@adacore.com>
* dwarf2/frame.c (struct dwarf2_frame_cache)
<checked_tailcall_bottom, entry_cfa_sp_offset,
entry_cfa_sp_offset_p>: Remove members.
(dwarf2_frame_cache): Call dwarf2_tailcall_sniffer_first.
(dwarf2_frame_prev_register): Don't call
dwarf2_tailcall_sniffer_first.
(dwarf2_append_unwinders): Don't append tailcall unwinder.
* frame-unwind.c (add_unwinder): New fuction.
(frame_unwind_init): Use it. Add tailcall unwinder.
GDB is not able to print logical true values for Flang compiler.
Actual result:
(gdb) p l
$1 = 4294967295
Expected result:
(gdb) p l
$1 = .TRUE.
This is due to GDB expecting representation of true value being 1.
The Fortran standard doesnt specify how LOGICAL types are represented.
Different compilers use different non-zero values to represent logical
true. The gfortran compiler uses 1 to represent logical true and the
flang compiler uses -1. GDB should accept all the non-zero values as
true.
This is achieved by handling TYPE_CODE_BOOL in f_val_print and
printing any non-zero value as true.
gdb/ChangeLog:
* f-valprint.c (f_val_print): Handle TYPE_CODE_BOOL, any non-zero
value should be printed as true.
gdb/testsuite/ChangeLog:
* gdb.fortran/logical.exp: Add tests that any non-zero value is
printed as true.
Windows executables linked with -dynamicbase get a new base address
when loaded, which makes debugging impossible if the executable isn't
also rebased in gdb.
The new base address is read from the Process Environment Block.
gdb/ChangeLog:
2020-03-03 Hannes Domani <ssbssa@yahoo.de>
* windows-tdep.c (windows_solib_create_inferior_hook): New function.
(windows_init_abi): Set and use windows_so_ops.
Back at:
commit 1f6f6e21fa
Author: Philippe Waroquiers <philippe.waroquiers@skynet.be>
Date: Mon Jun 10 21:41:51 2019 +0200
Ensure GDB printf command can print convenience var strings without a target.
GDB was extended in order to allow the printing of convenience
variables that are strings without a target. However, this introduced
a regression that hasn't been caught by our testsuite (because there
were no tests for it).
The problem happens when we try to print a convenience variable that
holds the address of a string in the inferior. The following
two-liners can reproduce the issue:
$ echo -e 'int main(){const char a[]="test";return 0;}' | gcc -x c - -O0-g3
$ ./gdb/gdb --data-directory ./gdb/data-directory -q ./a.out -ex 'start' -ex 'set $x = (const char *) (&a[0] + 2)' -ex 'printf "%s\n", $x'
After some investigation, I found that the problem happens on
printcmd.c:printf_c_string. In the case above, we're taking the first
branch of the 'if' condition, which assumes that there will be a value
to be printed at "value_contents (value)". There isn't. We actually
need to obtain the address that the variable points to, and read the
contents from memory.
It seems to me that we should avoid this branch if the TYPE_CODE of
"value_type (value)" is TYPE_CODE_PTR (i.e., a pointer to the
inferior's memory). This is what this patch does.
I took the liberty to extend the current testcase under
gdb.base/printcmds.exp and create a test that exercises this scenario.
No regressions have been found on Buildbot.
gdb/ChangeLog:
2020-03-03 Sergio Durigan Junior <sergiodj@redhat.com>
* printcmd.c (print_c_string): Check also for TYPE_CODE_PTR
when verifying if dealing with a convenience variable.
gdb/testsuite/ChangeLog:
2020-03-03 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/printcmds.exp: Add test to verify printf of a
variable holding an address.
I noticed GDB didn't know a particular AT tag (51) when doing some debugging.
Turns out we're missing a few entries compared to glibc's headers.
This patch adds them to GDB and fixes a failure in gdb.base/auxv.exp as
a result.
gdb/ChangeLog:
2020-03-03 Luis Machado <luis.machado@linaro.org>
* auxv.c (default_print_auxv_entry): Add new AUXV entries.
This function returns the result of a quite big condition. I think it
would be more readeable if it was broken up in smaller pieces and
commented. This is what this patch does.
I also introduced gdbarch_supports_displaced_stepping, since it shows
the intent better than checking for gdbarch_displaced_step_copy_insn_p.
I also used that new function in displaced_step_prepare_throw.
I also updated the comment on top of can_use_displaced_stepping, which
seemed a bit outdated with respect to non-stop. The comment likely
dates from before it was possible to have targets that always operate
non-stop under the hood, even when the user-visible mode is all-stop.
No functional changes intended.
gdb/ChangeLog:
* infrun.c (gdbarch_supports_displaced_stepping): New.
(use_displaced_stepping): Break up conditions in smaller pieces.
Use gdbarch_supports_displaced_stepping.
(displaced_step_prepare_throw): Use
gdbarch_supports_displaced_stepping.
This commit aims to give a cleaner mechanism by which the user can
prevent GDB from trying to load any previous command history.
Currently the user can change the path to the history file, either
using a command line flag, or by setting the GDBHISTFILE environment
variable, and if the path is set to a non-existent file, then
obviously GDB wont load any command history. However, this feels like
a bit of a bodge, I'd like to add an official mechanism by which we
can disable command history loading.
Why would we want to prevent command history loading? The specific
use case I have is GDB starting with a CWD that is a network mounted
directory, and there is no command history present. Still GDB will
access the network in order to check for the file. In my particular
use case I'm actually starting a large number of GDB instances in
parallel, all in the same network mounted directory, the large number
of network accesses looking for this file introduces a noticeable
delay at GDB startup.
The approach I'm proposing here is a slight adjustment to the current
rules for setting up the history filename. Currently, if a user does
this, they see an error:
(gdb) set history filename
Argument required (filename to set it to.).
However, if a user does this:
$ GDBHISTFILE= gdb --quiet
(gdb) set history save on
(gdb) q
warning: Could not rename -gdb18416~ to : No such file or directory
So, we already have a bug in this area. My plan is to allow the empty
filename to be accepted, and for this to mean, neither load, nor save
the command history.
This does mean that we now have two mechanisms to prevent saving the
command history:
(gdb) set history filename
or
(gdb) set history save off
But the only way to prevent loading the command history is to set the
filename to the empty string _before_ you get to a GDB prompt, either
using a command line option, or the environment variable.
I've updated some of the show commands, for example this session:
(gdb) set history filename
(gdb) show history filename
There is no filename currently set for recording the command history in.
(gdb) show history save
Saving of the history record on exit is off.
(gdb) set history save on
(gdb) show history save
Saving of the history is disabled due to the value of 'history filename'.
(gdb) set history filename /tmp/hist
(gdb) show history save
Saving of the history record on exit is on.
I've updated the manual, and added some tests.
gdb/ChangeLog:
* NEWS: Mention new behaviour of the history filename.
* top.c (write_history_p): Add comment.
(show_write_history_p): Add header comment, give a different
message when history writing is on, but the history filename is
empty.
(history_filename): Add comment.
(history_filename_empty): New function.
(show_history_filename): Add header comment, give a different
message when the filename is empty.
(init_history): Compare history_filename against nullptr, and only
read history if the filename is not empty.
(set_history_filename): Add header comment, and only make
non-empty filenames absolute.
(init_main): Make the filename argument to 'set history filename'
optional.
gdb/doc/ChangeLog:
* gdb.texinfo (Command History): Extend description for
GDBHISTFILE and GDBHISTSIZE, add detail about the filename for
'set history filename' being optional. Describe the effect of an
empty history filename on 'set history save on'.
gdb/testsuite/ChangeLog:
* gdb.base/default.exp: Remove test of 'set history filename'.
* gdb.base/gdbinit-history.exp: Add tests for setting the history
filename to the empty string.
* lib/gdb.exp (gdb_init): Unset environment variables GDBHISTFILE
and GDBHISTSIZE.
Change-Id: Ia586e4311182fac99113b60f11ef8a11fbd5450b
The floating point register interface has changed to this:
https://github.com/NetBSD/src/blob/trunk/sys/arch/arm/include/reg.h
It now uses VFP instead of FPA registers. This patch updates
arm-nbsd-nat.c accordingly.
Also implements read_description so that these registers are correctly
printed by "info registers" et al.
Tested by compiling & running on arm-netbsd on qemu.
gdb/ChangeLog:
2020-03-02 Christian Biesinger <cbiesinger@google.com>
* arm-nbsd-nat.c (arm_supply_fparegset): Rename to...
(arm_supply_vfpregset): ...this, and update to use VFP registers.
(fetch_fp_register): Update.
(fetch_fp_regs): Update.
(store_fp_register): Update.
(store_fp_regs): Update.
(arm_netbsd_nat_target::read_description): New function.
(fetch_elfcore_registers): Update.
With this commit:
commit 5b6d1e4fa4
Date: Fri Jan 10 20:06:08 2020 +0000
Multi-target support
There was a regression in GDB's support for older aspects of the
remote protocol. Specifically, when a target sends the 'S' stop reply
packet (which doesn't include a thread-id) then GDB has to figure out
which thread actually stopped.
Before the above commit GDB figured this out by using inferior_ptid in
process_stop_reply, which contained the ptid of the current
process/thread. This would be fine for single threaded
targets (which is the only place using an S packet makes sense), but
in the general case, relying on inferior_ptid for processing a stop is
wrong - there's no reason to believe that what was GDB's current
thread will be the same thread that just stopped in the target.
With the above commit the inferior_ptid now has the value null_ptid
inside process_stop_reply, this can be seen in do_target_wait, where
we call switch_to_inferior_no_thread before calling do_target_wait_1.
The problem this causes can be seen in the new test that runs
gdbserver using the flag --disable-packet=T, and causes GDB to throw
this assertion:
inferior.c:279: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.
A similar problem was fixed in this commit:
commit 3cada74087
Date: Thu Jan 11 00:23:04 2018 +0000
Fix backwards compatibility with old GDBservers (PR remote/22597)
However, this commit deals with the case where the T packet doesn't
include a thread-id, not the S packet case. This commit solves the
problem providing a thread-id at the GDB side if the remote target
doesn't provide one. The thread-id provided comes from
remote_state::general_thread, however, though this does work, I don't
think it is the ideal solution.
The remote_state tracks two threads, the continue_thread and the
general_thread, these are updated when GDB asks the remote target to
switch threads. The general_thread is set before performing things
like register or memory accesses, and the continue_thread is set
before things like continue or step commands. Further, the
general_thread is updated after a target stops to reference the thread
that stopped.
The first thing to note from the above description is that we have a
cycle of dependency, when a T packet arrives without a thread-id we
fill in the thread-id from the general_thread data. The thread-id
from the stop event is then used to set the general_thread. This in
itself feels a little weird.
The second question is why use the general_thread at all? You'd think
given how they are originally set that the continue thread would be a
better choice. The problem with this is that the continue_thread, if
the user just does "continue", will be set to the minus_one_ptid, in
the remote protocol this means all threads. When the stop arrives
with no thread-id and we use continue_thread we end up with a very
similar assertion to before because we now end up trying to lookup a
thread using the minus_one_ptid. By contrast, once GDB has connected
to a remote target the general_thread will be set to a valid
thread-id, after which, if the target is single threaded, and stop
events arrive without a thread-id, everything works fine.
There is one slight weirdness with the above behaviour though. When
GDB first connects to the remote target inferior_ptid is null_ptid,
however, upon connecting we query the remote for its threads. As the
thread information arrives GDB adds the threads to its internal
database, and this process involves setting inferior_ptid to the id of
each new thread in turn. Once we know about all the threads we wait
for a stop event from the remote target to indicate that GDB is now in
control of the target.
The problem is that after adding the new threads we don't reset
inferior_ptid, and the code path we use to wait for a stop event from
the target also doesn't reset inferior_ptid, so it turns out that
during the initial connection inferior_ptid is not null_ptid. This is
lucky, because during the initial connection the general_thread
variable _is_ set to null_ptid.
So, during the initial connection, if the first stop event is missing
a thread-id then we "provide" a thead-id from general_thread. This
turns out to be null_ptid meaning no thread-id is known, and then
during process_stop_reply we fill in the missing thread-id using
inferior_ptid.
This was all discussed on the mailing list here:
https://sourceware.org/ml/gdb-patches/2020-02/msg01011.html
My proposal for a fix then is:
1. Move the call to switch_to_inferior_no_thread into
do_target_wait_1, this means that in all cases where we are waiting
for an inferior the inferior_ptid will be set to null_ptid. This is
good as no wait code should rely on inferior_ptid.
2. Remove the use of general_thread from the 'T' packet processing.
The general_thread read here was only ever correct by chance, and we
shouldn't be using it this way.
3. Remove use of inferior_ptid from process_stop_event as this is
wrong, and will always be null_ptid now anyway.
4. When a stop_event has null_ptid due to a lack of thread-id (either
from a T packet or an S packet) then pick the first non exited thread
in the target and use that. This will be fine for single threaded
targets. A multi-thread or multi-inferior aware remote target
should be using T packets with a thread-id, so we give a warning if
the target is multi-threaded, and we are still missing a thread-id.
5. Extend the existing test that covered the T packet with missing
thread-id to also cover the S packet.
gdb/ChangeLog:
* remote.c (remote_target::remote_parse_stop_reply): Don't use the
general_thread if the stop reply is missing a thread-id.
(remote_target::process_stop_reply): Use the first non-exited
thread if the target didn't pass a thread-id.
* infrun.c (do_target_wait): Move call to
switch_to_inferior_no_thread to ....
(do_target_wait_1): ... here.
gdb/testsuite/ChangeLog:
* gdb.server/stop-reply-no-thread.exp: Add test where T packet is
disabled.
* defs.h includes config.h
* config.h may define _GNU_SOURCE
* if _GNU_SOURCE is defined, that must be before including any system
header (see feature_test_macro(7))
This is necessary to ensure that a prototype for mkostemp() is brought
into scope by <stdlib.h> when compiling filestuff.h, on platforms where
_GNU_SOURCE isn't unconditionally defined for C++.
In file included from ../../gdb/../gdbsupport/scoped_fd.h:24,
from ../../gdb/debuginfod-support.c:22:
../../gdb/../gdbsupport/filestuff.h: In function ‘int gdb_mkostemp_cloexec(char*, int)’:
../../gdb/../gdbsupport/filestuff.h:59:10: error: ‘mkostemp’ was not declared in this scope; did you mean ‘mkstemp’?
gdb/ChangeLog:
2020-02-29 Jon Turney <jon.turney@dronecode.org.uk>
* debuginfod-support.c: Include defs.h first.
When language is set to auto, part of loading an executable is to update the
language accordingly. This is implemented by set_initial_language.
In case of a c++ executable without DW_AT_main_subprogram,
set_initial_language finds "main" in the minimal symbols, and does a lookup of
"main" in the symbol tables to determine the language of the symbol, and uses
that as initial language.
The symbol lookup is done using lookup_symbol which is a wrapper around
lookup_symbol_in_language, using the current language.
So, consider two c++ executables a.out and b.out, which we'll load one after
another. If we track the resulting lookup_symbol_in_language calls:
...
$ gdb -batch \
-ex "b lookup_symbol_in_language" \
-ex r -ex c -ex c \
--args gdb
...
we find that indeed lookup_symbol_in_language is called once using language_c, and
once using language_c_plus:
...
(gdb) file a.out
Reading symbols from a.out...
Breakpoint 1, lookup_symbol_in_language (name=0x5555568c2050 "main", \
block=0x0, domain=VAR_DOMAIN, lang=language_c, is_a_field_of_this=0x0) \
at ../../gdb/symtab.c:1905
1905 {
(gdb) file b.out
Load new symbol table from "b.out"? (y or n) y
Reading symbols from b.out...
Breakpoint 1, lookup_symbol_in_language (name=0x5555568c2030 "main", \
block=0x0, domain=VAR_DOMAIN, lang=language_cplus, is_a_field_of_this=0x0) \
at ../../gdb/symtab.c:1905
1905 {
(gdb)
...
It seems like a bad idea to have the previous language play a role
in determining the executable language.
Fix this by using lookup_symbol_in_language in set_initial_language with the
default language c as argument.
Tested on x86_64-linux.
gdb/ChangeLog:
2020-02-28 Tom de Vries <tdevries@suse.de>
* symfile.c (set_initial_language): Use default language for lookup.
Running anything with the fission.exp board fails since commit
c0ab21c22b ("Replace init_cutu_and_read_dies with a class").
GDB crashes while reading the DWARF info. cu is NULL in
read_signatured_type:
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x000055555780663e in read_signatured_type
sig_type=0x6210000c3600) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22782
22782 gdb_assert (cu->die_hash == NULL);
(top-gdb) bt
#0 0x000055555780663e in read_signatured_type (sig_type=0x6210000c3600) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22782
#1 0x00005555578062dd in load_full_type_unit (per_cu=0x6210000c3600) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22758
#2 0x00005555577c5fb7 in queue_and_load_dwo_tu (slot=0x60600007fc00, info=0x6210000c34e0) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:12674
#3 0x0000555559934232 in htab_traverse_noresize (htab=0x60b000063670, callback=0x5555577c5e61 <queue_and_load_dwo_tu(void**, void*)>, info=0x6210000c34e0)
at /home/simark/src/binutils-gdb/libiberty/hashtab.c:775
#4 0x00005555577c6252 in queue_and_load_all_dwo_tus (per_cu=0x6210000c34e0) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:12701
#5 0x000055555777ebd8 in dw2_do_instantiate_symtab (per_cu=0x6210000c34e0, skip_partial=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:2371
#6 0x000055555777eea2 in dw2_instantiate_symtab (per_cu=0x6210000c34e0, skip_partial=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:2395
#7 0x0000555557786ab6 in dw2_lookup_symbol (objfile=0x614000007240, block_index=GLOBAL_BLOCK, name=0x602000025310 "main", domain=VAR_DOMAIN)
at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:3539
After creating the reader object, the reader.cu field should not be
NULL. By checking the commit previous to the faulty one mentioned
above, I noticed that the cu field is normally set by
init_cu_die_reader, called from read_cutu_die_from_dwo, itself called
from cutu_reader::init_tu_and_read_dwo_dies, itself called from
cutu_reader's constructor.
However, cutu_reader::init_tu_and_read_dwo_dies calls
read_cutu_die_from_dwo, passing a pointer to a local `die_reader_specs`
variable. So it's the `cu` field of that object that gets set.
cutu_reader itself is a `die_reader_specs` (it inherits from it), and
the intention was most likely to pass `this` to read_cutu_die_from_dwo.
This way, the fields of the cutu_reader object, which
read_signatured_type will use, are set.
With this, I am able to use:
make check RUNTESTFLAGS='--target_board=fission'
and it looks much better. There are still some failures to be
investigated, but that's the usual state of the testsuite.
gdb/ChangeLog:
* dwarf2/read.c (cutu_reader::init_tu_and_read_dwo_dies): Remove
reader variable, pass `this` to read_cutu_die_from_dwo.
This fixes a regression caused by commit 0d79cdc494d5:
$ make check TESTS="gdb.dwarf2/dw2-ranges-base.exp"
[...]
ERROR: GDB process no longer exists
This error is caused by an abort during the computation of srcpath
when SYMTAB_DIRNAME (s) == NULL.
Computing srcpath only when SYMTAB_DIRNAME (s) is not NULL fixes this
error. Also change the condition for calling debuginfod_source_query
to include whether srcpath could be computed.
gdb/ChangeLog:
2020-02-27 Aaron Merey <amerey@redhat.com>
* source.c (open_source_file): Check for nullptr when computing
srcpath.
I noticed that there's no real reason to have field_info::nfields in
the DWARF reader. It simply mirrors information that is already
available. This patch removes it, in favor of a convenience method.
gdb/ChangeLog
2020-02-27 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (struct field_info) <nfields>: Now a method, not a
member.
(dwarf2_add_field): Don't update nfields.
(dwarf2_attach_fields_to_type, process_structure_scope): Update.
Use std::abs so that we get the C++ overloaded version that matches
the argument type instead of the C abs function which is only for int
arguments.
There should be no user visible change after this commit.
gdb/ChangeLog:
* gdbtypes.c (create_array_type_with_stride): Use std::abs not
abs.
Include files are represented by a partial symtab, but don't expand to
anything. From dwarf2_psymtab::expand_psymtab:
if (per_cu == NULL)
{
/* It's an include file, no symbols to read for it.
Everything is in the parent symtab. */
readin = true;
return;
}
This patch introduces a new specialization of partial_symtab to handle
this case. In addition to being slightly smaller, I believe an
include file is the only situation where a DWARF psymtab can result in
a null compunit_symtab. This adds an assert to that effect as well.
This change will simplify one of the psymtab sharing patches.
gdb/ChangeLog
2020-02-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (struct dwarf2_include_psymtab): New.
(dwarf2_create_include_psymtab): Use dwarf2_include_psymtab.
(dwarf2_psymtab::expand_psymtab, dwarf2_psymtab::readin_p)
(dwarf2_psymtab::get_compunit_symtab): Remove null checks for
per_cu_data.
dwarf2/index-write.c casts pointers to "dwarf2_psymtab *", but as far
as I can tell, it does not actually use any DWARF-specific fields of
the psymtab. So, this patch changes this code to use partial_symtab
instead. This removes nearly every cast, leaving just the unavoidable
one from addrmap iteration.
gdb/ChangeLog
2020-02-26 Tom Tromey <tom@tromey.com>
* dwarf2/index-write.c (psym_index_map): Change type.
(add_address_entry_worker, write_one_signatured_type)
(recursively_count_psymbols, recursively_write_psymbols)
(class debug_names, psyms_seen_size, write_gdbindex)
(write_debug_names): Use partial_symtab, not dwarf2_psymtab.
debuginfod is a lightweight web service that indexes ELF/DWARF debugging
resources by build-id and serves them over HTTP.
This patch enables GDB to query debuginfod servers for separate debug
files and source code when it is otherwise not able to find them.
GDB can be built with debuginfod using the --with-debuginfod configure
option.
This requires that libdebuginfod be installed and found at configure time.
debuginfod is packaged with elfutils, starting with version 0.178.
For more information see https://sourceware.org/elfutils/.
Tested on x86_64 Fedora 31.
gdb/ChangeLog:
2020-02-26 Aaron Merey <amerey@redhat.com>
* Makefile.in: Handle optional debuginfod support.
* NEWS: Update.
* README: Add --with-debuginfod summary.
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Handle optional debuginfod support.
* debuginfod-support.c: debuginfod helper functions.
* debuginfod-support.h: Ditto.
* doc/gdb.texinfo: Add --with-debuginfod to configure options
summary.
* dwarf2/read.c (dwarf2_get_dwz_file): Query debuginfod servers
when a dwz file cannot be found.
* elfread.c (elf_symfile_read): Query debuginfod servers when a
debuginfo file cannot be found.
* source.c (open_source_file): Query debuginfod servers when a
source file cannot be found.
* top.c (print_gdb_configuration): Include
--{with,without}-debuginfod in the output.
gdb/testsuite/ChangeLog:
2020-02-26 Aaron Merey <amerey@redhat.com>
* gdb.debuginfod: New directory for debuginfod tests.
* gdb.debuginfod/main.c: New test file.
* gdb.debuginfod/fetch_src_and_symbols.exp: New tests.
This makes the thread apply command print the thread's name. The use
of target_pid_to_str is replaced by thread_target_id_str, which
provides the same output as "info threads".
Before:
(gdb) thread apply 2 bt
Thread 2 (Thread 0x7fd245602700 (LWP 3837)):
[...]
After:
(gdb) thread apply 2 bt
Thread 2 (Thread 0x7fd245602700 (LWP 3837) "HT cleanup"):
[...]
The thread's description header is pre-computed before running the
command since the command may change the selected inferior. This is
not permitted by thread_target_id_str as target_thread_name asserts
that `info->inf == current_inferior ()`.
This situation arises in the `gdb.threads/threadapply.exp` test which
kills and removes the inferior as part of a "thread apply" command.
gdb/ChangeLog:
* thread.c (thr_try_catch_cmd): Print thread name.
All these functions have their implementations in dwarf2/read.c, so move
their declarations to dwarf2/read.h. Move the doc to the header, at the
same time.
gdb/ChangeLog:
* dwarf2/loc.h (dwarf2_fetch_die_loc_sect_off,
dwarf2_fetch_die_loc_cu_off, dwarf2_fetch_constant_bytes,
dwarf2_fetch_die_type_sect_off): Move to...
* dwarf2/read.h (dwarf2_fetch_die_loc_sect_off,
dwarf2_fetch_die_loc_cu_off, dwarf2_fetch_constant_bytes,
dwarf2_fetch_die_type_sect_off): ... here.
* dwarf2/read.c (dwarf2_fetch_die_loc_sect_off,
dwarf2_fetch_die_loc_cu_off, dwarf2_fetch_constant_bytes,
dwarf2_fetch_die_type_sect_off): Move doc to header file.
Initially, gdb sets the language to auto/c:
...
$ gdb -q
(gdb) show language
The current source language is "auto; currently c".
...
And after loading a c++ executable, that changes to auto/c++:
...
(gdb) file a.out
Reading symbols from a.out...
(gdb) show language
The current source language is "auto; currently c++".
...
Now consider setting the language manually to c:
...
$ gdb -q
(gdb) show language
The current source language is "auto; currently c".
(gdb) set language c
(gdb) show language
The current source language is "c".
...
The resulting language is manual/c.
Surprisingly, a subsequent load of the c++ executable:
...
(gdb) file a.out
Reading symbols from a.out...
(gdb) show language
The current source language is "c++".
...
gets us language manual/c++.
Loading the file should get us either:
- auto/c++, or
- manual/c.
That is, either the manual setting should be reset by loading, or the manual
setting should persist.
Fix this in the manual/c fashion. [ Though we could make some gdb setting to
choose one or the other. ]
Build and reg-tested on x86_64-linux.
[ Note: In PR23710 comment 1 a cc1 binary is attached for which gdb is slow when
loading and settting a breakpoint on do_rpo_vn:
...
$ time.sh gdb cc1 -batch -ex "b do_rpo_vn"
Breakpoint 1 at 0xd40e30: do_rpo_vn. (2 locations)
maxmem: 1463496
real: 8.88
user: 8.59
system: 0.35
...
This fix enables a speedup by manually setting the language before
loading, reducing executing time with ~17%, due to not having to load the full
symtab containing main:
...
$ time.sh gdb -iex "set language c++" cc1 -batch -ex "b do_rpo_vn"
Breakpoint 1 at 0xd40e30: do_rpo_vn. (2 locations)
maxmem: 1067308
real: 7.36
user: 7.14
system: 0.28
... ]
gdb/ChangeLog:
2020-02-26 Tom de Vries <tdevries@suse.de>
PR gdb/25603
* symfile.c (set_initial_language): Exit-early if
language_mode == language_mode_manual.
gdb/testsuite/ChangeLog:
2020-02-26 Tom de Vries <tdevries@suse.de>
PR gdb/25603
* gdb.base/persistent-lang.cc: New test.
* gdb.base/persistent-lang.exp: New file.
The implementation is in dwarf2/read.c, so the declaration belongs in
dwarf2/read.h. Also, move the documentation there.
gdb/ChangeLog:
* dwarf2/loc.h (dwarf2_read_addr_index): Move...
* dwarf2/read.h (dwarf2_read_addr_index): ... here.
* dwarf2/read.c (dwarf2_read_addr_index): Move doc to header.
This commit adds support for negative Fortran array strides in one
limited case, that is the case of a single element array with a
negative array stride.
The changes in this commit will be required in order for more general
negative array stride support to work correctly, however, right now
other problems in GDB prevent negative array strides from working in
the general case.
The reason negative array strides don't currently work in the general
case is that when dealing with such arrays, the base address for the
objects data is actually the highest addressed element, subsequent
elements are then accessed with a negative offset from that address,
and GDB is not currently happy with this configuration.
The changes here can be summarised as, stop treating signed values as
unsigned, specifically, the array stride, and offsets calculated using
the array stride.
This issue was identified on the mailing list by Sergio:
https://sourceware.org/ml/gdb-patches/2020-01/msg00360.html
The test for this issue is a new one written by me as the copyright
status of the original test is currently unknown.
gdb/ChangeLog:
* gdbtypes.c (create_array_type_with_stride): Handle negative
array strides.
* valarith.c (value_subscripted_rvalue): Likewise.
gdb/testsuite/ChangeLog:
* gdb.fortran/derived-type-striding.exp: Add a new test.
* gdb.fortran/derived-type-striding.f90: Add pointer variable for
new test.
Just a trivial typo fix in a comment.
gdb/ChangeLog
2020-02-25 Luis Machado <luis.machado@linaro.org>
* aarch64-tdep.c (aarch64_vnv_type): Fix comment typo.
Since its implementation is in dwarf2/read.c, its declaration belongs in
dwarf2/read.h. Move the documentation to the .h at the same time.
gdb/ChangeLog:
* loc.h (dwarf2_get_die_type): Move to...
* read.h (dwarf2_get_die_type): ... here.
* read.c (dwarf2_get_die_type): Move doc to header.
This will prevent this script from updating the copyright year range
for those files.
Note that aclocal.m4 and configure are already in the EXCLUDE_ALL_LIST,
so they don't need to be added to the EXCLUDE_LIST.
gdb/ChangeLog:
* copypright.py (EXCLUDE_LIST): Add 'gnulib/config.in' and
'gnulib/Makefile.in' to the list.
I noticed that setup_type_unit_groups leaks the symtab vector -- it
allocates this with XNEWVEC, but from what I can tell, nothing frees
it. This patch changes it to use XOBNEWVEC.
Also, the type_unit_unshareable::num_symtabs member is assigned but
never read. So, this removes it.
gdb/ChangeLog
2020-02-24 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct type_unit_unshareable) <num_symtabs>:
Remove.
* dwarf2/read.c (dwarf2_cu::setup_type_unit_groups): Use
XOBNEWVEC.
This converts the IS_TYPE_UNIT_GROUP to a method on
dwarf2_per_cu_data.
gdb/ChangeLog
2020-02-24 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct dwarf2_per_cu_data) <type_unit_group_p>:
New method.
* dwarf2/read.c (IS_TYPE_UNIT_GROUP): Remove.
(dw2_do_instantiate_symtab, dw2_get_file_names)
(build_type_psymtab_dependencies, load_full_type_unit): Update.
This simplifies the setting and clearing of reading_partial_symbols,
by using scoped_restore in the function that reads partial symbols.
gdb/ChangeLog
2020-02-24 Tom Tromey <tom@tromey.com>
* dwarf2read.c (dwarf2_build_psymtabs_hard): Use
make_scoped_restore.
(dwarf2_psymtab::read_symtab): Don't clear
reading_partial_symbols.
Consider a test-case compiled with -g:
...
int main (void) {
static int b = 2;
return 0;
}
...
When running info locals in main, we get:
...
(gdb) info locals
No locals.
...
The info locals documentation states:
...
Print the local variables of the selected frame, each on a separate line.
These are all variables (declared either static or automatic) accessible at
the point of execution of the selected frame.
...
So, "info locals" should have printed static variable b.
The variable is present in dwarf info:
...
<2><14a>: Abbrev Number: 6 (DW_TAG_variable)
<14b> DW_AT_name : b
<153> DW_AT_const_value : 2
...
but instead of a location attribute, it has a const_value attribute, which
causes the corresponding symbol to have LOC_CONST, which causes info locals to
skip it.
Fix this by handling LOC_CONST in iterate_over_block_locals.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-02-24 Tom de Vries <tdevries@suse.de>
PR gdb/25592
* stack.c (iterate_over_block_locals): Handle LOC_CONST.
gdb/testsuite/ChangeLog:
2020-02-24 Tom de Vries <tdevries@suse.de>
PR gdb/25592
* gdb.base/info-locals-unused-static-var.c: New test.
* gdb.base/info-locals-unused-static-var.exp: New file.
With test-case gdb.gdb/unittest.exp, I run into:
...
(gdb) maintenance selftest^M
...
Running selftest help_doc_invariants.^M
help doc broken invariant: command 'layout next' help doc first line is \
not terminated with a '.' character^M
help doc broken invariant: command 'layout prev' help doc first line is \
not terminated with a '.' character^M
help doc broken invariant: command 'layout regs' help doc first line is \
not terminated with a '.' character^M
Self test failed: self-test failed at help-doc-selftests.c:95^M
...
Fix this by adding the missing '.' character.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-02-24 Tom de Vries <tdevries@suse.de>
* tui/tui-layout.c (_initialize_tui_layout): Fix help messages for
commands layout next/prev/regs.
I noticed that dwarf2_compile_expr_to_ax can be static. Nothing
outside of loc.c calls it.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* dwarf2/loc.h (dwarf2_compile_expr_to_ax): Don't declare.
* dwarf2/loc.c (dwarf2_compile_expr_to_ax): Now static.
I noticed that the TUI_DISASM_WIN macro cast the disassembly window to
a base type, rather than its correct type. This patch fixes this
oversight.
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-data.h (TUI_DISASM_WIN): Cast to tui_disasm_window.
Change-Id: Ied3dbac9ef3dc48ceb9e0850fe4ada3c316dd769
This adds "usage" text to the help for all all the TUI commands. In
some cases the usage is borderline, but I tend to think being complete
is preferable.
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (_initialize_tui_win): Add usage text.
* tui/tui-stack.c (_initialize_tui_stack): Add usage text.
* tui/tui-regs.c (_initialize_tui_regs): Add usage text.
* tui/tui.c (_initialize_tui): Add usage text.
Change-Id: I727f7a7cfc03efa248ef98f30a18be393819e30b
This changes a couple of TUI commands to use error_no_arg. The
commands are also simplified a bit, and changed to use other gdb CLI
utility functions like skip_to_space. This lets us removes a couple
of defines that don't interact properly with gettext.
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_set_focus_command)
(tui_set_win_height_command): Use error_no_arg.
(_initialize_tui_win): Update help text.
(FOCUS_USAGE, WIN_HEIGHT_USAGE): Don't define.
Change-Id: I2bf95c2e5cfe1472d068388fa39f0cf07591b76c
This patch adds support for writing new TUI windows in Python.
2020-02-22 Tom Tromey <tom@tromey.com>
* NEWS: Add entry for gdb.register_window_type.
* tui/tui-layout.h (window_factory): New typedef.
(tui_register_window): Declare.
* tui/tui-layout.c (saved_tui_windows): New global.
(tui_apply_current_layout): Use it.
(tui_register_window): New function.
* python/python.c (do_start_initialization): Call
gdbpy_initialize_tui.
(python_GdbMethods): Add "register_window_type" function.
* python/python-internal.h (gdbpy_register_tui_window)
(gdbpy_initialize_tui): Declare.
* python/py-tui.c: New file.
* Makefile.in (SUBDIR_PYTHON_SRCS): Add py-tui.c.
gdb/doc/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* python.texi (Python API): Add menu item.
(TUI Windows In Python): New node.
gdb/testsuite/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* gdb.python/tui-window.exp: New file.
* gdb.python/tui-window.py: New file.
Change-Id: I85fbfb923a1840450a00a7dce113a05d7f048baa
do_tui_putc has some code to remove annotations from gdb output. This
was added in 2001, see commit a198b876bb.
However, I think this code is not needed. It seems very unlikely to
enable both annotations and the TUI, and in any case I think this is
something that should not be supported.
So, this patch removes this code.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-io.c (do_tui_putc): Don't omit annotations.
Change-Id: I05728110365a362d37c9821df9c8779316100bb8
I noticed that the TUI had two functions with similar names:
tui_set_win_focus_to and tui_set_win_with_focus.
However, one was just an implementation detail of the latter. So,
this patch removes tui_set_win_with_focus entirely, to avoid any
temptation to call it.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_set_win_focus_to): Move to tui-data.c.
* tui/tui-data.h (tui_set_win_with_focus): Don't declare.
* tui/tui-data.c (tui_set_win_with_focus): Remove.
(tui_set_win_focus_to): Move from tui-win.c.
Change-Id: Idffddab773436bdf80d55480906d76b292981ef2
This adds a new global that maps from window names to window
constructor functions, and then changes tui_get_window_by_name and
validate_window_name to use it. This is another step toward
user-defined window types.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-layout.c (make_standard_window, get_locator_window): New
functions.
(known_window_types): New global.
(tui_get_window_by_name): Reimplement.
(initialize_known_windows): New function.
(validate_window_name): Rewrite.
(_initialize_tui_layout): Call initialize_known_windows.
Change-Id: I9037aac550299b9d945899220a30c2d3af9dd0de
TUI windows no longer need to store their type -- there's only a
single spot that uses this information, and it can be changed to use
dynamic_cast. (It could be cleaned up even more, by using a virtual
method, but I haven't done so.) This patch removes the "type" field
from tui_gen_win_info, and this in turn allows removing a couple of
enumerator constants.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui.h (enum tui_win_type) <LOCATOR_WIN, DATA_ITEM_WIN>:
Remove constants.
* tui/tui-winsource.h (struct tui_source_window_base)
<tui_source_window_base>: Remove parameter.
* tui/tui-winsource.c
(tui_source_window_base::tui_source_window_base): Remove
parameter.
(tui_source_window_base::refill): Update.
* tui/tui-stack.h (struct tui_locator_window)
<tui_locator_window>: Update.
* tui/tui-source.h (struct tui_source_window) <tui_source_window>:
Default the constructor.
* tui/tui-regs.h (struct tui_data_item_window)
<tui_data_item_window>: Default the constructor.
(struct tui_data_window) <tui_data_window>: Likewise.
* tui/tui-disasm.h (struct tui_disasm_window) <tui_disasm_window>:
Default the constructor.
* tui/tui-data.h (struct tui_gen_win_info) <tui_gen_win_info>:
Default the constructor.
<type>: Remove.
(struct tui_win_info) <tui_win_info>: Default the constructor.
* tui/tui-data.c (tui_win_info::tui_win_info): Remove.
* tui/tui-command.h (struct tui_cmd_window) <tui_cmd_window>:
Default the constructor.
Change-Id: I594cd07d2e0bba71ad594a6fb263904ce2febcd6
tui_delete_invisible_windows is only needed after applying a layout,
and tui_make_all_invisible is only needed before applying a layout.
This patch removes these functions, in favor of doing this management
directly in tui_apply_current_layout. This is needed so that the
lifetimes of non-built-in windows will be properly managed.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-wingeneral.h (tui_make_all_invisible): Don't declare.
* tui/tui-wingeneral.c (tui_make_all_invisible): Remove.
* tui/tui-win.c (tui_resize_all): Don't call
tui_delete_invisible_windows.
* tui/tui-layout.c (tui_apply_current_layout): Delete windows when
done.
(tui_set_layout): Update.
(tui_add_win_to_layout): Don't call tui_delete_invisible_windows.
* tui/tui-data.h (tui_delete_invisible_windows): Don't declare.
* tui/tui-data.c (tui_delete_invisible_windows): Remove.
Change-Id: Ia3603b021dcb7ec31700a4a32640cd09b00b8f3b
This changes tui_partial_win_by_name to correctly handle an ambiguous
name prefix. This will be important once the user can register new
window types.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_partial_win_by_name): Handle ambiguity
correctly.
Change-Id: I59aaacd697eeab649164183457ef722dae58d60d
This reimplements tui_next_win and tui_prev_win. Now they account for
the possibility of windows not on tui_win_list.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-data.c (tui_next_win, tui_prev_win): Reimplement.
Change-Id: Ifcd402f76fe0a16e0fe9275a185d550279c01660
This changes the TUI to track all the instantiated windows in a new
global vector. After this, iteration over TUI windows is done by
simply iterating over this vector.
This approach makes it simpler to define new window types. In
particular, a subsequent patch will add the ability to define a TUI
window from Python.
Note that this series will not remove tui_win_list. This will
continue to exist in parallel, only because it was simpler to leave
this alone. Perhaps it could still be removed in the future.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.h (struct tui_source_window_iterator)
<inner_iterator>: New etytypedef.
<tui_source_window_iterator>: Take "end" parameter.
<tui_source_window_iterator>: Take iterator.
<operator*, advance>: Update.
<m_iter>: Change type.
<m_end>: New field.
(struct tui_source_windows) <begin, end>: Update.
* tui/tui-layout.c (tui_windows): New global.
(tui_apply_current_layout): Clear tui_windows.
(tui_layout_window::apply): Update tui_windows.
* tui/tui-data.h (tui_windows): Declare.
(all_tui_windows): Now inline function.
(class tui_window_iterator, struct all_tui_windows): Remove.
Change-Id: I6ab77976d6326f427178f725434f8f82046e0bbf
This changes the TUI layout engine to add horizontal splitting. Now,
windows can be side-by-side.
A horizontal split is defined using the "-horizontal" parameter to
"tui new-layout".
This also adds the first "winheight" test to the test suite. One open
question is whether we want a new "winwidth" command, now that
horizontal layouts are possible. This is easily done using the
generic layout code.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
PR tui/17850:
* tui/tui-win.c (tui_gen_win_info::max_width): New method.
* tui/tui-layout.h (class tui_layout_base) <get_sizes>: Add
"height" argument.
(class tui_layout_window) <get_sizes>: Likewise.
(class tui_layout_split) <tui_layout_split>: Add "vertical"
argument.
<get_sizes>: Add "height" argument.
<m_vertical>: New field.
* tui/tui-layout.c (tui_layout_split::clone): Update.
(tui_layout_split::get_sizes): Add "height" argument.
(tui_layout_split::adjust_size, tui_layout_split::apply): Update.
(tui_new_layout_command): Parse "-horizontal".
(_initialize_tui_layout): Update help string.
(tui_layout_split::specification): Add "-horizontal" when needed.
* tui/tui-layout.c (tui_layout_window::get_sizes): Add "height"
argument.
* tui/tui-data.h (struct tui_gen_win_info) <max_width, min_width>:
New methods.
gdb/doc/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
PR tui/17850:
* gdb.texinfo (TUI Commands): Document horizontal layouts.
gdb/testsuite/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
PR tui/17850:
* gdb.tui/new-layout.exp: Add horizontal layout and winheight
tests.
Change-Id: I38b35e504f34698578af86686be03c0fefd954ae
This changes tui_layout_base::adjust_size to return a new enum type.
I broke this out into a separate patch because it simplifies a
subsequent patch.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-layout.h (enum tui_adjust_result): New.
(class tui_layout_base) <adjust_size>: Return tui_adjust_result.
(class tui_layout_window) <adjust_size>: Return
tui_adjust_result. Rewrite.
(class tui_layout_split) <adjust_size>: Return tui_adjust_result.
* tui/tui-layout.c (tui_layout_split::adjust_size): Update.
Change-Id: I821b48ab06a9b9485875e147bd08a3bc46b900a0
The new TUI layout engine has support for "sub-layouts" -- this is a
layout that includes another layout as a child. A sub-layout is
treated as a unit when allocating space.
There's not a very strong reason to use sub-layouts currently. This
patch exists to introduce the idea, and to simplify the subsequent
patch that adds horizontal layouts -- where sub-layouts are needed.
Because this patch won't go in on its own, I chose to defer
documenting this change until the subsequent horizontal layout patch.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-layout.h (class tui_layout_split) <add_split>: Change
parameter and return types.
(class tui_layout_base) <specification>: Add "depth".
(class tui_layout_window) <specification>: Add "depth".
(class tui_layout_split) <specification>: Add "depth".
* tui/tui-layout.c (tui_layout_split::add_split): Change parameter
and return types.
(tui_new_layout_command): Parse sub-layouts.
(_initialize_tui_layout): Update help string.
(tui_layout_window::specification): Add "depth".
(add_layout_command): Update.
gdb/testsuite/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* gdb.tui/new-layout.exp: Add sub-layout tests.
Change-Id: Iddf52d067a552c168b8a67f29caf7ac86404b10c
This adds a new command, "tui new-layout". This command can be used
to define a new TUI window layout.
The command is used like:
(gdb) tui new-layout name src 1 regs 1 status 0 cmd 1
The first argument is the name of the layout. In this example, it is
"name", so the new layout could be seen by "layout name".
Subsequent arguments come in pairs, where the first item in a pair is
the name of a window, and the second item in a pair is the window's
weight. A weight is just an integer -- a window's allocated size is
proportional to the total of the weights given. So, in the above
example, all windows will have the same size (the status windows's
weight does not matter, because it has fixed height).
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* NEWS: Add "tui new-layout" item.
* tui/tui-layout.c (add_layout_command): Return cmd_list_element.
Add new-layout command to help text.
(validate_window_name): New function.
(tui_new_layout_command): New function.
(_initialize_tui_layout): Register "new-layout".
(tui_layout_window::specification): New method.
(tui_layout_window::specification): New method.
* tui/tui-layout.h (class tui_layout_base) <specification>: New
method.
(class tui_layout_window) <specification>: New method.
(class tui_layout_split) <specification>: New method.
gdb/doc/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* gdb.texinfo (TUI Overview): Mention user layouts.
(TUI Commands): Document "tui new-layout".
gdb/testsuite/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* gdb.tui/new-layout.exp: New file.
Change-Id: Id7c3ace20ab1e8924f8f4ad788f40210f58a5c05
This changes the TUI so that the available layouts are no longer
completely hard-coded. "enum tui_layout_type" is removed, and then
all the fallout from this is fixed up.
This patch also reimplements the "layout" command to be a prefix
command. The concrete layouts are simply sub-commands now. This
provides completion and correct abbreviation behavior for free.
Finally, this also changes the name of the locator window to "status".
This matches the documentation and will be exposed to the user in a
subsequent patch.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui.c (tui_enable): Call tui_set_initial_layout.
* tui/tui-win.c (window_name_completer): Update comment.
* tui/tui-layout.h (class tui_layout_base) <replace_window>:
Declare method.
(class tui_layout_window) <replace_window>: Likewise.
(class tui_layout_split) <replace_window>: Likewise.
(tui_set_layout): Don't declare.
(tui_set_initial_layout): Declare function.
* tui/tui-layout.c (layouts, applied_skeleton, src_regs_layout)
(asm_regs_layout): New globals.
(tui_current_layout, show_layout): Remove.
(tui_set_layout, tui_add_win_to_layout): Rewrite.
(find_layout, tui_apply_layout): New function.
(layout_completer): Remove.
(tui_next_layout): Reimplement.
(tui_next_layout_command): New function.
(tui_set_initial_layout, tui_prev_layout_command): New functions.
(tui_regs_layout): Reimplement.
(tui_regs_layout_command): New function.
(extract_display_start_addr): Rewrite.
(next_layout, prev_layout): Remove.
(tui_layout_window::replace_window): New method.
(tui_layout_split::replace_window): New method.
(destroy_layout): New function.
(layout_list): New global.
(add_layout_command): New function.
(initialize_layouts): Update.
(tui_layout_command): New function.
(_initialize_tui_layout): Install "layout" commands.
* tui/tui-data.h (enum tui_layout_type): Remove.
(tui_current_layout): Don't declare.
Change-Id: I9b5f7ab3ce838d6b340b8c373ef649a8e0a74b73
This reimplements the low-level layout function that is used by the
"tui reg" command. Now it simply calls into the existing "layout"
command, though this will be changed again in a subsequent patch. The
rationale for this patch is that it makes it simpler to remove
"enum tui_layout_type".
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-regs.c (tui_reg_layout): Remove.
(tui_reg_command): Use tui_regs_layout.
* tui/tui-layout.h (tui_reg_command): Declare.
* tui/tui-layout.c (tui_reg_command): New function.
Change-Id: I0ca6884e2967005e7d3fbf5f13a0ac8f9c3298cf
The TUI "C-x 1" key binding removes TUI windows, based on the current
layout. With user-defined layouts, this is no longer easy to do.
This patch changes "C-x 1" to simply delete windows, leaving just the
focus window, the locator, and the command window.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui.c (tui_rl_delete_other_windows): Call
tui_remove_some_windows.
* tui/tui-layout.h (class tui_layout_base) <remove_windows>:
Declare method.
(class tui_layout_window) <remove_windows>: New method.
(class tui_layout_split) <remove_windows>: Declare.
(tui_remove_some_windows): Declare.
* tui/tui-layout.c (tui_remove_some_windows): New function.
(tui_layout_split::remove_windows): New method.
Change-Id: If186f9c3f263913e963b965204481d1b4385c6d4
The TUI "C-x 2" binding tries to switch to a different layout based on
the current layout. Once user-defined layouts are available, this
won't really make sense. I wasn't entirely sure how to handle this.
This patch changes the binding to simply cycle through the existing
layouts. I considered this a reasonable, though not ideal,
compromise.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui.c (tui_rl_change_windows): Call tui_next_layout.
* tui/tui-layout.h (tui_next_layout): Declare.
* tui/tui-layout.c (tui_next_layout): New function.
Change-Id: Ic101f0e3831a4235a048b3090ef60f025f7449bb
tui_data_window creates new curses windows, but does not pass in
coordinates relative to the data window's origin. This means that the
data window could only ever be displayed as the topmost window in a
layout. This is not a currently problem, because all the existing
layouts do this; but a subsequent patch will add user-defined layouts,
which could do otherwise.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-regs.c (tui_data_window::display_registers_from): Use
correct coordinates.
Change-Id: I5101f2b2869557b87381ebdeebd9b7fd28687831
tui_add_win_to_layout is only ever called for the source or assembly
windows. This simplifies the function by removing the DATA_WIN case.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-layout.h (tui_add_win_to_layout): Add comment.
* tui/tui-layout.c (tui_add_win_to_layout): Add assert. Remove
DATA_WIN case.
Change-Id: Idfca902c6c90153acc5d19af4c33aa74bc3caf31
This is a minor cleanup to change tui_get_low_disassembly_address to
use TUI_DISASM_WIN, rather than the tui_win_list array. This is more
in line with what the rest of the TUI code does.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-disasm.c (tui_get_low_disassembly_address): Use
TUI_DISASM_WIN, not tui_win_list.
Change-Id: I999335ee3f63a4b570e84f320236b78f2bd5b780
This changes gdb to use the "variable" style when printing field
names. I've added new tests for C and Rust, but not other languages.
I chose "variable" because that seemed most straightforward. However,
another option would be to introduce a new "field" style. Similarly,
this patch uses the variable style for enumerator constants -- but
again, a new style could be used if that's preferred.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* valprint.c (generic_val_print_enum_1)
(val_print_type_code_flags): Style member names.
* rust-lang.c (val_print_struct, rust_print_enum)
(rust_print_struct_def, rust_internal_print_type): Style member
names.
* p-valprint.c (pascal_object_print_value_fields): Style member
names. Only call fprintf_symbol_filtered for static members.
* m2-typeprint.c (m2_record_fields, m2_enum): Style member names.
* f-valprint.c (f_val_print): Style member names.
* f-typeprint.c (f_type_print_base): Style member names.
* cp-valprint.c (cp_print_value_fields): Style member names. Only
call fprintf_symbol_filtered for static members.
(cp_print_class_member): Style member names.
* c-typeprint.c (c_print_type_1, c_type_print_base_1): Style
member names.
* ada-valprint.c (ada_print_scalar): Style enum names.
(ada_val_print_enum): Likewise.
* ada-typeprint.c (print_enum_type): Style enum names.
gdb/testsuite/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* gdb.rust/rust-style.rs: New file.
* gdb.rust/rust-style.exp: New file.
* gdb.base/style.exp: Test structure printing.
* gdb.base/style.c (struct some_struct): New type.
(enum etype): New type.
(struct_value): New global.
Change-Id: I070e1293c6cc830c9ea916af8243410aa384e944
The introductory comment for partial_symtab has been mildly incorrect
since the partial symtab code was changed to allocate partial symtabs
with "new". This patch removes the incorrect text.
gdb/ChangeLog
2020-02-21 Tom Tromey <tom@tromey.com>
* psympriv.h (struct partial_symtab): Update comment.
My earlier patch to fix a declaration mismatch in mips-tdep.h missed a
couple of spots. Basically, I sent it too soon.
This patch fixes a couple more mismatches between a declaration (using
bfd_vma) and the definition (using CORE_ADDR).
gdb/ChangeLog
2020-02-21 Tom Tromey <tromey@adacore.com>
* mips-tdep.h (mips_pc_is_mips16, mips_pc_is_micromips): Parameter
type is CORE_ADDR.
I noticed a regression with board cc-with-dwz:
...
FAIL: gdb.cp/m-static.exp: static const int initialized elsewhere
FAIL: gdb.cp/m-static.exp: info variable everywhere
...
The problem started with commit 0494dbecdf "Consolidate partial symtab
dependency reading".
The commit replaces the dwarf2_psymtab::expand_psymtab specific reading of
dependencies, which contains a "dependencies[i]->user == NULL" test, with a
generic partial_symtab::read_dependencies call, which does not test the user
field.
This patch fixes the regression by adding back the test, in the generic
partial_symtab::read_dependencies.
Build and reg-tested on x86_64-linux.
Tested natively, as well as with boards cc-with-dwz and cc-with-dwz-m.
The patch fixes all 33 regressions with cc-with-dwz, and all 2929 regression
with cc-with-dwz-m.
gdb/ChangeLog:
2020-02-21 Tom de Vries <tdevries@suse.de>
PR gdb/25534
* psymtab.c (partial_symtab::read_dependencies): Don't read dependency
if dependencies[i]->user != NULL.
I am sending this patch on behalf of kmoy@google.com, who discovered the bug
and wrote the fix.
gdb_demangle can return null for strings that don't properly demangle. The null
check was mistakenly removed in commit 43816ebc33. Without this check, GDB
aborts when loading symbols from some binaries.
gdb/ChangeLog
2020-02-21 Ali Tamur <tamur@google.com>
* dwarf2/read.c (dwarf2_name): Add null check.
dwarf2_find_containing_comp_unit has this in its binary search:
if (mid_cu->is_dwz > offset_in_dwz
|| (mid_cu->is_dwz == offset_in_dwz
&& mid_cu->sect_off + mid_cu->length >= sect_off))
high = mid;
The intent here is to determine whether SECT_OFF appears in or before
MID_CU.
I believe this has an off-by-one error, and that the check should use
">" rather than ">=". If the two side are equal, then SECT_OFF
actually appears at the start of the next CU.
I've had this patch kicking around for ages but I forget how I found
the problem.
gdb/ChangeLog
2020-02-20 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf2_find_containing_comp_unit): Use ">", not
">=", in binary search.
(dwarf2_find_containing_comp_unit): New overload.
(run_test): New self-test.
(_initialize_dwarf2_read): Register new test.
According to the riscv privilege spec, some CSR are only valid when rv32 or
the specific extension is set. We extend the DECLARE_CSR and DECLARE_CSR_ALIAS
to record more informaton we need, and then check whether the CSR is valid
according to these information. We report warning message when the CSR is
invalid, so we have a choice between error and warning by --fatal-warnings
option. Also, a --no-warn/-W option is used to turn the warnings off, if
people don't want the warnings.
gas/
* config/tc-riscv.c (enum riscv_csr_class): New enum. Used to decide
whether or not this CSR is legal in the current ISA string.
(struct riscv_csr_extra): New structure to hold all extra information
of CSR.
(riscv_init_csr_hash): New function. According to the DECLARE_CSR and
DECLARE_CSR_ALIAS, insert CSR extra information into csr_extra_hash.
Call hash_reg_name to insert CSR address into reg_names_hash.
(md_begin): Call riscv_init_csr_hashes for each DECLARE_CSR.
(reg_csr_lookup_internal, riscv_csr_class_check): New functions.
Decide whether the CSR is valid according to the csr_extra_hash.
(init_opcode_hash): Update 'if (hash_error != NULL)' as hash_error is
not a boolean. This is same as riscv_init_csr_hash, so keep the
consistent usage.
* testsuite/gas/riscv/csr-dw-regnums.d: Add -march=rv32if option.
* testsuite/gas/riscv/priv-reg.d: Add f-ext by -march option.
* testsuite/gas/riscv/priv-reg-fail-fext.d: New testcase. The source
file is `priv-reg.s`, and the ISA is rv32i without f-ext, so the
f-ext CSR are not allowed.
* testsuite/gas/riscv/priv-reg-fail-fext.l: Likewise.
* testsuite/gas/riscv/priv-reg-fail-rv32-only.d: New testcase. The
source file is `priv-reg.s`, and the ISA is rv64if, so the
rv32-only CSR are not allowed.
* testsuite/gas/riscv/priv-reg-fail-rv32-only.l: Likewise.
include/
* opcode/riscv-opc.h: Extend DECLARE_CSR and DECLARE_CSR_ALIAS to
record riscv_csr_class.
opcodes/
* riscv-dis.c (print_insn_args): Updated since the DECLARE_CSR is changed.
gdb/
* riscv-tdep.c: Updated since the DECLARE_CSR is changed.
* riscv-tdep.h: Likewise.
* features/riscv/rebuild-csr-xml.sh: Generate the 64bit-csr.xml without
rv32-only CSR.
* features/riscv/64bit-csr.xml: Regernated.
binutils/
* dwarf.c: Updated since the DECLARE_CSR is changed.
There is currently a regression when using
'{putchar,fputc}_unfiltered' with 'puts_unfiltered' which was
introduced by one of the commits that reworked the unfiltered print
code.
The regression makes it impossible to use '{putchar,fputc}_unfiltered'
with 'puts_unfiltered', because the former writes directly to the
ui_file stream using 'stream->write', while the latter uses a buffered
mechanism (see 'wrap_buffer') and delays the printing.
If you do a quick & dirty hack on e.g. top.c:show_gdb_datadir:
@@ -2088,6 +2088,13 @@ static void
show_gdb_datadir (struct ui_file *file, int from_tty,
struct cmd_list_element *c, const char *value)
{
+ putchar_unfiltered ('\n');
+ puts_unfiltered ("TEST");
+ putchar_unfiltered ('>');
+ puts_unfiltered ("PUTS");
+ putchar_unfiltered ('\n');
rebuild GDB and invoke the "show data-directory" command, you will
see:
(gdb) show data-directory
>
TESTPUTSGDB's data directory is "/usr/local/share/gdb".
Note how the '>' was printed before the output, and "TEST" and "PUTS"
were printed together.
My first attempt to fix this was to always call 'flush_wrap_buffer' at
the end of 'fputs_maybe_filtered', since it seemed to me that the
function should always print what was requested. But I wasn't sure
this was the right thing to do, so I talked to Tom on IRC and he gave
me another, simpler idea: make '{putchar,fputc}_unfiltered' call into
the already existing 'fputs_unfiltered' function.
This patch implements the idea. I regtested it on the Buildbot, and
no regressions were detected.
gdb/ChangeLog:
2020-02-20 Sergio Durigan Junior <sergiodj@redhat.com>
Tom Tromey <tom@tromey.com>
* utils.c (fputs_maybe_filtered): Call 'stream->puts' instead
of 'fputc_unfiltered'.
(putchar_unfiltered): Call 'fputc_unfiltered'.
(fputc_unfiltered): Call 'fputs_unfiltered'.
The motivation behind this commit is to make it easier to bundle the
Python *.py library files with GDB when statically linking GDB against
libpython. The Python files will be manually added into the GDB
installation tree, and GDB should be able to find them at run-time.
The installation tree will look like this:
.
|-- bin/
|-- include/
|-- lib/
| `-- python3.8/
`-- share/
The benefit here is that the entire installation tree can be bundled
into a single archive and copied to another machine with a different
version of Python installed, and GDB will still work, including its
Python support.
In use the new configure options would be used something like this,
first build and install a static Python library:
mkdir python
cd python
# Clone or download Python into a src/ directory.
mkdir build
export PYTHON_INSTALL_PATH=$PWD/install
cd build
../src/configure --disable-shared --prefix=$PYTHON_INSTALL_PATH
make
make install
Now build and install GDB:
mkdir binutils-gdb
cd binutils-gdb
# Clone or download GDB into a src/ directory.
mkdir build
export GDB_INSTALL_DIR=$PWD/install
cd build
../src/configure \
--prefix=$GDB_INSTALL_DIR \
--with-python=$PYTHON_INSTALL_PATH/bin/python3 \
--with-python-libdir=$GDB_INSTALL_DIR/lib
make all-gdb
make install-gdb
Finally, copy the Python libraries into the GDB install:
cp -r $PYTHON_INSTALL_DIR/lib/python3.8/ $GDB_INSTALL_DIR/lib
After this the Python src, build, and install directories are no
longer needed and can be deleted.
If the new --with-python-libdir option is not used then the existing
behaviour is left unchanged, GDB will look for the Python libraries in
the lib/ directory within the python path. The concatenation of the
python prefix and the string 'lib/' is now done at configure time,
rather than at run time in GDB as it was previous, however, this was
never something that the user had dynamic control over, so there's no
loss of functionality.
gdb/ChangeLog:
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Add --with-python-libdir option.
* main.c: Use WITH_PYTHON_LIBDIR.
This patch simplifies compute_and_set_names in a couple of ways.
First, it changes one spot to use obstack_strndup, which is
equivalent, but more concise.
Second, the function ends with two calls to symbol_set_demangled_name.
This can be simplified to a single call.
gdb/ChangeLog
2020-02-19 Tom Tromey <tom@tromey.com>
* symtab.c (general_symbol_info::compute_and_set_names): Use
obstack_strndup. Simplify call to symbol_set_demangled_name.
This is a simple cleanup. These functions used to use the objfile's
obstack for allocation in the hash tables, but they don't anymore.
Remove the unnecessary objfile parameters, which in turn allows removing
some local variables.
gdb/ChangeLog:
* dwarf2/read.c (allocate_signatured_type_table,
allocate_dwo_unit_table, allocate_type_unit_groups_table,
allocate_dwo_file_hash_table, allocate_dwp_loaded_cutus_table):
Remove objfile parameter, update all callers.
A build where CORE_ADDR is not the same as bfd_vma pointed out that
mips_pc_is_mips is declared using bfd_vma as the parameter type, but
defined using CORE_ADDR. This patch fixes the declaration.
gdb/ChangeLog
2020-02-19 Tom Tromey <tromey@adacore.com>
* mips-tdep.h (mips_pc_is_mips): Parameter type is CORE_ADDR.
Tom Tromey
Nelson Chu
Pedro Franco de Carvalho
Simon Marchi
Tom Tromey
Hannes Domani
John Baldwin
Tom de Vries
Andrew Burgess
Simon Marchi
Kamil Rytarowski
Luis Machado
Anton Kolesov
Christian Biesinger
Kevin Buettner
Tankut Baris Aktemur
Sergio Durigan Junior
Jon Turney
Aaron Merey
Jérémie Galarneau
Joel Brobecker
Ali Tamur via gdb-patches
Doug Evans