This changes a few TUI globals to be "static". Tested by rebuilding.
gdb/ChangeLog
2019-12-30 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_border_mode_translate)
(tui_border_kind_translate_vline, tui_border_kind_translate_hline)
(tui_border_kind_translate_ulcorner)
(tui_border_kind_translate_urcorner)
(tui_border_kind_translate_llcorner)
(tui_border_kind_translate_lrcorner, tui_active_border_mode)
(tui_border_mode, tui_border_kind): Now static.
Change-Id: Ibb49a0df195dfe780a5ba1f90e9125ab5f6b7ce1
This changes a few spots in the TUI to use "bool" rather than "int".
Tested on x86-64 Fedora 28.
gdb/ChangeLog
2019-12-30 Tom Tromey <tom@tromey.com>
* tui/tui-interp.c (tui_start_enabled): Now bool.
(_initialize_tui_interp): Update.
* tui/tui-hooks.c (tui_refreshing_registers): Now bool.
(tui_register_changed)
(tui_refresh_frame_and_register_information): Update.
* tui/tui-win.c (tui_update_variables): Return bool.
* tui/tui-win.h (tui_update_variables): Return bool.
* tui/tui.c (tui_get_command_dimension): Return bool.
* tui/tui.h (tui_get_command_dimension): Return bool.
Change-Id: I55b7f2d62d2ef88da3587dc914ada9f463ad8d2b
This removes code that was present from the very first git revisison
7b4ac7e1ed from 1988. It was in the
gdb/dbxread.c at the time (and makes more sense for dbx line info format
since line numbers are 16-bit entities in that debug format and debugging
files with more than 65535 lines would not work anyway) but moved from
there to gdb/buildsym.c which is used for dwarf line info as well, and
excluding an arbitrary line number does certainly not make sense nowadays.
Add a test case for line 65535
gdb:
2019-12-29 Bernd Edlinger <bernd.edlinger@hotmail.de>
* buildsym.c (buildsym_compunit::record_line): Do no longer ignore
line 65535.
gdb/testsuite:
2019-12-29 Bernd Edlinger <bernd.edlinger@hotmail.de>
* gdb.base/line65535.exp: New file.
* gdb.base/line65535.c: New file.
This test verifies that GDB correctly identifies the run-time type of
"s" as being the type "Circle". However, that can only be done
correctly if the GNAT runtime has been compiled and shipped with debug
information, so that GDB can poke in its internal data structures.
Currently the test fails when when running against a GNAT runtime
without debug info. This is the case, for example, on Arch Linux using
the distribution package.
This patch adds a helper in lib/ada.exp to check whether the GNAT
runtime has debug info or not. It then uses it in
gdb.ada/ptype_tagged_param.exp to expect a different result, depending
on whether we have debug info or not in the runtime.
At first, I made it so we would XFAIL the test, in the absence of debug
info, but then I thought that we might as well test for the output we
expect in the absence of debug info instead.
gdb/testsuite/ChangeLog:
* lib/ada.exp (gnat_runtime_has_debug_info): New proc.
* lib/gnat_debug_info_test.adb: New file.
* gdb.ada/ptype_tagged_param.exp: Use
gnat_runtime_has_debug_info, expect a different output if
runtime does not have debug info.
I found some dead code in the TUI -- some using #if 0, and some
commented-out code. There's no reason to keep this, so this patch
removes it.
gdb/ChangeLog
2019-12-27 Tom Tromey <tom@tromey.com>
* tui/tui-source.c (tui_source_window::do_scroll_vertical): Remove
commented-out code.
* tui/tui.c: Remove #if 0 code.
Change-Id: Ie00933b2ba498417ce22e5da3f62f5a40c234f33
I noticed that print_disassembly has two #if blocks for TUI code,
where one would do. This patch rearranges the code slightly to remove
a #if.
gdb/ChangeLog
2019-12-27 Tom Tromey <tom@tromey.com>
* cli/cli-cmds.c (print_disassembly): Reorder "if".
Change-Id: I36f3f682f5685b3d9b148da5aed26eb3cc7d598e
This changes tui_active and tui_finish_init to have type "bool".
gdb/ChangeLog
2019-12-27 Tom Tromey <tom@tromey.com>
* tui/tui.c (tui_active): Now bool.
(tui_finish_init): Likewise.
(tui_enable): Update.
(tui_disable): Update.
(tui_is_window_visible): Update.
* tui/tui.h (tui_active): Now bool.
Change-Id: Ia159ae9beb041137e34956b77f5bcf4e83eaf2b9
tui_gen_win_info::viewport_height is only used in a couple of spots,
and is redundant with "height". This patch removes viewport_height.
gdb/ChangeLog
2019-12-27 Tom Tromey <tom@tromey.com>
* tui/tui-source.c (tui_source_window::maybe_update): Update.
* tui/tui-regs.c (tui_data_window::display_registers_from):
Update.
* tui/tui-layout.c (tui_gen_win_info::resize): Update.
* tui/tui-data.h (struct tui_gen_win_info) <viewport_height>:
Remove.
* tui/tui-command.c (tui_cmd_window::resize): Update.
Change-Id: I020e026fbe289adda8e2fdfebca91bdbdbc312e8
This also renames it to make it clearer that this is not a cheap
function (to compute_and_set_names). Also renames name to m_name
to make the implementation of the renamed function more readable.
Most of the places that access sym->m_name directly were also changed
to call linkage_name () instead, to make it clearer which name they
are accessing.
gdb/ChangeLog:
2019-12-26 Christian Biesinger <cbiesinger@google.com>
* ada-lang.c (ada_decode_symbol): Update.
* buildsym.c (add_symbol_to_list): Update.
* coffread.c (process_coff_symbol): Update.
* ctfread.c (ctf_add_enum_member_cb): Update.
(new_symbol): Update.
(ctf_add_var_cb): Update.
* dwarf2read.c (fixup_go_packaging): Update.
(dwarf2_compute_name): Update.
(new_symbol): Update.
* jit.c (finalize_symtab): Update.
* language.c (language_alloc_type_symbol): Update.
* mdebugread.c (new_symbol): Update.
* minsyms.c (minimal_symbol_reader::record_full): Update.
(minimal_symbol_reader::install): Update.
* psymtab.c (print_partial_symbols): Update.
(psymbol_hash): Update.
(psymbol_compare): Update.
(add_psymbol_to_bcache): Update.
(maintenance_check_psymtabs): Update.
* stabsread.c (define_symbol): Update.
* symtab.c (symbol_set_names): Rename to...
(general_symbol_info::compute_and_set_names): ...this.
(general_symbol_info::natural_name): Update.
(general_symbol_info::search_name): Update.
(fixup_section): Update.
* symtab.h (struct general_symbol_info) <name>: Rename to...
<m_name>: ...this.
<compute_and_set_names>: Rename from...
(symbol_set_names): ...this.
(SYMBOL_SET_NAMES): Remove.
(struct symbol) <ctor>: Update.
Change-Id: I8da1f10cab4e0b89f19d5750fa4e6e2ac8d2b24f
Now that we enabled it by default, this change adds a NEWS entry for it.
gdb/ChangeLog:
2019-12-26 Christian Biesinger <cbiesinger@google.com>
* NEWS: Mention that multithreaded symbol loading is now on by
default.
Change-Id: Ic344596a3b1b6e612a0071a50df49588b833c15d
The SVR4 solib event handler determines whether an event is related to a
non-base link namespace by comparing the event's debug struct address
to the debug struct address of the initial program image. However, this
can fail when using LD_AUDIT as audit libraries are loaded before the
loader has initialised the initial program image's debug struct. When
the event handler fails to find the debug struct, the probe-based
debugger interface is disabled and a warning is flagged to the user.
This commit adds a fallback test to help determine whether an event is
for a foreign link namespace when the debug struct isn't available.
gdb/ChangeLog:
2019-12-15 George Barrett <bob@bob131.so>
* solib-svr4.c (svr4_handle_solib_event): Add fallback link
namespace test for when the debug struct isn't available.
gdb/ChangeLog
2019-12-21 Eli Zaretskii <eliz@gnu.org>
* top.c (print_gdb_configuration): Print "--with-xxhash" or
"--without-xxhash" according to HAVE_LIBXXHASH.
* Use the type-safe registry for ctf_file_key;
* Drop "typedef" when defining "struct ctf_context";
* Use ANOFFSET with SECT_OFF_TEXT to get the text base address;
gdb/ChangeLog
2019-12-20 Weimin Pan <weimin.pan@oracle.com>
* ctfread.c (ctf_file_key): Change type to objfile_key.
(struct ctf_context): Remove typedef.
(get_objfile_text_range): Use ANOFFSET to get text base.
In my previous commit, I missed this other spot that is missing a
quote...
gdb/testsuite/ChangeLog:
* lib/sym-info-cmds.exp (GDBInfoSymbols::check_no_entry): Add
(another) quote in test name.
This is a refactoring. Instead of a plain unsigned value, use an enum
bitfield.
gdb/ChangeLog:
2019-12-20 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* dwarf2read.c (is_valid_DW_AT_calling_convention_for_subroutine):
New function.
(read_subroutine_type): Validate the parsed
DW_AT_calling_convention value before assigning it to a
subroutine's calling_convention attribute.
* gdbtypes.h (struct func_type) <calling_convention>: Use
an enum bitfield as its type, instead of plain unsigned.
Change-Id: Ibc6b2f71e885cbc5c3c9d49734f7125acbfd1bcd
Extend testcases for GDB's infcall of call-by-value functions that
take aggregate values as parameters. In particular, existing test has
been substantially extended with class definitions whose definitions
of copy constructor, destructor, and move constructor functions are a
combination of
(1) explicitly defined by the user,
(2) defaulted inside the class declaration,
(3) defaulted outside the class declaration,
(4) deleted
(5) not defined in the source.
For each combination, a small and a large class is generated as well
as a derived class and a container class. Additionally, the following
manually-written cases are provided:
- a dynamic class (i.e. class with a virtual method)
- classes that contain an array field
- a class whose copy ctor is inlined
- a class whose destructor is deleted
- classes with multiple copy and/or move ctors
Test cases check whether GDB makes the right decision to pass an
object by value or implicitly by reference, whether really a copy of
the argument is passed, and whether the copy constructor and
destructor of the clone of the argument are invoked properly.
The input program pass-by-ref.cc is generated in the test's output
directory. The input program pass-by-ref-2.cc is manually-written.
Tests have been verified on the X86_64 architecture with
GCC 7.4.0, 8.2.0, and 9.2.1.
gdb/testsuite/ChangeLog:
2019-12-20 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.cp/pass-by-ref.cc: Delete. Generated in the output
directory instead.
* gdb.cp/pass-by-ref.exp: Extend with more cases.
* gdb.cp/pass-by-ref-2.cc: New file.
* gdb.cp/pass-by-ref-2.exp: New file.
Change-Id: Ie8ab1f260c6ad5ee4eb34b2c1597ce24af04abb6
If an aggregate argument is implicitly pass-by-reference, allocate a
temporary object on the stack, initialize it via the copy constructor
(if exists) or trivially by memcpy'ing. Pass the reference of the
temporary to the callee function. After the callee returns, invoke
the destructor of the temporary.
gdb/ChangeLog:
2019-12-20 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
PR gdb/25054
* infcall.c (call_function_by_hand_dummy): Update the argument-
passing section for call-by-value parameters.
(struct destructor_info): New struct.
(call_destructors): New auxiliary function.
Change-Id: I18fa5d0df814dfa0defe9e862a88a6dbf1d99d01
Walk through a given type to collect information about whether the
type is copy constructible, destructible, trivially copyable,
trivially copy constructible, trivially destructible. The previous
algorithm returned only a boolean result about whether the type is
trivially copyable. This patch computes more info. Additionally, it
utilizes DWARF attributes that were previously not taken into account;
namely, DW_AT_deleted, DW_AT_defaulted, and DW_AT_calling_convention.
gdb/ChangeLog:
2019-12-20 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gnu-v3-abi.c (enum definition_style): New enum type.
(get_def_style): New function.
(is_user_provided_def): New function.
(is_implicit_def): New function.
(is_copy_or_move_constructor_type): New function.
(is_copy_constructor_type): New function.
(is_move_constructor_type): New function.
(gnuv3_pass_by_reference): Collect language_pass_by_ref_info
for a given type.
Change-Id: Ic05bd98a962d07ec3c1ad041f709687eabda3bb9
In C++, call-by-value arguments that cannot be trivially copied are
implicitly passed by reference. When making an infcall, GDB needs to
find out if an argument is pass-by-reference or not, so that the
correct semantics can be followed. This patch enriches the
information computed by the language ops for pass-by-reference
arguments. Instead of a plain binary result, the computed information
now includes whether the argument is
- copy constructible
- destructible
- trivially copyable
- trivially copy constructible
- trivially destructible
This information is stored in a struct named 'language_pass_by_ref_info'.
This patch paves the way for GDB's infcall mechanism to call the copy
ctor and the destructor of a pass-by-ref argument appropriately.
gdb/ChangeLog:
2019-12-20 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* language.h (struct language_pass_by_ref_info): New struct.
(struct language_defn)<la_pass_by_reference>: Change the signature
to return a language_pass_by_ref_info instead of an int.
(language_pass_by_reference): Ditto.
(default_pass_by_reference): Ditto.
Adjust the users listed below.
* arch-utils.c (default_return_in_first_hidden_param_p):
Update.
* cp-abi.c (cp_pass_by_reference): Update.
* cp-abi.h (cp_pass_by_reference): Update declaration.
(struct cp_abi_ops)<pass_by_reference>: Update.
* gnu-v3-abi.c (gnuv3_pass_by_reference): Update.
* infcall.c (call_function_by_hand_dummy): Update.
* language.c (language_pass_by_reference): Update.
(default_pass_by_reference): Update.
* tic6x-tdep.c (tic6x_return_value): Update.
Change-Id: Ib1c1f87f2490a5737c469f7b7185ddc7f6a164cb
Extend GDB's internal representation of types to include the
DW_AT_calling_convention, DW_AT_defaulted, and DW_AT_deleted attributes
that were introduced in DWARF5.
These attributes will be helpful in a future patch about infcall'ing
functions with call-by-value parameters. GDB will use the attributes
to decide whether the type of a call-by-value parameter is implicitly
pass-by-reference.
gdb/ChangeLog:
2019-12-20 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* dwarf2read.c (dwarf2_add_member_fn): Read the DW_AT_defaulted
and DW_AT_deleted attributes of a function.
(read_structure_type): Read the DW_AT_calling_convention attribute
of a type.
(is_valid_DW_AT_defaulted): New function.
(is_valid_DW_AT_calling_convention_for_type): New function.
* gdbtypes.h: Include dwarf2.h.
(struct fn_field)<defaulted>: New field to store the
DW_AT_defaulted attribute.
(struct fn_field)<is_deleted>: New field to store the
DW_AT_deleted attribute.
(struct cplus_struct_type)<calling_convention>: New field to store
the DW_AT_calling_convention attribute.
(TYPE_FN_FIELD_DEFAULTED): New macro.
(TYPE_FN_FIELD_DELETED): New macro.
(TYPE_CPLUS_CALLING_CONVENTION): New macro.
* gdbtypes.c (dump_fn_fieldlists): Update for the changes made
to the .h file.
(print_cplus_stuff): Likewise.
Change-Id: I54192f363115b78ec7435a8563b73fcace420765
This removes the call to tui_show_source from tui_ui_out. This always
seemed like a hack, and now that the TUI is using the proper
observers, it seems not to be needed.
The rest of the logic remains, unfortunately, because it is needed to
suppress some gdb output in the TUI case. We could probably find a
nicer way to do this (maybe a ui_out_flag), but I haven't attempted
this.
This was the last caller of tui_show_source, so this is removed as
well.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui.c (tui_show_source): Remove.
* tui/tui.h (tui_show_source): Don't declare.
* tui/tui-out.c (tui_ui_out::do_field_string): Don't call
tui_show_source.
Change-Id: Id71098e597ee4ebfef0429562baa45f537bd2c2b
PR tui/18932 notes that "list" no longer works in the TUI. At some
point in the past, it switched the TUI source window to show the
specified source; but now this source briefly flashes before the TUI
reverts to showing the current stack frame's source.
This patch fixes this bug by introducing a new observer that notices
when the user selected context has changed. Then, the existing
before-prompt observer is updated to request the correct update:
either one based on the current stack frame, or one based on the
user's source symtab_and_line.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
PR tui/18932:
* tui/tui-hooks.c (tui_refresh_frame_and_register_information):
Rename parameters. Handle the not-from-stack-frame case.
(from_stack, from_source_symtab): New globals.
(tui_before_prompt, tui_normal_stop): Update.
(tui_context_changed, tui_symtab_changed): New functions.
(tui_attach_detach_observers): Attach new observers.
gdb/testsuite/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* gdb.tui/list-before.exp: New file.
Change-Id: I62013825f6c1afdd568a1c7a8c019b0c881131af
This patch adds an observable, so that a later patch can change the
TUI to notice when the user has selected a new source symtab, say via
"list".
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* source.c (struct current_source_location) <set, symtab, line>:
New methods.
<m_symtab, m_line>: Rename. Now private.
(get_current_source_symtab_and_line)
(set_default_source_symtab_and_line)
(set_current_source_symtab_and_line)
(clear_current_source_symtab_and_line, select_source_symtab)
(info_source_command, print_source_lines_base)
(info_line_command, search_command_helper): Update.
* observable.h (current_source_symtab_and_line_changed): Declare
observable.
* observable.c (current_source_symtab_and_line_changed): Define
observable.
Change-Id: I3c0f6b40f2df84b590bdf5b5ec5ccd8423bb7f22
This changes tui_before_prompt to take a bool rather than an int.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui-hooks.c (tui_before_prompt): Change parameter to bool.
(tui_before_prompt, tui_normal_stop): Update.
Change-Id: I9c7f2b764748fe19621851dc4fed4775a6db211a
update_source_window_as_is calls set_current_source_symtab_and_line,
but I don't think there is any reason it should be doing this. This
patch removes the call.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.c
(tui_source_window_base::update_source_window_as_is): Don't call
set_current_source_symtab_and_line.
Change-Id: I1152fc7c78150974bd3d555b8568a6f88b65dbe6
This changes set_locator_info to take a symtab_and_line, rather than
the individual components.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui-stack.h (struct tui_locator_window) <set_locator_info>:
Take a symtab_and_line.
* tui/tui-stack.c (tui_locator_window::set_locator_info): Take a
symtab_and_line.
(tui_show_frame_info): Update.
Change-Id: Icb58d67e6c5bdc034eede9e5bbe8c1d1e633fbb5
tui_show_frame_info calls update_exec_info after calling
erase_source_content, but there's no need to do this, as
erase_source_content already clears the exec info.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui-stack.c (tui_show_frame_info): Don't call
update_exec_info.
Change-Id: I63d658561028ac1bc0a0a2b7ac17da1b9c6134fe
I noticed that even when there's a symbol file, "tui enable" won't
show "main" by default. I think it should, and this patch fixes this.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui.c (tui_enable): Call tui_display_main.
gdb/testsuite/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* gdb.tui/list.exp: Check for source on initial listing.
Change-Id: Ic7bfc930e1179f5b61111e30a2dae46a98b00064
tui_get_begin_asm_address looks for the inferior's "main" to display
it. I think this is incorrect in two ways.
First, it should probably instead use the user's most recent source
context, if one has been set.
Second, it uses a hard-coded list of "main" names, but gdb already has
a better approach to handling this.
This patch fixes both of these problems.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui-disasm.c (tui_get_begin_asm_address): Use
get_current_source_symtab_and_line, and main_name.
Change-Id: I77dc13d49148e8dec5aa3eeb357ce3968a68d0bd
This changes tui_update_source_windows_with_line to take a
symtab_and_line, rather than separate parameters, and then updates the
caller.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui.c (tui_show_source): Update.
* tui/tui-winsource.h (tui_update_source_windows_with_line): Update.
* tui/tui-winsource.c (tui_update_source_windows_with_line): Take
a symtab_symbol_info, not a separate symtab and line. Simplify.
Change-Id: I8803a0a6fd2938ceee859aea53a57ce582f3e80d
After the previous changes, tui_update_source_windows_with_addr simply
updates each source-like window separately, passing the same data to
each. So, it can be simplified by using a loop instead.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.c (tui_update_source_windows_with_addr):
Simplify.
Change-Id: Id2ba6b3145ec005dbed1b1115118bd1ef4efb842
This changes a few TUI source window methods to take a symtab_and_line
rather than separate symtab and tui_line_or_address parameters. A
symtab_and_line already incorporates the same information, so this
seemed simpler. Also, it helps avoid the problem that the source and
disassembly windows need different information -- both forms are
present in the SAL.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.h (struct tui_source_window_base)
<set_contents, update_source_window_as_is, update_source_window>:
Take a sal, not a separate symtab and tui_line_or_address.
* tui/tui-winsource.c (tui_source_window_base::update_source_window)
(tui_source_window_base::update_source_window_as_is): Take a sal,
not a separate symtab and tui_line_or_address.
(tui_update_source_windows_with_addr)
(tui_update_source_windows_with_line)
(tui_source_window_base::rerender)
(tui_source_window_base::refill): Update.
* tui/tui-source.h (struct tui_source_window) <set_contents>: Take
a sal, not a separate symtab and tui_line_or_address.
* tui/tui-source.c (tui_source_window::set_contents): Take a sal,
not a separate symtab and tui_line_or_address.
(tui_source_window::maybe_update): Update.
* tui/tui-disasm.h (struct tui_disasm_window) <set_contents>: Take
a sal, not a separate symtab and tui_line_or_address.
* tui/tui-disasm.c (tui_disasm_window::set_contents): Take a sal,
not a separate symtab and tui_line_or_address.
(tui_disasm_window::do_scroll_vertical)
(tui_disasm_window::maybe_update): Update.
Change-Id: I6974a03589930a0f910c657ef50b7f6f7397c87d
A few spots in the TUI source and disassembly windows referred to
content[0], where start_line_or_addr is equivalent. This patch makes
this substitution.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.c (tui_source_window_base::refill): Use
start_line_or_addr.
* tui/tui-source.c (tui_source_window::do_scroll_vertical): Use
start_line_or_addr.
* tui/tui-disasm.c (tui_disasm_window::do_scroll_vertical): Use
start_line_or_addr.
Change-Id: I1fa807321cd7ad88b3cc5e41cc50f4d4e2d46271
This changes tui_source_window_base::set_contents to return bool,
rather than tui_status. It also changes one implementation of
set_contents to use early returns rather than a variable, which IMO
makes it easier to follow.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.h (struct tui_source_window_base)
<set_contents>: Return bool.
* tui/tui-winsource.c
(tui_source_window_base::update_source_window_as_is): Update.
* tui/tui-source.h (struct tui_source_window) <set_contents>:
Return bool.
* tui/tui-source.c (tui_source_window::set_contents): Return
bool. Simplify.
* tui/tui-disasm.h (struct tui_disasm_window) <set_contents>:
Return bool.
* tui/tui-disasm.c (tui_disasm_window::set_contents): Return
bool.
Change-Id: I8c5212400cd7aadf35760c22d5344cd3b9435674
tui_show_disassem is just a wrapper for the update_source_window
method, and it only has a single caller. This removes the function
and inlines the logic into that caller.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.c (tui_update_source_windows_with_addr): Call
update_source_window directly.
* tui/tui-disasm.h (tui_show_disassem): Don't declare.
* tui/tui-disasm.c (tui_show_disassem): Remove.
Change-Id: I7ae7a3309f64a4a949c07a80c46e1664c7f12913
A couple of lower-level utility functions can change the TUI focus.
This seems incorrect to me -- focus switches should only be done
either by explicit user request, or ass a side effect of changing the
layout.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.c
(tui_source_window_base::update_source_window_as_is): Don't switch focus.
* tui/tui-disasm.c (tui_show_disassem): Don't switch focus.
Change-Id: I0a5bb8a407cf8d52e2fd23b0598eb9bce56b1251
tui_source_window_base::maybe_update takes a symtab_and_line, plus a
separate line number and PC. Because a symtab_and_line already holds
a line number and a PC, it is possible to remove these extra
parameters.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.h (struct tui_source_window_base)
<maybe_update>: Remove line_no and addr parameters.
* tui/tui-stack.c (tui_show_frame_info): Set PC on sal. Update.
* tui/tui-source.h (struct tui_source_window) <maybe_update>:
Update.
* tui/tui-source.c (tui_source_window::maybe_update): Remove
line_no and addr parameters.
* tui/tui-disasm.h (struct tui_disasm_window) <maybe_update>:
Update.
* tui/tui-disasm.c (tui_disasm_window::maybe_update): Remove
line_no and addr parameters.
Change-Id: I33d8e1a669a179544edb4197f5f7c5429dfc368e
This removes a few asserts from the TUI. These asserts aren't useful,
because they simply check an invariant that's already ensured by the
type system.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.c (tui_source_window_base::set_is_exec_point_at)
(tui_source_window_base::update_breakpoint_info): Remove asserts.
Change-Id: I807e1e9bdb0cfa475e70375ceca3a5d4f2eb8d0b
tui_show_disassem_and_update_source only has a single caller. This
patch simplifies that caller, by having it call tui_show_disassem, and
then removes tui_show_disassem_and_update_source.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.c (tui_update_source_windows_with_addr): Call
tui_show_disassem.
* tui/tui-disasm.h (tui_show_disassem_and_update_source): Don't
declare.
* tui/tui-disasm.c (tui_show_disassem_and_update_source): Remove.
Change-Id: I7554eca8e259f3539ea7710f2ff369b4a630dd9d
tui_show_source does not need its parameters, so this removes them.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui.h (tui_show_source): Remove parameters.
* tui/tui.c (tui_show_source): Remove parameters.
* tui/tui-out.c (tui_ui_out::do_field_string): Update.
Change-Id: I7cbcf20175b459c269549f1832d4fb844cc573db
This changes tui_update_locator_fullname to take a symtab. This
somewhat consolidates the "??" handling.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
* tui/tui.c (tui_show_source): Update.
* tui/tui-winsource.c (tui_display_main): Update.
* tui/tui-stack.h (tui_update_locator_fullname): Change parameter
to symtab.
* tui/tui-stack.c (tui_update_locator_fullname): Change parameter
to symtab.
* tui/tui-disasm.c (tui_show_disassem_and_update_source): Update.
Change-Id: Ic61749517b44ac68561d829ff81f16976b830dec
PR tui/23619 points out that isearch changes the prompt in the CLI gdb
(and in Bash) -- but not in the TUI. This turns out to be easily
fixed by removing tui_rl_saved_prompt and instead using the prompt
that readline computes.
This is stored in rl_display_prompt, which according to git was added
in readline 6.2.
gdb/ChangeLog
2019-12-20 Tom Tromey <tom@tromey.com>
PR tui/23619:
* tui/tui-io.c (tui_rl_saved_prompt): Remove.
(tui_redisplay_readline): Use rl_display_prompt.
(tui_prep_terminal): Update.
Change-Id: Iae97e9776a5540bbe52c73b05e4707941d9cd11a
This ensures that empty variables and variables with spaces are handled
correctly.
Code was inconsistent on whether the constant string (e.g. yes/no)
should also be quoted; I tried to be consistent with surrounding code.
This fixes the error Eli reported during configure with mingw (though that
was not fatal).
gdb/ChangeLog:
2019-12-19 Christian Biesinger <cbiesinger@google.com>
* configure: Regenerate.
* configure.ac: Quote variable arguments of test.
* gdbsupport/common.m4: Likewise.
gdb/gdbserver/ChangeLog:
2019-12-19 Christian Biesinger <cbiesinger@google.com>
* configure: Regenerate.
* configure.ac: Quote variable arguments of test.
Change-Id: I220e78b52c7db88b9dd058eda604635b03464fac
GNU Make 3.81 is apparently confused when the same
source file is processed by a pattern rule and an
explicit rule at the same time with different output file.
The pattern %.o: ../%.c and alloc-ipa.o: ../alloc.c
both have the source ../alloc.c but two independent
object files alloc.o and alloc-ipa.o, so
while building gdbserver I see the following message:
make[4]: Circular alloc-ipa.o <- ../alloc.c dependency dropped.
CXX alloc-ipa.o
g++: warning: '-x c++' after last input file has no effect
g++: fatal error: no input files
compilation terminated.
In the make debug output I see the pattern is first correct:
alloc-ipa.o: ../alloc.c | config.h build-gnulib-gdbserver/import/string.h
$(IPAGENT_COMPILE) $(WARN_CFLAGS_NO_FORMAT) $<
$(POSTCOMPILE)
But after the "Circular" dependency is dropped, the pattern
is changed to:
alloc-ipa.o: | config.h build-gnulib-gdbserver/import/string.h
$(IPAGENT_COMPILE) $(WARN_CFLAGS_NO_FORMAT) $<
$(POSTCOMPILE)
So indeed now $< is empty, and the build step fails.
This happens only when alloc.o needs to be built, when alloc.o
was already built, the build succeeds, but it takes often
several attempts until the build succeeds.
By rewriting the alloc-ipa.c: ../alloc.c rule into a pattern
rule, the problem goes away.
While already at it, this patch removes also the
$(WARN_CFLAGS_NO_FORMAT) from the build rule, which is just a
copy/paste thing that is not necessary for alloc.c at all.
Since pow takes doubles, pass 2.0 instead of 2 to pow ().
Conveniently, this fixes the ambiguous call to pow on Solaris 11
with gcc 5.5 (gcc211 on the compile farm), which has a "using std::pow"
directive in a system header, which brings in float/double/long double
overloads. Fixes the build on Solaris with enable-targets=all.
gdb/ChangeLog:
2019-12-19 Christian Biesinger <cbiesinger@google.com>
* score-tdep.c (score7_analyze_prologue): Pass 2.0 instead of
2 to pow ().
Change-Id: Ib18e7e4749ddcbff0727b72a31198f8cb84d1993
On Solaris 11 with gcc 5.5.0 (gcc211 on the compile farm), math.h has a
using std::log10; directive. This is unfortunate because std::log10 has
overloads for float/double/long double. To disambiguate this call,
cast the argument to double to fix the build.
gdb/ChangeLog:
2019-12-19 Christian Biesinger <cbiesinger@google.com>
* tui/tui-source.c (tui_source_window::set_contents): Cast argument of
log10 to double to fix Solaris 11 with gcc 5.5.
Change-Id: I6c0c52e9c172b529c899a435d430e5916aeef69f
A Solaris system header has a #define for "sun". This renames
that variable to avoid the conflict, fixing a build error with
--enable-targets=all on Solaris.
gdb/ChangeLog:
2019-12-19 Christian Biesinger <cbiesinger@google.com>
* fbsd-tdep.c (fbsd_info_proc_files_entry): Rename local var
"sun" to "saddr_un".
Change-Id: I07a5cd801db1e28ccab8a473ebad74d7afe017c2
Christian pointed out that the new comment in field_kind is
un-grammatical. This fixes it.
gdb/ChangeLog
2019-12-19 Tom Tromey <tromey@adacore.com>
* ui-out.h (enum class field_kind): Fix comment.
Change-Id: I6608ff18e29f1af98a0ff77012afe28b3d4602f4
xml-support.c uses FOPEN_RT, but then reads the entire contents of the
file and verifies that the number of bytes read matches the length.
This can fail on Windows, where the read will translate line
terminators.
This patch fixes the bug by changing xml-support.c to use FOPEN_RB.
This works because expat correctly handles \r\n line terminators.
gdb/ChangeLog
2019-12-11 Tom Tromey <tromey@adacore.com>
* xml-support.c (xml_fetch_content_from_file): Use FOPEN_RB.
gdb/testsuite/ChangeLog
2019-12-11 Tom Tromey <tromey@adacore.com>
* gdb.xml/tdesc-arch.exp (set_arch): Add "trans_mode" parameter.
Add crlf test.
Change-Id: I548438f33eed284dde1de8babf755eaa1a40319d
Now that the version number in master has been bumped to 10, I get this
failure:
FAIL: gdb.base/default.exp: show convenience ($_gdb_major = 9 not found)
Update the test accordingly.
gdb/testsuite/ChangeLog:
* gdb.base/default.exp: Update value of $_gdb_major.
My earlier patch to fix the pthread_setname_np build error on macOS
was incorrect. While the macOS man page claims that
pthread_setname_np returns void, in <pthread.h> it is actually
declared returning "int". I knew this earlier, but must have made
some mistake when preparing the patch for submission (perhaps when
removing the templates?).
This patch re-fixes the bug. I'm also applying it to the 9.1 branch.
Tested by building on macOS High Sierra.
gdb/ChangeLog
2019-12-18 Tom Tromey <tromey@adacore.com>
PR build/25268:
* gdbsupport/thread-pool.c (set_thread_name): Expect "int" return
type on macOS. Add comment.
Change-Id: Ib09da6ac33958a0d843f65df2a528112356e7de6
I see this warning when building with clang:
CXX c-lang.o
/home/smarchi/src/binutils-gdb/gdb/c-lang.c:314:7: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
*length = i * width;
^
/home/smarchi/src/binutils-gdb/gdb/c-lang.c:308:4: note: previous statement is here
if (extract_unsigned_integer (contents + i * width,
^
It took me a while to notice that some lines in that area have a
spurious space before the tabs, at the beginning of the ling. I'm not
sure how clang translates that to misleading indentation, but making the
indentation correct gets rid of the error.
There are many more instances of this in the code base (`grep -P '^ \t'
*.c`), if others think it's a good idea, it would be pretty easy to fix
them all up in one shot.
gdb/ChangeLog:
* c-lang.c (c_get_string, asm_language_defn): Remove space
before tab.
PR build/25250 notes that the gdb 9 pre-release fails to build on
macOS, due to a name clash between field_kind::STRING and the STRING
token in ada-exp.y. I am not sure (I couldn't reproduce this myself),
but presumably this is due to differences caused by the version of
bison in use there.
This patch works around the problem by renaming the field_kind
enumerator. I chose to rename this one because it is used in
relatively few places -- it's just an implementation detail of the
style code.
This version also renames field_kind::SIGNED for consistency.
Let me know what you think. I intend to check this in on the gdb 9
branch as well.
gdb/ChangeLog
2019-12-18 Tom Tromey <tromey@adacore.com>
PR build/25250:
* ui-out.c (ui_out::vmessage): Update.
* ui-out.h (enum class field_kind) <FIELD_STRING, FIELD_SIGNED>:
Rename.
(string_field): Update.
(signed_field): Update.
Change-Id: Iae9f36f1b793e22c61fee0de2ab2d508668ee7e4
When building top.c with this clang (daily build from apt.llvm.org):
$ clang++-10 --version
clang version 10.0.0-+20191211091425+f99297176cd-1~exp1~20191211082036.1372
I get:
/home/smarchi/src/binutils-gdb/gdb/top.c:1549:5: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
fprintf_filtered (stream, _("\n\
^
/home/smarchi/src/binutils-gdb/gdb/top.c:1543:3: note: previous statement is here
if (SYSTEM_GDBINIT_DIR[0])
^
This looks like a legitimate warning, the fprintf_filtered is too much
indented. Fix it, and at the same time add a bit of whitespace to make
this function easier to read.
gdb/ChangeLog:
* top.c (print_gdb_configuration): Adjust indentation.
Commit ff8577f649 added a call to
gdb_abspath in bsd-kvm.c, but doesn't include its header file.
This commit fixes that.
gdb/ChangeLog:
2019-12-17 Christian Biesinger <cbiesinger@google.com>
* bsd-kvm.c: Include gdbsupport/pathstuff.h.
Change-Id: I647c3620d8ae978ae27c38dbe0b3347a97c5bfc2
I stumbled on some ASan failures when using the TUI, when tearing down a
TUI layout. The simplest way to trigger it is to run:
$ ./gdb --data-directory=data-directory -batch -ex "layout next"
The ASan report is:
=================================================================
==2829136==ERROR: AddressSanitizer: new-delete-type-mismatch on 0x608000009a20 in thread T0:
object passed to delete has wrong type:
size of the allocated type: 88 bytes;
size of the deallocated type: 24 bytes.
#0 0x7f470fe2507e in operator delete(void*, unsigned long) /build/gcc/src/gcc/libsanitizer/asan/asan_new_delete.cc:177
#1 0x55f88c75700d in std::default_delete<tui_layout_base>::operator()(tui_layout_base*) const /usr/include/c++/9.2.0/bits/unique_ptr.h:81
#2 0x55f88c756328 in std::unique_ptr<tui_layout_base, std::default_delete<tui_layout_base> >::~unique_ptr() /usr/include/c++/9.2.0/bits/unique_ptr.h:284
#3 0x7f470ee536a6 in __run_exit_handlers (/usr/lib/libc.so.6+0x3e6a6)
#4 0x7f470ee5385d in __GI_exit (/usr/lib/libc.so.6+0x3e85d)
#5 0x55f88c69f2ac in quit_force(int*, int) /home/simark/src/binutils-gdb/gdb/top.c:1766
#6 0x55f88becc29a in captured_main_1 /home/simark/src/binutils-gdb/gdb/main.c:1183
#7 0x55f88becc814 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1192
#8 0x55f88becc8a9 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1217
#9 0x55f88b3159cd in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
#10 0x7f470ee3c152 in __libc_start_main (/usr/lib/libc.so.6+0x27152)
#11 0x55f88b31579d in _start (/home/simark/build/binutils-gdb/gdb/gdb+0x11fb79d)
0x608000009a20 is located 0 bytes inside of 88-byte region [0x608000009a20,0x608000009a78)
allocated by thread T0 here:
#0 0x7f470fe238f8 in operator new(unsigned long) /build/gcc/src/gcc/libsanitizer/asan/asan_new_delete.cc:104
#1 0x55f88c750906 in tui_layout_split::clone() const /home/simark/src/binutils-gdb/gdb/tui/tui-layout.c:515
#2 0x55f88c74e60e in show_layout /home/simark/src/binutils-gdb/gdb/tui/tui-layout.c:90
#3 0x55f88c74e7db in tui_set_layout(tui_layout_type) /home/simark/src/binutils-gdb/gdb/tui/tui-layout.c:116
#4 0x55f88c782f4f in tui_enable() /home/simark/src/binutils-gdb/gdb/tui/tui.c:481
#5 0x55f88c74eeb2 in tui_layout_command /home/simark/src/binutils-gdb/gdb/tui/tui-layout.c:286
#6 0x55f88b6f969b in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:107
#7 0x55f88b701859 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1952
#8 0x55f88c69b455 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:652
#9 0x55f88bec9026 in catch_command_errors /home/simark/src/binutils-gdb/gdb/main.c:400
#10 0x55f88becc1f2 in captured_main_1 /home/simark/src/binutils-gdb/gdb/main.c:1167
#11 0x55f88becc814 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1192
#12 0x55f88becc8a9 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1217
#13 0x55f88b3159cd in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
#14 0x7f470ee3c152 in __libc_start_main (/usr/lib/libc.so.6+0x27152)
The problem is that the tui_layout_base is missing a virtual destructor.
We allocate a derived object (tui_layout_split), but delete it through a
tui_layout_base pointer. Since the tui_layout_base destructor is not
virtual, the derived (tui_layout_split) destructor is not called, only
the base destructor.
That code is not in gdb-9-branch, so I don't think this patch is
relevant for the stable branch.
Note that this is caught as a diagnostic with clang:
In file included from /home/simark/src/binutils-gdb/gdb/tui/tui-layout.c:22:
In file included from /home/simark/src/binutils-gdb/gdb/defs.h:28:
In file included from /home/simark/src/binutils-gdb/gdb/gdbsupport/common-defs.h:133:
In file included from /home/simark/src/binutils-gdb/gdb/gdbsupport/common-exceptions.h:25:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../include/c++/9.2.0/memory:80:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../include/c++/9.2.0/bits/unique_ptr.h:81:2: error: delete called on 'tui_layout_base' that is abstract but has non-virtual destructor [-Werror,-Wdelete-abstract-non-virtual-dtor]
delete __ptr;
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../include/c++/9.2.0/bits/unique_ptr.h:284:4: note: in instantiation of member function 'std::default_delete<tui_layout_base>::operator()' requested here
get_deleter()(std::move(__ptr));
^
/home/simark/src/binutils-gdb/gdb/tui/tui-layout.c:54:41: note: in instantiation of member function 'std::unique_ptr<tui_layout_base, std::default_delete<tui_layout_base> >::~unique_ptr' requested here
static std::unique_ptr<tui_layout_base> applied_layout;
^
1 error generated.
GCC has the similar -Wdelete-non-virtual-dtor, enabled by -Wall, but it
doesn't show up because warnings are inhibited for system headers, where
std::unique_ptr is defined. There is a bug about it here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876
gdb/ChangeLog:
* tui/tui-layout.h (class tui_layout_base): Add virtual
destructor.
We need to step a second time with this gcc version.
The first step jumps back to main before entering foo.
Previously the control flow was from bar directly to foo.
Further ananlysis suggests, that this change in behavior started
with gcc-8.1.0 when -gcolumn-info was enabled by default.
The option -gcolumn-info was first implemented in gcc-7.1.0 but
default-disabled, so you can get the altered behavior already with
gcc-7 if you manually enable -gcolumn-info.
Previously there was just one point where line 30 (of skip.c) started:
[0x00000032] Advance Line by 27 to 28
[0x00000034] Copy
[0x00000035] Special opcode 63: advance Address by 4 to 0x4004cb and Line by 2 to 30
[0x00000036] Advance PC by constant 17 to 0x4004dc
[0x00000037] Special opcode 7: advance Address by 0 to 0x4004dc and Line by 2 to 32
But with -gcolumn-info enabled, we have line 30 three times with different column:
[0x00000034] Advance Line by 27 to 28
[0x00000036] Copy
[0x00000037] Set column to 9
[0x00000039] Special opcode 63: advance Address by 4 to 0x4004c6 and Line by 2 to 30
[0x0000003a] Set column to 17
[0x0000003c] Special opcode 75: advance Address by 5 to 0x4004cb and Line by 0 to 30
[0x0000003d] Set column to 3
[0x0000003f] Special opcode 75: advance Address by 5 to 0x4004d0 and Line by 0 to 30
[0x00000040] Special opcode 105: advance Address by 7 to 0x4004d7 and Line by 2 to 32
That could probably be filtered in dwarf2read.c to keep the old behavior, but
the new behavior makes still sense, even if we cannot really make use of the
column in the line number info for now.
This makes the skip command work in optimized builds, where skipped
functions may be inlined. Previously that was only working when
stepping into a non-inlined function.
This patch changes the gdb_symtab::blocks manually maintained linked
list to be an std::forward_list, simplifying memory management.
Currently, the list is sorted as blocks are created. With an
std::forward_list, it is easier (and probably a bit more efficient) to
sort them once at the end, so this is what I did.
A note about the comment on the "next" field:
/* gdb_blocks are linked into a tree structure. Next points to the
next node at the same depth as this block and parent to the
parent gdb_block. */
I don't think it's true that "next" points to the next node at the same
depth. All nodes are in a simple singly linked list, so necessarily
some node will point to some other node that isn't at the same depth.
gdb/ChangeLog:
* jit.c (struct gdb_block) <next>: Remove field.
(struct gdb_symtab) <~gdb_symtab>: Remove.
<blocks>: Change type to std::forward_list<gdb_block>.
(compare_block): Remove.
(jit_block_open_impl): Adjust to std::forward_list. Place the new
block at the beginning, don't mind about sorting.
(finalize_symtab): Adjust to std::forward_list, sort the blocks list
before using it.
Add a constructor to gdb_block, change the name field to be a
gdb::unique_xmalloc_ptr. This is in preparation for using an
std::forward_list<gdb_block> in the next patch.
gdb/ChangeLog:
* jit.c (struct gdb_block): Add constructor, initialize
real_block and next fields.
<name>: Change type to gdb::unique_xmalloc_ptr.
(struct gdb_symtab) <~gdb_symtab>: Free blocks with delete.
(jit_block_open_impl): Allocate gdb_block with new.
(finalize_symtab): Adjust to gdb::unique_xmalloc_ptr.
Replace the manual linked list with an std::forward_list, simplifying
the memory management. This requires allocating gdb_object with new and
free'ing it with delete.
gdb/ChangeLog:
* jit.c: Include forward_list.
(struct gdb_symtab) <next>: Remove field.
(struct gdb_object) <symtabs>: Change type to
std::forward_list<gdb_symtab>.
(jit_object_open_impl): Allocate gdb_object with new.
(jit_symtab_open_impl): Adjust to std::forward_list.
(finalize_symtab): Don't delete symtab.
(jit_object_close_impl): Adjust to std::forward_list. Free
gdb_object with delete.
This patch makes the gdb_symtab bit more c++y, in preparation for the
next patch that will use an std::forward_list<gdb_symtab>. It changes
the fields to use automatic memory management, in the form of
std::string and gdb::unique_xmalloc_ptr, and adds a constructor and a
destructor.
gdb/ChangeLog:
* jit.c (struct gdb_symtab): Add constructor, destructor,
initialize fields.
<linetable>: Change type to unique_xmalloc_ptr.
<file_name>: Change type to std::string.
(jit_symtab_open_impl): Allocate gdb_symtab with new.
(jit_symtab_line_mapping_add_impl): Adjust.
(finalize_symtab): Adjust, call delete on stab.
A double-free happens when using a JIT debug info reader that creates
more than one block. In the loop that frees blocks in finalize_symtab,
at the very end, the gdb_block_iter_tmp variable is set initially, but
not changed as the loop advances. If we have two blocks, the first
iteration frees the first block, the second iteration frees the second
block, but the third iteration tries to free the second block again, as
gdb_block_iter_tmp keeps pointing on the second block.
Fix it by assigning the gdb_block_iter_tmp variable in the loop.
I have improved the jit-reader.exp test to cover this case, by adding a
second "JIT-ed" function and creating a block for it. I have renamed
the existing function to something I find a bit more descriptive. There
are no significant changes to jit-reader.exp itself, only updates
following the renaming. The important changes are in jithost.c
(generate a new function) and in jitreader.c (create a gdb_block for
that function).
This was found because of an ASan report:
$ ./gdb testsuite/outputs/gdb.base/jit-reader/jit-reader -ex "jit-reader-load /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/jit-reader/jitreader.so" -ex r
Reading symbols from testsuite/outputs/gdb.base/jit-reader/jit-reader...
Starting program: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/jit-reader/jit-reader
=================================================================
==1751048==ERROR: AddressSanitizer: heap-use-after-free on address 0x604000042eb8 at pc 0x5650ef8eec88 bp 0x7ffe52767290 sp 0x7ffe52767280
READ of size 8 at 0x604000042eb8 thread T0
#0 0x5650ef8eec87 in finalize_symtab /home/simark/src/binutils-gdb/gdb/jit.c:768
#1 0x5650ef8eef88 in jit_object_close_impl /home/simark/src/binutils-gdb/gdb/jit.c:797
#2 0x7fbbda986278 in read_debug_info /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jitreader.c:71
#3 0x5650ef8ef56b in jit_reader_try_read_symtab /home/simark/src/binutils-gdb/gdb/jit.c:850
#4 0x5650ef8effe3 in jit_register_code /home/simark/src/binutils-gdb/gdb/jit.c:948
#5 0x5650ef8f2c92 in jit_event_handler(gdbarch*) /home/simark/src/binutils-gdb/gdb/jit.c:1396
#6 0x5650ef0d137e in handle_jit_event /home/simark/src/binutils-gdb/gdb/breakpoint.c:5470
[snip]
0x604000042eb8 is located 40 bytes inside of 48-byte region [0x604000042e90,0x604000042ec0)
freed by thread T0 here:
#0 0x7fbbe57376b0 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:122
#1 0x5650ef8f350b in xfree<gdb_block> /home/simark/src/binutils-gdb/gdb/gdbsupport/common-utils.h:62
#2 0x5650ef8eeca9 in finalize_symtab /home/simark/src/binutils-gdb/gdb/jit.c:769
#3 0x5650ef8eef88 in jit_object_close_impl /home/simark/src/binutils-gdb/gdb/jit.c:797
#4 0x7fbbda986278 in read_debug_info /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jitreader.c:71
#5 0x5650ef8ef56b in jit_reader_try_read_symtab /home/simark/src/binutils-gdb/gdb/jit.c:850
#6 0x5650ef8effe3 in jit_register_code /home/simark/src/binutils-gdb/gdb/jit.c:948
#7 0x5650ef8f2c92 in jit_event_handler(gdbarch*) /home/simark/src/binutils-gdb/gdb/jit.c:1396
#8 0x5650ef0d137e in handle_jit_event /home/simark/src/binutils-gdb/gdb/breakpoint.c:5470
[snip]
previously allocated by thread T0 here:
#0 0x7fbbe5737cd8 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:153
#1 0x5650eef662f3 in xcalloc /home/simark/src/binutils-gdb/gdb/alloc.c:100
#2 0x5650ef8f34ea in xcnew<gdb_block> /home/simark/src/binutils-gdb/gdb/gdbsupport/poison.h:122
#3 0x5650ef8ed467 in jit_block_open_impl /home/simark/src/binutils-gdb/gdb/jit.c:557
#4 0x7fbbda98620a in read_debug_info /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jitreader.c:60
#5 0x5650ef8ef56b in jit_reader_try_read_symtab /home/simark/src/binutils-gdb/gdb/jit.c:850
#6 0x5650ef8effe3 in jit_register_code /home/simark/src/binutils-gdb/gdb/jit.c:948
#7 0x5650ef8f2c92 in jit_event_handler(gdbarch*) /home/simark/src/binutils-gdb/gdb/jit.c:1396
#8 0x5650ef0d137e in handle_jit_event /home/simark/src/binutils-gdb/gdb/breakpoint.c:5470
[snip]
gdb/ChangeLog:
* jit.c (finalize_symtab): Set gdb_block_iter_tmp in loop.
gdb/testsuite/ChangeLog:
* gdb.base/jit-reader.exp (jit_reader_test): Rename
jit_function_00 to jit_function_stack_mangle.
* gdb.base/jithost.c (jit_function_t): Rename to...
(jit_function_stack_mangle_t): ... this.
(jit_function_add_t): New typedef.
(jit_function_00_code): Rename to...
(jit_function_stack_mangle_code): ... this, make static.
(jit_function_add_code): New.
(main): Generate "add" function and call it. Adjust to changes
in jithost_abi.
* gdb.base/jithost.h (struct jithost_abi_bounds): New.
(struct jithost_abi) <begin, end>: Remove fields.
<object, function_stack_mangle, function_add>: New fields.
* gdb.base/jitreader.c (struct reader_state) <code_begin,
code_end>: Remove fields.
<func_stack_mangle>: New field.
(read_debug_info): Adjust to renaming, create block for "add"
function.
(read_sp, unwind_frame, get_frame_id): Adjust to other changes.
I noticed that get_exec_file could return a "const char *". This
patch implements this change.
I couldn't build all the code -- but I did build Linux native and a
mingw cross.
Consequently, the NTO code has a hack, where it casts away const. I
think this can be removed, but that required more work there, and
since I couldn't compile it, I felt it best not to try.
Let me know what you think.
gdb/ChangeLog
2019-12-16 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat_target::attach): Update.
* remote.c (extended_remote_target::attach): Update.
* procfs.c (procfs_target::attach): Update.
* nto-procfs.c (nto_procfs_target::attach): Update.
(nto_procfs_target::create_inferior): Update.
* inf-ptrace.c (inf_ptrace_target::attach): Update.
* gnu-nat.c (gnu_nat_target::attach): Update.
(gnu_nat_target::detach): Update.
* darwin-nat.c (darwin_nat_target::attach): Update.
* corefile.c (get_exec_file): Constify result. Remove extraneous
return.
* bsd-kvm.c (bsd_kvm_target_open): Update.
* gdbsupport/common-inferior.h (get_exec_file): Constify result.
gdb/gdbserver/ChangeLog
2019-12-16 Tom Tromey <tromey@adacore.com>
* server.c (get_exec_file): Constify result.
Change-Id: I29c60f7313a7def0dcb290ff0c2a4c1dea4f981f
This removes symbol_set_language and SYMBOL_SET_LANGUAGE in favor of
a new function general_symbol_info::set_language. symbol and minimal_symbol
already inherit from that struct so this works naturally.
gdb/ChangeLog:
2019-12-15 Christian Biesinger <cbiesinger@google.com>
* ada-exp.y (write_ambiguous_var): Update.
* coffread.c (process_coff_symbol): Update.
* ctfread.c (ctf_add_enum_member_cb): Update.
(new_symbol): Update.
* dwarf2read.c (fixup_go_packaging): Update.
(new_symbol): Update.
* language.c (language_alloc_type_symbol): Update.
* mdebugread.c (new_symbol): Update.
* minsyms.c (minimal_symbol_reader::record_full): Update.
* psymtab.c (add_psymbol_to_bcache): Update.
* stabsread.c (define_symbol): Update.
(read_enum_type): Update.
* symtab.c (symbol_set_language): Make this a member function...
(general_symbol_info::set_language): ... here.
* symtab.h (struct general_symbol_info) <set_language>: New function.
(SYMBOL_SET_LANGUAGE): Remove.
(symbol_set_language): Remove.
Change-Id: Ideafb6c384004b9adef793a1192735c501da41d5
Instead of using SYMBOL_LANGUAGE (sym) = foo.
Having only a single way to set a symbol's language is clearer and this
is also a requirement for making set_language a member function.
gdb/ChangeLog:
2019-12-15 Christian Biesinger <cbiesinger@google.com>
* ada-exp.y (write_ambiguous_var): Call symbol_set_language to
set the language of sym.
* language.c (language_alloc_type_symbol): Likewise.
Change-Id: I85338ea2e4121155f2da222fe0aa6b7d3ffe26f7
In this commit:
commit 086baaf134
Date: Tue Oct 15 16:18:26 2019 +0100
gdb/python: Introduce gdb.lookup_static_symbols
A duplicate description of gdb.lookup_global_symbol was accidentally
added. This commit corrects this mistake and removes the duplicate.
gdb/doc/ChangeLog:
* python.texi (Symbols In Python): Remove duplicate description of
gdb.lookup_global_symbol.
Change-Id: I4457b42cf05bde39e5c0ff39f168af919cad1255
Ref.: https://bugzilla.redhat.com/show_bug.cgi?id=1728147
Ref.: https://sourceware.org/bugzilla/show_bug.cgi?id=23613
Hi,
This bug has been reported against Fedora GDB, but there's also an
upstream bug. The problem reported is that GDB segfaults when the
working directory is deleted. It's pretty use to reproduce it:
mkdir bla
cd bla
rmdir ../bla
gdb echo
Debugging the problem is a bit tricky, because, since the current
directory doesn't exist anymore, a corefile cannot be saved there.
After a few attempts, I came up with the following:
gdb -ex 'shell mkdir bla' -ex 'cd bla' -ex 'shell rmdir ../bla' -ex 'r echo' ./gdb/gdb
This assumes that you're inside a build directory which contains
./gdb/gdb, of course.
After investigating it, I found that the problem happens at
gdb_abspath, where we're dereferencing 'current_directory' without
checking if it's NULL:
...
(concat (current_directory,
IS_DIR_SEPARATOR (current_directory[strlen (current_directory) - 1])
? "" : SLASH_STRING,
...
So I fixed the problem with the patch below. The idea is that, if
'current_directory' is NULL, then the final string returned should be
just the "path".
After fixing the bug, I found a similar one reported against our
bugzilla: PR gdb/23613. The problem is the same, but the reproducer
is a bit different.
I really tried writing a testcase for this, but unfortunately it's
apparently not possible to start GDB inside a non-existent directory
with DejaGNU.
I regression tested this patch on the BuildBot, and no regressions
were found.
gdb/ChangeLog:
2019-12-14 Sergio Durigan Junior <sergiodj@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1728147
PR gdb/23613
* bsd-kvm.c (bsd_kvm_target_open): Use 'gdb_abspath'.
* corelow.c: Include 'gdbsupport/pathstuff.h'.
(core_target_open): Use 'gdb_abspath'.
* gdbsupport/pathstuff.c (gdb_abspath): Guard against
'current_directory == NULL' case.
* gdbsupport/pathstuff.h (gdb_abspath): Expand comment and
explain what happens when 'current_directory' is NULL.
* go32-nat.c (go32_nat_target::wait): Check if
'current_directory' is NULL before call to 'chdir'.
* source.c (add_path): Use 'gdb_abspath'.
* top.c: Include 'gdbsupport/pathstuff.h'.
(init_history): Use 'gdb_abspath'.
(set_history_filename): Likewise.
* tracefile-tfile.c: Include 'gdbsupport/pathstuff.h'.
(tfile_target_open): Use 'gdb_abspath'.
Change-Id: Ibb0932fa25bc5c2d3ae4a7f64bd7f32885ca403b
This reverts commit 62e77f56f0.
(except for ChangeLog and a bugfix in minimal_symbol_reader::install)
As agreed on the mailing list, now that GDB 9 has branched, this patch
reverts the change to set worker-threads to zero. After this patch,
multithreaded minsym demangling will be enabled again by default.
gdb/ChangeLog:
2019-12-13 Christian Biesinger <cbiesinger@google.com>
* maint.c (n_worker_threads): Default to -1.
(worker_threads_disabled): Remove function.
* maint.h (worker_threads_disabled): Remove function.
* minsyms.c (minimal_symbol_reader::record_full): Don't call
symbol_set_names here if worker_threads_disabled () is true.
Change-Id: I5ff3e318d96f60968c8b8bedb84546ad2314d94b
ARI has a check for multiple calls to warning or error, suggesting
that they be combined into a single call. This triggers at three
places in gdb -- throw_bad_regnum_error, guile_repl_command, and the
end of value_cast -- and after examining these, I think they all make
sense as-is. Instead, it makes sense to remove this check from ARI.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh: Remove check for multiple calls to
warning or error.
Change-Id: I0618683623a3c7324460c7b9e5d7f252d88c2e8d
ARI has a "fix" call for "long long", but this call is incorrect.
This patch removes it.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh: Remove call to "fix" for "long long".
Change-Id: I97bca2dc04b579fcf7c9dba7fe7fd939451bcefa
This adds -Wno- support to ARI, so that warnings can be disabled
selectively. I use this to ignore "deprecated" warnings.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh: Handle -Wno- prefix.
Change-Id: I6919faedf920e857df4f597df66f0ba3943e0eac
This changes the ARI usage text to use the GNU style for
"metasyntactic variables".
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh (usage): Use GNU style.
Change-Id: Ibe5a867571382d2985d1b8b78dfef3ddd02291ff
A few spots can validly call vsprintf; this adds ARI markers to
suppress warnings at these places.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* gdbsupport/common-utils.c (string_printf, string_vprintf)
(string_vappendf): Add ARI comment.
Change-Id: Ia8665aa5d7b7331a3985b18626b19764a264447b
This silences ARI at the one spot that is permitted to call
floatformat_to_double, and also removes the corresponding "fix" call
from gdb_ari.sh -- it was incorrect, and now is not needed.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh: Remove "fix" call for
floatformat_to_double.
* target-float.c (host_float_ops<T>::from_target): Add ARI
comment.
Change-Id: I778a17a04da417c113194004dd7de3b1df381266
There are a handful of spots in gdb that validly call abort. This
patch adds the appropriate ARI marker to these lines, to silence the
ARI report. This also removes the "fix" call for "abort" from
gdb_ari.sh; it was incorrect and now is not needed.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh: Remove "fix" call for abort.
* utils.c (abort_with_message, dump_core, internal_vproblem): Add
ARI marker to abort.
* event-top.c (handle_sigsegv): Add ARI marker to abort.
Change-Id: I09ce6aa5010bbe4e5bb73ffdb727481be39d34d6
ARI reports the wrong substitution for floatformat_from_double.
"floatformat_from_doublest" was renamed in 2017.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh: Fix floatformat_from_double text.
Change-Id: Ibf1b194ea509b12ae8bc30ce285c809c96218557
The text for the ATTRIBUTE_UNUSED check in ARI is plainly incorrect
now -- gdb does in fact use ATTRIBUTE_UNUSED, and there's no issue in
doing so, when done properly.
This patch removes this check.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh: Remove ATTRIBUTE_UNUSED check.
Change-Id: I13fd8e9b40dbaab3978dbf9b6c4228b62299d944
The "boolean" and "var_boolean" checks from ARI seem only to generate
false reports.
Now that gdb is in C++, at least the "boolean" check seems unlikely to
ever generate a true report.
The "var_boolean" check likewise doesn't seem valuable any more --
presumably this refers to some ancient way of doing things in gdb, and
isn't likely to find a bug in the future.
Therefore, this patch removes these two checks.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh: Remove "boolean" and "var_boolean"
checks.
Change-Id: Iaf449b51e8182ffa0b9ed25fe688e0ff64a07a67
The Solaris buildbot builder complained about some recent patches of
mine. Building with GCC 7 failed.
This patch fixes the bug. I'm checking it in.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* gdbsupport/safe-iterator.h (class basic_safe_range) <begin,
end>: No longer "const".
Change-Id: I5f428fab61087f467ac3b6475f4ef4dbd314fcb0
Many places in this file use spaces only for indentation. Fix them to
conform to GNU style.
gdb/ChangeLog:
* jit.c: Fix indentation, replace spaces with tabs where
applicable.
This enables support for the msp430-elfbare target being added to GCC.
gdb/ChangeLog:
2019-12-13 Jozef Lawrynowicz <jozef.l@mittosystems.com>
* configure.tgt: Match msp430-*-elf* targets when configuring GDB.
A plan I had a while ago was to write the DWARF index in a worker
thread. This is why objfile::partial_symtabs is a shared_ptr.
However, it turned out that doing this required keeping the objfile
alive as well. Now that objfiles are managed using shared_ptr,
there's no need for partial_symtabs to be one as well, so this patch
reverts that change.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* objfiles.h (struct objfile) <partial_symtabs>: Now a
unique_ptr.
Change-Id: I3d7831006c40d4c8f3173ba51c0c1b0a32021ae5
This changes objfiles to be managed using a shared_ptr. shared_ptr is
chosen because it enables the use of objfiles in background threads.
The simplest way to do this was to introduce a new iterator that will
return the underlying objfile, rather than a shared_ptr. (I also
tried changing the rest of gdb to use shared_ptr, but this was quite
large; and to using intrusive reference counting, but this also was
tricky.)
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* progspace.h (objfile_list): New typedef.
(class unwrapping_objfile_iterator)
(struct unwrapping_objfile_range): Newl
(struct program_space) <objfiles_range>: Change type.
<objfiles>: Change return type.
<add_objfile>: Change type of "objfile" parameter.
<objfiles_list>: Now a list of shared_ptr.
* progspace.c (program_space::add_objfile): Change type of
"objfile". Update.
(program_space::remove_objfile): Update.
* objfiles.h (struct objfile) <~objfile>: Make public.
* objfiles.c (objfile::make): Update.
(objfile::unlink): Don't call delete.
Change-Id: I6fb7fbf06efb7cb7474c525908365863eae27eb3
This changes free_all_objfiles to be a method on program_space, in
line with the other changes to treat program_space as a container for
objfiles.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* symfile.c (symbol_file_clear): Update.
* progspace.h (struct program_space) <free_all_objfiles>: Declare
method.
* progspace.c (program_space::free_all_objfiles): New method.
* objfiles.h (free_all_objfiles): Don't declare.
* objfiles.c (free_all_objfiles): Move to program_space.
Change-Id: I908b549d2981b6005f7ca181fc0e6d24fc8b7b6f
This introduces the basic_safe_range class, which can be used to
create a basic_safe_iterator. This also changes basic_safe_iterator
in two ways.
First, it simplifies the constructor. This seemed unnecessarily
complicated to me, and keeping it this way would prevent the second
change...
... which is to add a second constructor for initializing the
one-past-the-end iterator that is stored in basic_safe_iterator.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* gdbsupport/safe-iterator.h (basic_safe_iterator): Simplify. Add
second constructor.
(basic_safe_range): New class.
Change-Id: Ib351ef6fd435129a5053c64e5561877e1459ab37
This removes the MULTI_OBJFILE_P macro in favor of a method on the
program space.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* progspace.c (program_space::multi_objfile_p): New method.
* printcmd.c (info_symbol_command): Update.
* maint.c (maintenance_translate_address): Update.
* objfiles.h (MULTI_OBJFILE_P): Remove.
* progspace.h (struct program_space) <multi_objfile_p>: New
method.
Change-Id: I2779e26ea8909078d63fea8f13bce94cab73948c
This introduces a new method, program_space::remove_objfile, and
changes the objfile destructor not to unlink an objfile from the
program space's list.
This is cleaner because, like the previous patch, it treats the
program space more like a container for objfiles. Also, this makes it
possible to keep an objfile alive even though it has been unlinked
from the program space's list, which is important for processing in a
worker thread.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* progspace.h (struct program_space) <remove_objfile>: Declare.
* progspace.c (program_space::remove_objfile): New method.
* objfiles.c (unlink_objfile): Remove.
(objfile::unlink): Call remove_objfile.
(objfile): Don't call unlink_objfile.
Change-Id: I22f768827723dce21886fae9b3664532c8349e68
This introduces a new method, program_space::add_objfile, that adds an
objfile to the program space's list of objfiles. It also changes the
obfile's constructor so that linking an objfile into this list is not
done here.
The former is an improvement because it makes more sense to treat the
program space as a container holding objfiles -- so manipulation of
the list belongs there.
The latter is not strictly needed, but seemed better both because it
is removing a global side effect from a constructor, and for symmetry
reasons, as a subsequent patch will remove unlinking from the
destructor.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* progspace.h (struct program_space) <add_objfile>: Declare
method.
* progspace.c (program_space::add_objfile): New method.
* objfiles.c (~objfile): Don't unlink objfile.
(put_objfile_before): Remove.
(add_separate_debug_objfile): Don't call put_objfile_before.
(objfile::make): Call add_objfile. Set new_objfiles_available on
the per-program-space data.
Change-Id: I93e8525dda631cb89dcc2046a5c51c7c9f34ccfd
The idea behind this is that, in the long run, some code will need to
be able to hold onto an objfile after it is unlinked from the program
space. In particular, this is needed for some functionality to be
moved to worker threads -- otherwise the objfile can be deleted while
still in use.
So, this makes ~objfile private, replacing it with an "unlink" method,
making it more obvious which operation is intended at the calling
points.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* symfile.c (syms_from_objfile_1): Use objfile_up.
(syms_from_objfile_1, remove_symbol_file_command): Call unlink
method.
(reread_symbols): Use objfile_up.
* solib.c (update_solib_list, reload_shared_libraries_1): Call
unlink method.
* objfiles.h (struct objfile) <~objfile>: Now private.
<unlink>: New method.
(struct objfile_deleter): New.
(objfile_up): New typedef.
* objfiles.c (objfile::unlink): New method.
(free_objfile_separate_debug, free_all_objfiles)
(objfile_purge_solibs): Use it.
* jit.c (jit_unregister_code): Remove.
(jit_inferior_exit_hook, jit_event_handler): Call unlink on
objfile.
* compile/compile-object-run.c (do_module_cleanup): Call unlink on
objfile.
* compile/compile-object-load.c (compile_object_load): Use
objfile_up.
Change-Id: I934bee70b26b8b24e1735828fb1e60fe8a05714f
This changes objfile::make to take a "parent" parameter, and makes
add_separate_debug_objfile static.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* symfile.c (symbol_file_add_with_addrs): Pass "parent" to
objfile::make.
* objfiles.h (struct objjfile) <make>: No longer inline.
(add_separate_debug_objfile): Don't declare.
* objfiles.c (add_separate_debug_objfile): Now static.
(objfile::make): Move from objfiles.h. Call
add_separate_debug_objfile. Add "parent" parameter.
Change-Id: I631f43bb71738dea6ae0697317bf8ef4a0db4617
This changes the objfile constructor to be private, changing the
callers to use a factory method. This isn't perhaps strictly needed
for the goal of this series -- changing the container model of
objfiles -- but is a nice symmetry.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* symfile.c (symbol_file_add_with_addrs): Use objfile::make.
* objfiles.h (struct objfile): Make constructor private.
<make>: New static method.
* jit.c (jit_object_close_impl): Update.
Change-Id: I42e07bc80a88cf3322ace94ffe869ae5788bcb29
I'm currently studying that code and noticed this manual memory
management, which could easily be replaced with a vector, so here it is.
gdb/ChangeLog:
* jit.c (jit_reader_try_read_symtab): Replace xmalloc/xfree with
gdb::byte_vector.
I noticed a couple of spots that call malloc_failure, but that don't
need to.
* In xml-support.c, "concat" uses xmalloc, so cannot return NULL.
* In utils.c, "buildargv" also uses xmalloc, so can only return NULL
if the argument is empty.
Tested by the buildbot.
gdb/ChangeLog
2019-12-12 Tom Tromey <tromey@adacore.com>
* xml-support.c (xml_fetch_content_from_file): Don't call
malloc_failure.
* utils.h (class gdb_argv): Remove malloc_failure comment.
* utils.c (gdb_argv::reset): Don't call malloc_failure.
Change-Id: I59483620deb6609ccf2f024d94a29113bb62d1a9
This adds Ravenscar support to gdb for RISC-V targets.
This was tested internally using AdaCore's test suite and qemu.
gdb/ChangeLog
2019-12-12 Tom Tromey <tromey@adacore.com>
* Makefile.in (ALL_TARGET_OBS): Add riscv-ravenscar-thread.o.
(HFILES_NO_SRCDIR): Add riscv-ravenscar-thread.h.
(ALLDEPFILES): Add riscv-ravenscar-thread.c.
* configure.tgt (riscv-*-*): Add riscv-ravenscar-thread.o.
* riscv-ravenscar-thread.c: New file.
* riscv-ravenscar-thread.h: New file.
* riscv-tdep.c (riscv_gdbarch_init): Call
register_riscv_ravenscar_ops.
Change-Id: Ic47a3b3cfbbe80c2c82a5f48d2e0481845cac8b0
A recent commit removed DIAGNOSTIC_IGNORE_UNUSED_FUNCTION, which was
used in thread-pool.c. This patch changes this code to use
ATTRIBUTE_UNUSED instead.
Tested by rebuilding.
gdb/ChangeLog
2019-12-12 Tom Tromey <tromey@adacore.com>
* gdbsupport/thread-pool.c (set_thread_name): Use
ATTRIBUTE_UNUSED.
Change-Id: I56d46eaac73690565d0e52db1791411567a918dd
Attempting to build GDB in Ubuntu 16.04.6 LTS on x86_64, I ran into warnings
that caused the build to fail:
binutils-gdb/gdb/gdbsupport/safe-strerror.c:44:1: error: ‘char* select_strerror_r(char*, char*)’ defined but not used [-Werror=unused-function] select_strerror_r (char *res, char *)
The diagnostic macro DIAGNOSTIC_IGNORE_UNUSED_FUNCTION seems to expand
correctly to its respective pragma, but this doesn't seem to have an effect on
the warning. I tried to use the pragma explicitly and got the same result.
ATTRIBUTE_UNUSED works fine in this case if you put it in both functions,
which should fix warnings for both gdb and gdbserver builds.
The compiler version is gcc (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609.
This is likely the result of PR64079 in GCC, which was fixed by commit
9e96f1e1b9731c4e1ef4fbbbf0997319973f0537.
To prevent other developers from attempting to use this macro, only to get
confused by it not working as expected, it seems better to not define this
particular macro.
gdb/ChangeLog:
2019-12-12 Luis Machado <luis.machado@linaro.org>
* gdbsupport/safe-strerror.c: Don't include diagnostics.h.
(select_strerror_r): Use ATTRIBUTE_UNUSED instead of the diagnostics
macros.
include/ChangeLog:
2019-12-12 Luis Machado <luis.machado@linaro.org>
* diagnostics.h (DIAGNOSTIC_IGNORE_UNUSED_FUNCTION). Remove
definitions.
Change-Id: Iad6123d61d76d111e3ef8d24aa8c60112304c749
Testing on another TUI series showed that some of the regexps in the
TUI test suite have been incorrect for a while. In particular, "|"
was meant literally in these tests, but was interpreted as pattern
alternation due to lack of quoting.
This patch fixes the bad tests. I am checking this in.
gdb/testsuite/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* gdb.tui/resize.exp: Fix regexp.
* gdb.tui/regs.exp: Fix regexps.
* gdb.tui/main.exp: Fix regexp.
Change-Id: Ib6661361171ac120bb92f4a8aec7efa4bcaa36b9
The "winheight" command resizes a specified window, resizing the other
windows in the layout to adapt. In the current code, this is done by
examining each possible layout separately. The new layout code has a
more general approach to handling this, and this patch simply removes
the old code in favor of a call into the new layout engine.
gdb/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_set_win_height_command): Call
tui_adjust_window_height.
(tui_adjust_win_heights, new_height_ok): Remove.
* tui/tui-layout.h (tui_adjust_window_height): Declare.
* tui/tui-layout.c (tui_adjust_window_height): New function.
Change-Id: I6bb681375a46adc8d29fd06f581deed4e078e78a
The TUI has separate code for each possible layout to handle the case
where the terminal window is resized. With the new layout code, this
can all be replaced with a call to tui_apply_current_layout, which
simply re-applies the current layout.
This results in some small differences in behavior when resizing, so
some tests are updated.
gdb/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_resize_all): Remove code, call
tui_apply_current_layout.
gdb/testsuite/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* gdb.tui/resize.exp: Update.
* gdb.tui/empty.exp (layouts): Update.
Change-Id: I3dc6c02a753d495d9ab5e8213d550a147198ce6f
This patch introduces the first use of tui_layout, by changing
show_layout to clone and use the appropriate tui_layout.
This resulted in one minor layout change, and also in the unintended
-- but good -- side effect that the title of each boxed window is now
visible.
gdb/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* tui/tui-layout.h (tui_apply_current_layout): Declare.
* tui/tui-layout.c (standard_layouts, applied_layout): New
globals.
(tui_apply_current_layout): New function.
(show_layout): Set applied_layout. Call
tui_apply_current_layout.
(show_source_command, show_disasm_command)
(show_source_disasm_command, show_data)
(show_source_or_disasm_and_command): Remove.
(initialize_layouts): New function.
(_initialize_tui_layout): Call initialize_layouts.
gdb/testsuite/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* gdb.tui/regs.exp: Update.
* gdb.tui/empty.exp (layouts): Update.
* gdb.tui/basic.exp: Update.
* lib/tuiterm.exp (_check_box): Don't check bottom border.
Change-Id: If1ee06ee58f4803e8c213f4ab0f5bb59f4650ec2
This introduces a new approach to window layout for the TUI. The idea
behind this code is that a layout should be specified in a declarative
way, and then be applied by generic code that does not need to know
the specifics of every possible layout.
This patch itself does not change any behavior, because the new layout
engine isn't yet connected to anything. That is, this merely
introduces the implementation.
This generic approach makes the code more maintainable. It also
enables some future changes:
* New window types are simpler to add;
* User-specified layouts are possible; and
* Horizontal layouts are more attainable
gdb/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* tui/tui-layout.h (class tui_layout_base)
(class tui_layout_window, class tui_layout_split): New.
* tui/tui-layout.c (tui_get_window_by_name)
(tui_layout_window::clone, tui_layout_window::apply)
(tui_layout_window::get_sizes, tui_layout_window::add_split)
(tui_layout_split::add_window, tui_layout_split::clone)
(tui_layout_split::get_sizes)
(tui_layout_split::set_weights_from_heights)
(tui_layout_split::adjust_size, tui_layout_split::apply): New
functions.
(tui_layout_split::add_split, tui_layout_split::add_split)
(tui_layout_split::set_weights_from_heights)
(tui_layout_split::set_weights_from_heights): New functions.
Change-Id: I3a4cae666327b617d862aaa356f8179f945c6a4e
struct tui_point does not help very much. It is only used for
storage, and never passed between functions. I think it makes the
code more verbose without any corresponding benefit, so this patch
removes it.
gdb/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* tui/tui-wingeneral.c (tui_gen_win_info::make_window): Update.
* tui/tui-win.c (tui_adjust_win_heights, tui_resize_all): Update.
* tui/tui-layout.c (tui_gen_win_info::resize): Update.
* tui/tui-data.h (struct tui_point): Remove.
(struct tui_gen_win_info) <origin>: Remove.
<x, y>: New fields.
* tui/tui-command.c (tui_cmd_window::resize): Update.
Change-Id: I3f77920585b9ea9e2b4b189f3f3ae32d4da0c252
This introduces a new method, tui_gen_win_info::min_height, to fetch
the minimum height of a window. This is used in the subsequent
unified layout patch.
gdb/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* tui/tui-stack.h (struct tui_locator_window) <min_height>:
Implement.
* tui/tui-regs.h (struct tui_data_item_window) <min_height>:
Implement.
* tui/tui-data.h (struct tui_gen_win_info) <min_height>: New
method.
(struct tui_win_info) <min_height>: Implement.
Change-Id: Id33baffdf041fde072e15c1ff89b75f8b8118adb
This moves the can_box method to tui_gen_win_info, so that it will be
available on the tui_locator_window class. This will be used in a
subsequent patch.
gdb/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* tui/tui-data.h (struct tui_gen_win_info) <can_box>: New method.
(struct tui_win_info) <can_box>: Update.
Change-Id: Idfa58af41341607932d3c39415f6a35ee9b5d3dc
This moves the max_height method to tui_gen_win_info and implements it
in the subclasses. This is used by a subsequent patch, which will
normalize window layout across all window types.
gdb/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* tui/tui-stack.h (struct tui_locator_window) <max_height>: New
method.
* tui/tui-regs.h (struct tui_data_item_window) <max_height>: New
method.
* tui/tui-data.h (struct tui_gen_win_info) <max_height>: New
method.
(struct tui_win_info) <max_height>: Now override.
Change-Id: I4ba3e8899bc4668328d3d78e3c1674c61882450d
Now that the GDB 9 branch has been created, we can
bump the version number.
gdb/ChangeLog:
GDB 9 branch created (27f7b2f640):
* version.in: Bump version to 10.0.50.DATE-git.
PR build/25268 points out that the build fails on macOS, because on
macOS the "pthread_setname_np" function takes a single argument.
This patch fixes the problem, by introducing a new adapter function
that handles both styles of pthread_setname_np.
This change also meant moving the pthread_setname_np call to the
thread function, because macOS only permits setting the name of the
current thread. This means that there can be a brief window when gdb
will see the wrong name; but I think this is a minor concern.
Tested by rebuilding on x86-64 Fedora 30, and on macOS High Sierra.
On Linux I also debugged gdb to ensure that the thread names are still
set correctly.
gdb/ChangeLog
2019-12-11 Tom Tromey <tromey@adacore.com>
PR build/25268:
* gdbsupport/thread-pool.c (set_thread_name): New function.
(thread_pool::set_thread_count): Don't call pthread_setname_np.
(thread_pool::thread_function): Call set_thread_name.
Change-Id: Id7bf28d99ca27a893a9fc87ebb90b15a9c2a9cb4
A recent commit changed bfd_get_signed_8 to extend the result to a
bfd_signed_vma. This caused a compiler error in one spot in my
--enable-targets=all gdb build, where the result of bfd_get_signed_8
was passed to printf.
This patch fixes the build. Tested by rebuilding.
gdb/ChangeLog
2019-12-11 Tom Tromey <tromey@adacore.com>
* fbsd-tdep.c (fbsd_core_info_proc_status): Cast result of
bfd_get_signed_8.
Change-Id: Ic015f5fd3d88da6b5da8f7b4e1d11d5c981333db
The option framework documentation was speaking about a 'print -raw'
option, but this option does not exist.
This patch implements -raw-values option that tells to ignore the
active pretty printers when printing a value.
As we already have -raw-frame-arguments, I thought -raw-values
was more clear, in particular to differentiate
set print raw-values and set print raw-frame-arguments.
gdb/doc/ChangeLog
2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.texinfo (Command Options): Use -p and -pretty in the example,
as -r is ambiguous. Update the print - TAB TAB completion result.
(Data): Document new option -raw-values. Use -p and -pretty in the
example, as -r is ambiguous.
(Print Settings): Document set print raw values.
(Pretty-Printer Commands): Document interaction between enabled
pretty printers and -raw-values/-raw-frame-arguments.
gdb/ChangeLog
2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* NEWS: Document -raw-values option and the related setting commands.
* printcmd.c (print_command_parse_format): Do not set opts->raw off,
only set it on when /r is given.
* valprint.c (value_print_option_defs): New element raw-values.
* Makefile.in: Add the new file.
gdb/testsuite/ChangeLog
2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/options.exp: Add -raw-values in the print completion list.
* gdb.python/py-prettyprint.exp: Add tests for -raw-values.
I noticed that an example in the gdb.prompt documentation used the
wrong kind of quotes -- because it is code, it should use a plain
ASCII quotation mark. I also slightly shortened the sample text here,
so it would more clearly fit on a single line.
gdb/doc/ChangeLog
2019-12-10 Tom Tromey <tom@tromey.com>
* python.texi (gdb.prompt): Use correct quotes in example.
Shorten sample text.
Change-Id: I4153928c0d88001244ad410f3943c952a6ebfeb1
Add tests which check for accessibility of variables from within
various OpenMP parallel regions.
Tested on Fedora 27, 28, 29, 30, and 31. I also tested with my OpenMP
work on Fedora 30. The test has been annotated with setup_xfail and
setup_kfail statements so that there are no unexpected failures on any
of these platforms when using gcc. Better still, for my own testing
anyway, is that there are also no XPASSes or KPASSes either. So,
regardless of platform, when using gcc, and regardless of whether my
(not yet public) OpenMP work is used, seeing a FAIL indicates a real
problem.
Fedora 27 results:
# of expected passes 85
# of expected failures 65
(Note: I have not retested F27 since v1 of the patch; it's possible
that the numbers will be slightly different for v2.)
Fedora 28, 29, 30 results:
# of expected passes 131
# of expected failures 4
# of known failures 16
Fedora 30, 31 results w/ my OpenMP work:
# of expected passes 151
The above results all use gcc, either the system gcc or a development
gcc (when testing against my OpenMP work in GDB). I've also tested
with clang 9.0.0 and icc 19.0.5.281 20190815 on Fedora 31.
Fedora 31, clang:
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print s3
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print i1
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print i3
FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print s3
FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print i1
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i02
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i11
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i12
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i22
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: second thread: print i11
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: second thread: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: after parallel: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 2nd stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 2nd stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print j
Fedora 31, icc:
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i12
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i22
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print j
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print j
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print z
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print j
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print j
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print z
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print k
For both clang and icc, it turns out that there are some problems with
the DWARF that these compilers generate. Of the two, icc does at
least nest the subprogram of the outlined function representing the
parallel region within the function that it's defined, but does not
handle inner scopes if they exist. clang places the subprogram for
the outlined function at the same level as the containing function, so
variables declared within the function aren't visible at all.
I could call setup_xfail to avoid FAILs for clang and icc also, but I don't
want to further complicate the test.
gdb/testsuite/ChangeLog:
* gdb.threads/omp-par-scope.c: New file.
* gdb/threads/omp-par-scope.exp: New file.
Change-Id: Icb9c991730d84ca7509380af817dfcc778e764ea
This commit adds the gdb_caching_proc, support_nested_function_tests,
to lib/gdb.exp. It tests to see whether or not the C compiler has
support for nested function calls.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (support_nested_function_tests): New proc.
Change-Id: Ic2c93bc4cc200e07e104a2398f89a9c0514bdc75
We only ever use one of the two overloads, so to avoid breaking -Werror
builds, supress the warning.
gdb/ChangeLog:
2019-12-10 Christian Biesinger <cbiesinger@google.com>
* gdbsupport/safe-strerror.c: Supress the unused function warning
for select_strerror_r.
Change-Id: I344869a382bb36fe181b5b2a31838d1d20f58169
To do that, this patch makes IPA compile safe-strerror as well. Because
it doesn't use Gnulib, it calls the Glibc version of strerror_r directly.
Consequently this patch also removes the configure checks for strerror.
gdb/ChangeLog:
2019-12-10 Christian Biesinger <cbiesinger@google.com>
* config.in: Regenerate.
* configure: Regenerate.
* gdbsupport/agent.c (gdb_connect_sync_socket): Call
safe_strerror instead of strerror.
* gdbsupport/common.m4: Don't check for strerror.
* gdbsupport/safe-strerror.c: Support both the glibc version
of strerror_r and the XSI version.
gdb/gdbserver/ChangeLog:
2019-12-10 Christian Biesinger <cbiesinger@google.com>
* Makefile.in: Add safe-strerror.c to gdbreplay and IPA, and change
UNDO_GNULIB_CFLAGS to undo strerror_r instead of strerror.
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Don't check for strerror.
* linux-i386-ipa.c (initialize_fast_tracepoint_trampoline_buffer):
Call safe_strerror instead of strerror.
* server.h (strerror): Remove this now-unnecessary declaration.
* tracepoint.c (init_named_socket): Call safe_strerror instead of
strerror.
(gdb_agent_helper_thread): Likewise.
* utils.c (perror_with_name): Likewise.
Change-Id: I74848f072dcde75cb55c435ef9398dc8f958cd73
Sometimes -- notably with unchecked unions -- the Ada "ptype" code
will print a "?" or "??" to indicate something unknown. The choice of
what was printed was somewhat arbitrary, and in one case, Ada would
print an empty string rather than "?".
This patch normalizes the Ada code to use "?" rather than an empty
string or "??". My reasoning here is that a single question mark is
enough to convey unknown-ness.
gdb/ChangeLog
2019-12-10 Tom Tromey <tromey@adacore.com>
* ada-typeprint.c (print_choices): Use a single "?".
(print_variant_part): Print "?" if the discriminant name
is not known.
gdb/testsuite/ChangeLog
2019-12-10 Tom Tromey <tromey@adacore.com>
* gdb.ada/unchecked_union.exp: New file.
* gdb.ada/unchecked_union/pck.adb: New file.
* gdb.ada/unchecked_union/pck.ads: New file.
* gdb.ada/unchecked_union/unchecked_union.adb: New file.
* gdb-utils.exp (string_to_regexp): Also quote "?".
Change-Id: I3403040780a155ffa2c44c8e6a04ba86bc810e29
The documentation for make-breakpoint from the Guile API and the `spec'
variant of the gdb.Breakpoint constructor from the Python API state that
the format acceptable for location strings is the same as that accepted
by the break command. However, using the -probe qualifier at the
beginning of the location string causes a GDB internal error as it
attempts to decode a probe location in the wrong code path. Without this
functionality, there doesn't appear to be another way to set breakpoints
on probe points from Python or Guile scripts.
This patch introduces a new helper function that returns a
breakpoint_ops instance appropriate for a parsed location and updates
the Guile and Python bindings to use said function, rather than the
current hard-coded use of bkpt_breakpoint_ops. Since this logic is
duplicated in the handling of the `break' and `trace' commands, those
are also updated to call into the new helper function.
gdb/ChangeLog:
2019-12-10 George Barrett <bob@bob131.so>
Fix scripted probe breakpoints.
* breakpoint.c (tracepoint_probe_breakpoint_ops): Move
declaration forward.
(breakpoint_ops_for_event_location_type)
(breakpoint_ops_for_event_location): Add function definitions.
(break_command_1, trace_command): Use
breakpoint_ops_for_event_location.
* breakpoint.h (breakpoint_ops_for_event_location): Add function
declarations.
* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Use
breakpoint_ops_for_event_location.
* python/py-breakpoint.c (bppy_init): Use
breakpoint_ops_for_event_location.
gdb/testsuite/ChangeLog:
2019-12-10 George Barrett <bob@bob131.so>
Test scripted probe breakpoints.
* gdb.guile/scm-breakpoint.c (main): Add probe point.
* gdb.python/py-breakpoint.c (main): Likewise.
* gdb.guile/scm-breakpoint.exp (test_bkpt_probe): Add probe
specifier test.
* gdb.python/py-breakpoint.exp (test_bkpt_probe): Likewise.
Passing an lvalue argument to a function that takes an rvalue parameter
is not allowed per C++ rules. Consider this function:
int g (int &&x) { return x; }
Calling g as in
int i = 5;
int j = g (i);
is illegal. For instance, GCC 9.2.1 yields
~~~
test.cpp: In function ‘int main()’:
test.cpp:6:14: error: cannot bind rvalue reference of type ‘int&&’ to
lvalue of type ‘int’
6 | int j = g (i);
| ^
~~~
GDB currently allows this function call:
~~~
(gdb) print g(i)
$1 = 5
~~~
Fix this by ranking an lvalue argument incompatible with an rvalue
parameter. The behavior after this patch is:
~~~
(gdb) print g(i)
Cannot resolve function g to any overloaded instance
~~~
Tested with GCC 9.2.1.
gdb/ChangeLog:
2019-12-09 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdbtypes.c (rank_one_type): Return INCOMPATIBLE_TYPE_BADNESS
when ranking an lvalue argument for an rvalue parameter.
gdb/testsuite/ChangeLog:
2019-12-09 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.cp/rvalue-ref-overload.cc (g): New function that takes
an rvalue parameter.
* gdb.cp/rvalue-ref-overload.exp: Test calling it with an lvalue
parameter.
Change-Id: I4a6dfc7dac63efa1e3b9f8f391e4b736fbdccdc1
Extend the output pattern in mi-fortran-modules.exp to skip some
system modules that appear with versions of GFortran after 7.x.x.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-fortran-modules.exp: Add patterns to skip system
modules.
Change-Id: I64aaa395e554a32e8267ffa096faee53c19c0b9e
In some cases the Fortran stride information generated by GCC is wrong
with versions of GCC after 7.x.x. This commit adds kfails for the
tests in question with known bad versions of gcc.
The bug has been reported to GCC here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92775
gdb/testsuite/ChangeLog:
* gdb.fortran/derived-type-striding.exp: KFAIL if we are using a
broken version of GCC.
Change-Id: Iaef08e5e2c87ab3d6983b88f749d40e01aea2bc6
The gdb.fortran/info-modules.exp and gdb.fortran/info-types.exp tests
are failing on versions of gfortran after 7.3 due to the inclusion of
extra "system" modules and type that were not being matched by the
current test patterns.
Rather than building increasingly complex patterns that would always
be at risk of breaking with future versions of GCC I have instead
added a new library that parses the output of the following commands:
info types
info variables
info functions
info modules
info module functions
info module variables
into a data structure, the test can than run checks against the
contents of this data structure.
The benefit is that we can simply ignore extra results that we don't
care about.
There is a small risk that a bug in GDB might allow us to start
reporting incorrect results in such a way that the new library will
not spot the error. However, I have tried to mitigate this risk by
adding extra procedures into the test library (see check_no_entry) and
we can add more in future if we wanted to be even more defensive.
I tested this test file with gFortran 7.3.1, 8.3.0, and 9.2.0, I now
see 100% pass in all cases.
gdb/testsuite/ChangeLog:
* gdb.fortran/info-modules.exp: Rewrite to make use of new
sym-info-cmds library.
* gdb.fortran/info-types.exp: Likewise.
* lib/sym-info-cmds.exp: New file.
Change-Id: Iff81624f51b5afb6c95393932f3d94472d7c2970
This should be the type of startup_with_shell, whose type was changed
from int to bool at commit 80fd28264.
This fixes the build on macOS:
CXX darwin-nat.o
In file included from ../../gdb/darwin-nat.c:22:
In file included from ../../gdb/top.h:25:
In file included from ../../gdb/value.h:23:
In file included from ../../gdb/frame.h:72:
In file included from ../../gdb/language.h:26:
In file included from ../../gdb/symtab.h:33:
../../gdb/gdbsupport/gdb_optional.h:155:19: error: no matching constructor for initialization of 'scoped_restore_tmpl<int>'
new (&m_item) T (std::forward<Args>(args)...);
^ ~~~~~~~~~~~~~~~~~~~~~~~~
../../gdb/darwin-nat.c:1995:31: note: in instantiation of function template specialization 'gdb::optional<scoped_restore_tmpl<int> >::emplace<bool *, int>' requested here
restore_startup_with_shell.emplace (&startup_with_shell, 0);
^
../../gdb/gdbsupport/scoped_restore.h:69:3: note: candidate constructor template not viable: no known conversion from 'bool *' to 'int *' for 1st argument
scoped_restore_tmpl (T *var, T2 value)
^
../../gdb/gdbsupport/scoped_restore.h:57:3: note: candidate constructor not viable: requires single argument 'var', but 2 arguments were provided
scoped_restore_tmpl (T *var)
^
../../gdb/gdbsupport/scoped_restore.h:76:3: note: candidate constructor not viable: requires single argument 'other', but 2 arguments were provided
scoped_restore_tmpl (const scoped_restore_tmpl<T> &other)
^
1 error generated.
gdb/ChangeLog
2019-12-08 Wataru Ashihara <wataash@wataash.com>
* darwin-nat.c (darwin_nat_target::create_inferior): Fix
template argument for scoped_restore_tmpl from bool to int.
Change-Id: Ia0202efd34dbce69b6af5d035fa55ed89215138a
When running the gdb testsuite with the cc-with-dwz board, I run into:
...
Running gdb/testsuite/gdb.dwarf2/imported-unit.exp ...
gdb compile failed, dwz: gdb.dwarf2/imported-unit/imported-unit: \
Couldn't find DIE referenced by DW_AT_abstract_origin
cc-with-tweaks.sh: dwz did not modify gdb.dwarf2/imported-unit/imported-unit.
...
The problem is that the DW_AT_abstract_origin reference here:
...
<0><d2>: Abbrev Number: 2 (DW_TAG_compile_unit)
<1><e6>: Abbrev Number: 4 (DW_TAG_subprogram)
<e7> DW_AT_abstract_origin: <0x142>
<eb> DW_AT_low_pc : 0x4004b2
<f3> DW_AT_high_pc : 0x4004c8
...
referring to a DIE in another compilation unit here:
...
<0><129>: Abbrev Number: 2 (DW_TAG_compile_unit)
<1><142>: Abbrev Number: 4 (DW_TAG_subprogram)
<143> DW_AT_name : main
<148> DW_AT_type : <0x13b>
<14c> DW_AT_external : 1
...
is encoded using intra-CU reference form DW_FORM_ref4 instead of intra-CU
reference DW_FORM_ref_addr:
...
4 DW_TAG_subprogram [has children]
DW_AT_abstract_origin DW_FORM_ref4
DW_AT_low_pc DW_FORM_addr
DW_AT_high_pc DW_FORM_addr
DW_AT value: 0 DW_FORM value: 0
...
Fix this in the DWARF assembler by making all inter-CU references use the '%'
label prefix.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-12-08 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/imported-unit.exp: Fix inter-CU references.
Change-Id: I690ff18c3943705ed478453531b176ff74700f3c
This patch uses new BFD support for detecting build-ids in core
files.
After this patch, it is possible to run gdb with only the
core file, and gdb will automatically load the executable and
debug info [example from tests]:
$ gdb -nx -q
(gdb) core-file corefile-buildid.core
[New LWP 29471]
Reading symbols from gdb.base/corefile-buildid/debugdir-exec/.build-id/36/fe5722c5a7ca3ac746a84e223c6a2a69193a24...
Core was generated by `outputs/gdb.base/coref'.
Program terminated with signal SIGABRT, Aborted.
(gdb)
This work is based on functionality available in Fedora originally
written by Jan Kratochvil.
Regression tested on buildbot.
gdb/ChangeLog:
2019-12-07 Keith Seitz <keiths@redhat.com>
* build-id.c (build_id_bfd_get): Permit bfd_core, too.
(build_id_to_debug_bfd): Make static, rewriting to use
build_id_to_bfd_suffix.
(build_id_to_bfd_suffix): Copy of build_id_to_debug_bfd,
adding `suffix' parameter. Append SUFFIX to file names
when searching for matching files.
(build_id_to_debug_bfd): Use build_id_to_bfd_suffix.
(build_id_to_exec_bfd): Likewise.
* build-id.h (build_id_to_debug_bfd): Clarify that function
searches for BFD of debug info file.
(build_id_to_exec_bfd): Declare.
* corelow.c: Include build-id.h.
(locate_exec_from_corefile_build_id): New function.
(core_target_open): If no executable BFD is found,
search for a core file BFD using build-id.
gdb/testsuite/ChangeLog:
2019-12-07 Keith Seitz <keiths@redhat.com>
* gdb.base/corefile-buildid-shlib-shr.c: New file.
* gdb.base/corefile-buildid-shlib.c: New file.
* gdb.base/corefile-buildid.c: New file.
* gdb.base/corefile-buildid.exp: New file.
Change-Id: I15e9e8e58f10c68b5cae55e2eba58df1e8aef529
This avoids a conflict with a system "struct bcache" on
Solaris (see e.g.
https://www.isi.edu/nsnam/archive/ns-users/webarch/2001/msg05393.html)
Note that the Solaris conflict for now only surfaces with
--enable-targets=all (which the build bot doesn't use).
gdb/ChangeLog:
2019-12-06 Christian Biesinger <cbiesinger@google.com>
* bcache.c: Put in namespace gdb.
* bcache.h: Likewise.
* gdbtypes.c (check_types_worklist): Update.
(types_deeply_equal): Update.
* macrotab.c (struct macro_table) <bcache>: Update.
(new_macro_table): Update.
* macrotab.h (struct bcache): Put this forward declaration
inside namespace gdb.
(new_macro_table): Update.
* objfiles.h (struct objfile_per_bfd_storage) <filename_cache>:
Update.
<macro_cache>: Update.
* psymtab.h: (psymtab_storage) <psymbol_cache>: Update.
Change-Id: I843d5e91f7ccb3db6d1099a8214c15a74510256f
Consider the DWARF as generated by gcc with the tentative patch to fix gcc
PR91507 - "wrong debug for completed array with previous incomplete
declaration":
...
<1><f4>: Abbrev Number: 2 (DW_TAG_array_type)
<f5> DW_AT_type : <0xff>
<f9> DW_AT_sibling : <0xff>
<2><fd>: Abbrev Number: 3 (DW_TAG_subrange_type)
<2><fe>: Abbrev Number: 0
<1><ff>: Abbrev Number: 4 (DW_TAG_pointer_type)
<100> DW_AT_byte_size : 8
<101> DW_AT_type : <0x105>
<1><105>: Abbrev Number: 5 (DW_TAG_base_type)
<106> DW_AT_byte_size : 1
<107> DW_AT_encoding : 6 (signed char)
<108> DW_AT_name : (indirect string, offset: 0x19f): char
<1><10c>: Abbrev Number: 6 (DW_TAG_variable)
<10d> DW_AT_name : zzz
<111> DW_AT_decl_file : 1
<112> DW_AT_decl_line : 1
<113> DW_AT_decl_column : 14
<114> DW_AT_type : <0xf4>
<118> DW_AT_external : 1
<118> DW_AT_declaration : 1
<1><118>: Abbrev Number: 2 (DW_TAG_array_type)
<119> DW_AT_type : <0xff>
<11d> DW_AT_sibling : <0x128>
<1><12f>: Abbrev Number: 8 (DW_TAG_variable)
<130> DW_AT_specification: <0x10c>
<134> DW_AT_decl_line : 2
<135> DW_AT_decl_column : 7
<136> DW_AT_type : <0x118>
<13a> DW_AT_location : 9 byte block: 3 30 10 60 0 0 0 0 0 (DW_OP_addr: 601030)
...
The DWARF will result in two entries in the symbol table, a decl with type
char *[] and a def with type char*[2].
When trying to print the value of zzz:
...
$ gdb a.spec.out -batch -ex "p zzz"
...
the decl (rather than the def) will be found in the symbol table, which is
missing the location information, and consequently we get:
...
$1 = 0x601030 <zzz>
...
[ There is a fallback mechanism that finds the address of the variable in the
minimal symbol table, but that's not used here, because the type of the decl
does not specify a size. We could use the symbol size here to get the size
of the type, but that's currently not done: PR exp/24989. Still, fixing that
PR would not fix the generic case, where minimal symbol info is not
available. ]
Fix this by preferring defs over decls when searching in the symbol table.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2019-12-06 Tom de Vries <tdevries@suse.de>
PR symtab/24971
* block.c (best_symbol, better_symbol): New function.
(block_lookup_symbol_primary, block_lookup_symbol): Prefer def over
decl.
gdb/testsuite/ChangeLog:
2019-12-06 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/varval.exp: Add decl before def test.
Change-Id: Id92326cb8ef9903b121ef9e320658eb565d0f5a9
Simplify the expected test outputs. This is a minor cleanup; no
functional change is intended.
gdb/testsuite/ChangeLog:
2019-12-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.cp/rvalue-ref-overload.exp: Minor cleanup.
Change-Id: Ie760a2856cae3be0eeed5496765a5f1cd102d6b7
The overload resolution mechanism assigns badness values to the
necessary conversions to be made on types to pick a champion. A
badness value consists of a "rank" that scores the conversion and a
"subrank" to differentiate conversions of the same kind.
An auxiliary function, 'sum_ranks', is used for adding two badness
values. In all of its uses, except two, 'sum_ranks' is used for
populating the subrank of a badness value. The two exceptions are in
'rank_one_type':
~~~
/* See through references, since we can almost make non-references
references. */
if (TYPE_IS_REFERENCE (arg))
return (sum_ranks (rank_one_type (parm, TYPE_TARGET_TYPE (arg), NULL),
REFERENCE_CONVERSION_BADNESS));
if (TYPE_IS_REFERENCE (parm))
return (sum_ranks (rank_one_type (TYPE_TARGET_TYPE (parm), arg, NULL),
REFERENCE_CONVERSION_BADNESS));
~~~
Here, the result of a recursive call is combined with
REFERENCE_CONVERSION_BADNESS. This leads to the problem of
over-punishment by combining two ranks. Consider this:
void an_overloaded_function (const foo &);
void an_overloaded_function (const foo &&);
...
foo arg;
an_overloaded_function(arg);
When ranking 'an_overloaded_function (const foo &)', the badness
values REFERENCE_CONVERSION_BADNESS and CV_CONVERSION_BADNESS are
combined, whereas 'rank_one_type' assigns only the
REFERENCE_CONVERSION_BADNESS value to 'an_overloaded_function (const
foo &&)' (there is a different execution flow for that). This yields
in GDB picking the latter function as the overload champion instead of
the former.
In fact, the 'rank_one_type' function should have given
'an_overloaded_function (const foo &)' the CV_CONVERSION_BADNESS
value, with the see-through referencing increasing the subrank a
little bit. This can be achieved by introducing a new badness value,
REFERENCE_SEE_THROUGH_BADNESS, which bumps up the subrank only, and
using it in the two "exceptional" cases of 'sum_ranks'.
gdb/ChangeLog:
2019-12-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdbtypes.h: Define the REFERENCE_SEE_THROUGH_BADNESS value.
* gdbtypes.c (rank_one_type): Use REFERENCE_SEE_THROUGH_BADNESS
for ranking see-through reference cases.
gdb/testsuite/ChangeLog:
2019-12-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.cp/rvalue-ref-overload.cc: Add a case that involves both
CV and reference conversion for overload resolution.
* gdb.cp/rvalue-ref-overload.exp: Test it.
Change-Id: I39ae6505ab85ad0bd21915368c82540ceeb3aae9
GDB crashes when doing:
(gdb) faas
Aborted
Do the needed check to avoid crashing.
gdb/ChangeLog
2019-12-06 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* stack.c (faas_command): Check a command is provided.
* thread.c (taas_command, tfaas_command): Likewise.
gdb/testsuite/ChangeLog
2019-12-06 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.threads/pthreads.exp: Test taas and tfaas without command.
* gdb.base/frameapply.exp: Test faas without command.
Valgrind detects various inferior related leaks, such as:
==31877== 5,530 (56 direct, 5,474 indirect) bytes in 1 blocks are definitely lost in loss record 7,131 of 7,355
==31877== at 0x4C2E18C: calloc (vg_replace_malloc.c:760)
==31877== by 0x23E580: xcalloc (alloc.c:100)
==31877== by 0x4794A9: xcnewvec<void*> (poison.h:158)
==31877== by 0x4794A9: registry_alloc_data(registry_data_registry*, registry_fields*) (registry.c:51)
==31877== by 0x3A537C: inferior_alloc_data (inferior.c:43)
==31877== by 0x3A537C: inferior::inferior(int) (inferior.c:92)
==31877== by 0x3A5426: add_inferior_silent(int) (inferior.c:98)
==31877== by 0x3A5530: add_inferior(int) (inferior.c:122)
...
Origin of the leaks is in prune_inferiors: prune_inferiors is first removing
the inferior to prune from the inferior list, then calls delete_inferior.
But delete_inferior will only really destroy the inferior when it finds
it into the inferior list.
As delete_inferior is removing the inferior to delete from the inferior list,
ensure prune_inferiors only calls delete_inferior, without touching the
inferior list.
gdb/ChangeLog
2019-12-05 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* inferior.c (prune_inferiors): Only call delete_inferior.
Do not modify the inferior list.
I happened to find a few more spots that should use metadata style,
but do not. I missed these in my earlier search somehow. This patch
also adds gettext markup in a couple of spots where it was missing.
gdb/ChangeLog
2019-12-04 Tom Tromey <tom@tromey.com>
* valprint.c (val_print_string): Use metadata_style.
* go-valprint.c (print_go_string): Use metadata style.
* p-valprint.c (pascal_object_print_static_field): Use metadata
style.
* cp-valprint.c (cp_print_static_field): Use metadata style.
Change-Id: Id82ca2aa306c6694b111d5c92dfa6f0cce919ebf
When compiling Fortran tests (e.g. gdb.fortran/info-modules.exp), the
Fotran compile produces .mod files. These files contain details of
compiled modules that are then consumed by the compiler when compiling
other files that USE a module.
Currently the compiler writes the .mod files into its current
directory, so for us this turns out to be 'build/gdb/testsuite/'.
This means that .mod files can be shared between tests, which seems
against the spirit of the GDB testsuite; source files should be
compiled fresh for each test.
This commit adds the -J option to the compiler flags whenever we
compile a Fortran file, this option tells the compiler where to write,
and look for, .mod files.
After this commit there was one Fortran test that needed fixing, with
that fix in place all of the Fortran tests pass again, but now the
.mod files are now produced in the per-test output directories.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_compile): Add -J compiler option when building
Fortran tests.
* gdb.mi/mi-fortran-modules.exp: Compile source files in correct
order.
Change-Id: I99444cf22d80e320093d3f3ed9abb8825f378e0b
Joel Brobecker
Tom Tromey
Bernd Edlinger
Simon Marchi
Christian Biesinger
Ruslan Kabatsayev
George Barrett
Eli Zaretskii
Weimin Pan
Simon Marchi
Tankut Baris Aktemur
Tom Tromey
Andrew Burgess
Sergio Durigan Junior
Jozef Lawrynowicz
Luis Machado
Philippe Waroquiers
Kevin Buettner
Wataru Ashihara
Tom de Vries
Keith Seitz