The async-event.[ch] files were introduced recently as a result of
splitting the event-loop. I believe the copyright year update was
just an oversight. So, this patch fixes that.
gdb/ChangeLog:
2020-05-13 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* async-event.c: Update the copyright year.
* async-event.h: Update the copyright year.
As discussed on gdb-patches, this restores info_command and the
breakpoint on info_command in gdb-gdb.gdb. This reverts a tiny part
of 0743fc83c0 ("Replace most calls to help_list and cmd_show_list"),
as well as 652fc23a30 ("Remove gdb-gdb.gdb breakpoint on disappeared
function info_command.").
gdb/ChangeLog
2020-05-11 Tom Tromey <tromey@adacore.com>
* cli/cli-cmds.c (info_command): Restore.
(_initialize_cli_cmds): Use add_prefix_command for "info".
* gdb-gdb.gdb.in: Restore breakpoint on info_command.
The val_print removal patches introduced an Ada regression on PPC64
(probably any big-endian system).
The issue comes because value_field does not understand that Ada
wrapper fields can be bitfields that wrap a non-scalar type. In this
case the value is already left-justified, so the justification done
there does the wrong thing.
Perhaps it would be good, eventually, to change value_field to
understand this case. In the meantime this implements an Ada-specific
solution.
gdb/ChangeLog
2020-05-11 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_value_primitive_field): Now public.
* ada-lang.h (ada_value_primitive_field): Declare.
* ada-valprint.c (print_field_values): Use
ada_value_primitive_field for wrapper fields.
When running test-case gdb.fortran/info-modules.exp with target board
debug-names, I run into:
...
FAIL: gdb.fortran/info-modules.exp: info modules: check for entry \
'info-types-2.f90', '18', 'mod2'
...
In more detail, comparing the behaviour of the executable without and with
.debug_names section, we have:
...
-$ gdb -batch info-modules -ex "info modules"
+$ gdb -batch info-modules.debugnames -ex "info modules"
All defined modules:
-File /data/gdb_versions/devel/src/gdb/testsuite/gdb.fortran/info-types-2.f90:
-18: mod2
-
File /data/gdb_versions/devel/src/gdb/testsuite/gdb.fortran/info-types.f90:
16: mod1
...
This is due to the fact that the .debug_names section does not contain
DW_TAG_module entries.
Fix this in debug_names::psymbol_tag.
Build and tested on x86_64-linux with target board debug-names.
gdb/ChangeLog:
2020-05-11 Tom de Vries <tdevries@suse.de>
* dwarf2/index-write.c (debug_names::psymbol_tag): Handle
MODULE_DOMAIN.
Consider the following two-file test-case:
...
$ cat main.c
extern int foo (void);
int
main (void)
{
int sum, a, b;
sum = a + b + foo ();
return sum;
}
$ cat foo.c
int
foo (void)
{
return 3;
}
...
Compiled like this:
...
$ clang-10 -gdwarf-5 -gpubnames -c main.c
$ clang-10 -gdwarf-5 -c foo.c
$ clang-10 -gdwarf-5 -gpubnames main.o foo.o
...
When loading this exec into gdb, we run into this assert:
...
$ gdb a.out
Reading symbols from a.out...
warning: Section .debug_aranges in a.out entry at offset 0 \
debug_info_offset 0 does not exists, ignoring .debug_aranges.
src/gdb/dwarf2/read.c:6949: \
internal-error: cutu_reader::cutu_reader(dwarf2_per_cu_data*, \
abbrev_table*, int, bool): \
Assertion `this_cu->length == cu->header.get_length ()' failed.
...
The problem is that the determined length of the CU:
...
(gdb) p /x this_cu->length
$4 = 0x26a
...
does not match the actual length:
...
(gdb) p /x cu->header.get_length ()
$5 = 0x59
...
The length of the CU is determined in create_cus_from_debug_names_list, and
set based on this list in the .debug_names section:
...
Compilation Unit offsets [
CU[0]: 0x000000c7
]
...
and it is assumed that this is a complete list, so the size of the CU is
calculated using the end of the .debug_section at 0x331, making it 0x331 -
0xc7 == 0x26a.
However, the CU list is not complete:
...
$ llvm-dwarfdump -debug-info a.out \
| grep "Compile Unit" \
| sed 's/Compile Unit.*//'
0x00000000:
0x0000002e:
0x000000a5:
0x000000c7:
0x00000120:
0x00000157:
0x0000030f:
...
In particular, because the CU for foo.c is there at 0x120 (the rest of the CUs
is due to openSUSE having debug info for various linked in objects).
Fix the assert by not assuming to know the length of CUs in
create_cus_from_debug_names_list (if the .debug_names is not produced by GDB),
and setting it to 0, and setting it later to the actual length.
Note that this does not fix the .debug_aranges warning, that's PR25969.
Build and tested on x86_64-linux, with native and debug-names.
gdb/ChangeLog:
2020-05-11 Tom de Vries <tdevries@suse.de>
PR symtab/25941
* dwarf2/read.c (create_cus_from_debug_names_list): Initialize CUs
with length 0, if not gdb-produced.
(cutu_reader::cutu_reader): Set CU length to actual length if 0.
gdb/testsuite/ChangeLog:
2020-05-11 Tom de Vries <tdevries@suse.de>
PR symtab/25941
* gdb.dwarf2/clang-debug-names.exp.in: New include exp file, factored
out of ...
* gdb.dwarf2/clang-debug-names.exp: ... here.
* gdb.dwarf2/clang-debug-names-2.exp: New file. Include
clang-debug-names.exp.in.
* gdb.dwarf2/clang-debug-names-2-foo.c: New test.
* gdb.dwarf2/clang-debug-names-2.c: New test.
When running test-case gdb.mi/mi-catch-cpp-exceptions.exp, we have:
...
FAIL: gdb.mi/mi-catch-cpp-exceptions.exp: all with invalid regexp: run until \
breakpoint in main (unknown output after running)
...
This is a regression since commit 596dc4adff "Speed up psymbol reading by
removing a copy".
Before that commit, we have:
...
$ gdb \
-batch \
./outputs/gdb.mi/mi-catch-cpp-exceptions/mi-catch-cpp-exceptions \
-ex "break 67" \
-ex "catch throw -r blahblah" \
-ex r
Breakpoint 1 at 0x4008e5: file mi-catch-cpp-exceptions.cc, line 67.
Catchpoint 2 (throw)
Breakpoint 1, main () at mi-catch-cpp-exceptions.cc:67
67 return 1; /* Stop here. */
...
In other words:
- we set a breakpoint somewhere in main,
- we set a catchpoint with a regexp that is intended to not match any
exception, and
- run to the breakpoint, without the catchpoint triggering.
After the commit, we have:
...
$ gdb \
-batch \
./outputs/gdb.mi/mi-catch-cpp-exceptions/mi-catch-cpp-exceptions \
-ex "break 67" \
-ex "catch throw -r blahblah" \
-ex r
Breakpoint 1 at 0x4008e5: file mi-catch-cpp-exceptions.cc, line 67.
Catchpoint 2 (throw)
Catchpoint 2 (exception thrown), 0x00007ffff7ab037e in __cxa_throw () from \
/usr/lib64/libstdc++.so.6
...
In other words, the catchpoint triggers.
This is caused by this bit of the commit:
...
type_name = cplus_typename_from_type_info (typeinfo_arg);
canon = cp_canonicalize_string (type_name.c_str ());
- if (!canon.empty ())
- std::swap (type_name, canon);
+ name = (canon == nullptr
+ ? canon.get ()
+ : type_name.c_str ());
}
catch (const gdb_exception_error &e)
{
exception_print (gdb_stderr, e);
}
- if (!type_name.empty ())
+ if (name != nullptr)
{
- if (self->pattern->exec (type_name.c_str (), 0, NULL, 0) != 0)
+ if (self->pattern->exec (name, 0, NULL, 0) != 0)
...
Before the commit, we have:
- type_name == "my_exception"
- canon = ""
and the !type_name.empty () test succeeds, and gdb executes the
self->pattern->exec call.
After the commit, we have:
- type_name == "my_exception"
- canon == NULL
- name == NULL
and the name != nullptr test fails, and gdb doesn't execute the
self->pattern->exec call.
Fix this by inverting the condition for the calculation of name:
...
- name = (canon == nullptr
+ name = (canon != nullptr
...
Build and tested on x86_64-linux.
gdb/ChangeLog:
2020-05-09 Tom de Vries <tdevries@suse.de>
PR gdb/25955
* break-catch-throw.c (check_status_exception_catchpoint): Fix name
calculation.
I noticed that "server_command" is an int, but really it should be a
bool.
gdb/ChangeLog
2020-05-09 Tom Tromey <tom@tromey.com>
* top.c (server_command): Now bool.
* top.h (server_command): Now bool.
A customer reported a crash in the DWARF reader.
Investigation showed that the crash occurred in an unusual scenario: a
function was lexically scoped within some other function -- but the
inner function inlined the outer function and referred to its DIE via
DW_AT_abstract_origin. With the executable in question,
inherit_abstract_dies could eventually call read_lexical_block_scope,
which in turn could recurse into process_die, to process a DIE that
was already being read, triggering an assert.
This came up once before; see:
https://www.sourceware.org/ml/gdb-patches/2014-02/msg00652.html
However, in this case, I don't have an easy way to reproduce. So,
there is no test case.
I did experiment with the failing executable. This patch fixes the
bug and doesn't seem to cause other issues. For example, I can still
set breakpoints on the relevant functions.
gdb/ChangeLog
2020-05-08 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (read_lexical_block_scope): Don't process a DIE
already being processed.
This changes displays to have a constructor, use bool and std::string,
and to be stored using std::vector. The ALL_DISPLAYS and
ALL_DISPLAYS_SAFE macros are removed. While internal iteration is
still done via map_display_numbers, this is updated to use a
function_view. These changes simplify the code somewhat; for example,
free_display can now be removed in favor of ordinary destruction.
gdb/ChangeLog
2020-05-08 Tom Tromey <tom@tromey.com>
* printcmd.c (struct display) <next>: Remove.
<display>: New constructor.
<exp_string>: Now a std::string.
<enabled_p>: Now a bool.
(display_number): Move definition earlier.
(displays): Rename from display_chain. Now a std::vector.
(ALL_DISPLAYS, ALL_DISPLAYS_SAFE): Remove.
(display_command): Update.
(do_one_display, disable_display)
(enable_disable_display_command, do_enable_disable_display):
Update.
(free_display): Remove.
(clear_displays): Rewrite.
(delete_display): Update.
(map_display_numbers): Use function_view. Remove "data"
parameter. Update.
(do_delete_display): Remove.
(undisplay_command): Update.
(do_one_display, do_displays, disable_display)
(info_display_command): Update.
(do_enable_disable_display): Remove.
(enable_disable_display_command)
(clear_dangling_display_expressions): Update.
This patch started as an attempt to replace ALL_SO_LIBS with an
ordinary C++ iterator. However, then I tripped over the so_list_head
define again, and decided to remove it as well.
gdb/ChangeLog
2020-05-08 Tom Tromey <tom@tromey.com>
* mi/mi-cmd-file.c (mi_cmd_file_list_shared_libraries): Update.
* solib-svr4.c (svr4_fetch_objfile_link_map): Update.
(enable_break): Update.
* solib-frv.c (frv_fdpic_find_global_pointer): Update.
(frv_fdpic_find_canonical_descriptor): Update.
(frv_fetch_objfile_link_map): Update.
* progspace.c (program_space::free_all_objfiles): Update.
(program_space::solibs): New method.
* progspace.h (struct program_space) <solibs>: New method.
* solist.h (master_so_list): Don't declare.
(ALL_SO_LIBS): Remove.
* solib.h (so_list_head): Remove.
(update_solib_list): Update comment.
* solib.c (master_so_list): Remove.
(solib_used, update_solib_list, solib_add)
(info_sharedlibrary_command, clear_solib)
(reload_shared_libraries_1, remove_user_added_objfile): Update.
This removes the ALL_EXTENSION_LANGUAGES and
ALL_ENABLED_EXTENSION_LANGUAGES macros, in favor of ordinary
iterators. For ALL_ENABLED_EXTENSION_LANGUAGES, I chose to simply
inline the check, as that seemed simpler than trying to make
filtered_iterator work for std::array. (As an aside, this sort of
thing will be easier once we can use the ranges library...)
gdb/ChangeLog
2020-05-08 Tom Tromey <tom@tromey.com>
* extension.c (extension_languages): Now a std::array.
(ALL_EXTENSION_LANGUAGES): Remove.
(get_ext_lang_defn, get_ext_lang_of_file)
(eval_ext_lang_from_control_command): Update.
(finish_ext_lang_initialization)
(auto_load_ext_lang_scripts_for_objfile)
(ext_lang_type_printers::ext_lang_type_printers)
(apply_ext_lang_type_printers)
(ext_lang_type_printers::~ext_lang_type_printers)
(apply_ext_lang_val_pretty_printer, apply_ext_lang_frame_filter)
(preserve_ext_lang_values, get_breakpoint_cond_ext_lang)
(breakpoint_ext_lang_cond_says_stop, check_quit_flag)
(get_matching_xmethod_workers, ext_lang_colorize)
(ext_lang_before_prompt): Update.
(ALL_ENABLED_EXTENSION_LANGUAGES): Remove.
I noticed that cp_canonicalize_string and friends copy a
unique_xmalloc_ptr to a std::string. However, this copy isn't
genuinely needed anywhere, and it serves to slow down DWARF psymbol
reading.
This patch removes the copy and updates the callers to adapt.
This speeds up the reader from 1.906 seconds (mean of 10 runs, of gdb
on a copy of itself) to 1.888 seconds (mean of 10 runs, on the same
copy as the first trial).
gdb/ChangeLog
2020-05-08 Tom Tromey <tom@tromey.com>
* symtab.h (class demangle_result_storage) <set_malloc_ptr>: New
overload.
<swap_string, m_string>: Remove.
* symtab.c (demangle_for_lookup, completion_list_add_symbol):
Update.
* stabsread.c (define_symbol, read_type): Update.
* linespec.c (find_linespec_symbols): Update.
* gnu-v3-abi.c (gnuv3_get_typeid): Update.
* dwarf2/read.c (dwarf2_canonicalize_name): Update.
* dbxread.c (read_dbx_symtab): Update.
* cp-support.h (cp_canonicalize_string_full)
(cp_canonicalize_string, cp_canonicalize_string_no_typedefs):
Return unique_xmalloc_ptr.
* cp-support.c (inspect_type): Update.
(cp_canonicalize_string_full): Return unique_xmalloc_ptr.
(cp_canonicalize_string_no_typedefs, cp_canonicalize_string):
Likewise.
* c-typeprint.c (print_name_maybe_canonical): Update.
* break-catch-throw.c (check_status_exception_catchpoint):
Update.
When running test-case gdb.threads/fork-child-threads.exp with gcc-8 instead
of gcc-7, we have:
...
(gdb) next^M
[Attaching after Thread 0x7ffff7fae740 (LWP 27574) fork to child process \
27578]^M
[New inferior 2 (process 27578)]^M
[Detaching after fork from parent process 27574]^M
[Inferior 1 (process 27574) detached]^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
[Switching to Thread 0x7ffff7fae740 (LWP 27578)]^M
-main () at src/gdb/testsuite/gdb.threads/fork-child-threads.c:41^M
+main () at src/gdb/testsuite/gdb.threads/fork-child-threads.c:34^M
-41 i = pthread_create (&thread, NULL, start, NULL);^M
+34 switch (fork ())^M
-(gdb) PASS: gdb.threads/fork-child-threads.exp: next over fork
+(gdb) FAIL: gdb.threads/fork-child-threads.exp: next over fork
...
This is due to the fact that gcc-8 generates more precise line info, making
the instruction after the call to fork a "recommended breakpoint location".
However, it is a bug because next is supposed to move to the next source
line.
The problem is that in process_event_stop_test we hit this code:
...
if ((ecs->event_thread->suspend.stop_pc == stop_pc_sal.pc)
&& (ecs->event_thread->current_line != stop_pc_sal.line
|| ecs->event_thread->current_symtab != stop_pc_sal.symtab))
{
if (stop_pc_sal.is_stmt)
{
/* We are at the start of a different line. So stop. Note that
we don't stop if we step into the middle of a different line.
That is said to make things like for (;;) statements work
better. */
if (debug_infrun)
fprintf_unfiltered (gdb_stdlog,
"infrun: stepped to a different line\n");
end_stepping_range (ecs);
return;
}
...
because current_line and current_symtab have initial values:
...
(gdb) p ecs->event_thread->current_line
$8 = 0
(gdb) p ecs->event_thread->current_symtab
$9 = (symtab *) 0x0
...
Fix this in follow_fork by copying current_line and current_symtab from
parent thread to child thread.
Tested on x86_64-linux, with gcc 7.5.0 and gcc 10.0.1.
gdb/ChangeLog:
2020-05-08 Tom de Vries <tdevries@suse.de>
* infrun.c (follow_fork): Copy current_line and current_symtab to
child thread.
This is a small cleanup to normalize the structures in async-event.c
with the rest of the code base:
- Remove the unnecessary typedefs
- Fix indentation of struct bodies
- Put comments above fields
No functional changes expected.
gdb/ChangeLog:
* async-event.c (struct async_signal_handler, struct
async_event_handler): Reformat, remove typedef.
Remove this macro, which abstracts how to obtain the dyn_prop_list of a
given type. We could replace it with a method on `struct type`, but I
don't think it's needed, as the only code that accesses the dynamic prop
list directly is internal gdbtypes.c code (that can be seen as code
internal to `struct type`). So it can just refer to the field directly.
gdb/ChangeLog:
* gdbtypes.h (TYPE_DYN_PROP_LIST): Remove. Update all users
access thistype->main_type->dyn_prop_list directly.
Move remove_dyn_prop, currently a free function, to be a method of
struct type.
gdb/ChangeLog:
* gdbtypes.h (struct type) <remove_dyn_prop>: New method.
(remove_dyn_prop): Remove. Update all users to use
type::remove_dyn_prop.
* gdbtypes.c (remove_dyn_prop): Rename to...
(type::remove_dyn_prop): ... this.
Move add_dyn_prop, currently a free function, to be a method of struct
type.
gdb/ChangeLog:
* gdbtypes.h (struct type) <add_dyn_prop>: New method.
(add_dyn_prop): Remove. Update all users to use
type::add_dyn_prop.
* gdbtypes.c (add_dyn_prop): Rename to...
(type::add_dyn_prop): ... this.
Move get_dyn_prop, currently a free function, to be a method on struct
type.
gdb/ChangeLog:
* gdbtypes.h (struct type) <get_dyn_prop>: New method.
(get_dyn_prop): Remove. Update all users to use
type::dyn_prop.
* gdbtypes.c (get_dyn_prop): Rename to...
(type::dyn_prop): ... this.
v2:
- test: build full executable instead of object
- test: add and use supports_fcf_protection
- test: use gdb_test_multiple's -wrap option
- test: don't execute gdb_assert if failed to get breakpoint address
Some GCCs now enable -fcf-protection by default. This is the case, for
example, with GCC 9.3.0 on Ubuntu 20.04. Enabling it causes the
`endbr64` instruction to be inserted at the beginning of all functions
and that breaks GDB's prologue analysis.
I noticed this because it gives many failures in gdb.base/break.exp.
But let's take this dummy program and put a breakpoint on main:
int main(void)
{
return 0;
}
Without -fcf-protection, the breakpoint is correctly put after the prologue:
$ gcc test.c -g3 -O0 -fcf-protection=none
$ ./gdb -q -nx --data-directory=data-directory a.out
Reading symbols from a.out...
(gdb) disassemble main
Dump of assembler code for function main:
0x0000000000001129 <+0>: push %rbp
0x000000000000112a <+1>: mov %rsp,%rbp
0x000000000000112d <+4>: mov $0x0,%eax
0x0000000000001132 <+9>: pop %rbp
0x0000000000001133 <+10>: retq
End of assembler dump.
(gdb) b main
Breakpoint 1 at 0x112d: file test.c, line 3.
With -fcf-protection, the breakpoint is incorrectly put on the first
byte of the function:
$ gcc test.c -g3 -O0 -fcf-protection=full
$ ./gdb -q -nx --data-directory=data-directory a.out
Reading symbols from a.out...
(gdb) disassemble main
Dump of assembler code for function main:
0x0000000000001129 <+0>: endbr64
0x000000000000112d <+4>: push %rbp
0x000000000000112e <+5>: mov %rsp,%rbp
0x0000000000001131 <+8>: mov $0x0,%eax
0x0000000000001136 <+13>: pop %rbp
0x0000000000001137 <+14>: retq
End of assembler dump.
(gdb) b main
Breakpoint 1 at 0x1129: file test.c, line 2.
Stepping in amd64_skip_prologue, we can see that the prologue analysis,
for GCC-compiled programs, is done in amd64_analyze_prologue by decoding
the instructions and looking for typical patterns. This patch changes
the analysis to check for a prologue starting with the `endbr64`
instruction, and skip it if it's there.
gdb/ChangeLog:
* amd64-tdep.c (amd64_analyze_prologue): Check for `endbr64`
instruction, skip it if it's there.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-prologue-skip-cf-protection.exp: New file.
* gdb.arch/amd64-prologue-skip-cf-protection.c: New file.
It is unused. The corresponding macro was removed in c3236f84c1 ("gdb:
remove TYPE_INCOMPLETE").
gdb/ChangeLog:
* gdbtypes.h (struct main_type) <flag_incomplete>: Remove.
The "HP platforms" comment prompted me to check if this was still used
somewhere. Apparently it's not, so remove it.
gdb/ChangeLog:
* gdbtypes.h (TYPE_INCOMPLETE): Remove.
* gdbtypes.c (recursive_dump_type): Remove use of
TYPE_INCOMPLETE.
I looked at all the calls to add_prefix_cmd, and replaced them with
calls to add_basic_prefix_cmd or add_show_prefix_cmd when appropriate.
This makes gdb's command language a bit more regular. I don't think
there's a significant downside.
Note that this patch removes a couple of tests. The removed ones are
completely redundant.
gdb/ChangeLog
2020-05-03 Tom Tromey <tom@tromey.com>
* breakpoint.c (catch_command, tcatch_command): Remove.
(_initialize_breakpoint): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
(set_breakpoint_cmd, show_breakpoint_cmd): Remove
* utils.c (set_internal_problem_cmd, show_internal_problem_cmd):
Remove.
(add_internal_problem_command): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* mips-tdep.c (set_mipsfpu_command): Remove.
(_initialize_mips_tdep): Use add_basic_prefix_cmd.
* dwarf2/index-cache.c (set_index_cache_command): Remove.
(_initialize_index_cache): Use add_basic_prefix_cmd.
* memattr.c (dummy_cmd): Remove.
(_initialize_mem): Use add_basic_prefix_cmd, add_show_prefix_cmd.
* tui/tui-win.c (set_tui_cmd, show_tui_cmd): Remove.
(_initialize_tui_win): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* cli/cli-logging.c (set_logging_command): Remove.
(_initialize_cli_logging): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
(show_logging_command): Remove.
* target.c (target_command): Remove.
(add_target): Use add_basic_prefix_cmd.
gdb/testsuite/ChangeLog
2020-05-03 Tom Tromey <tom@tromey.com>
* gdb.base/sepdebug.exp: Remove "catch" test.
* gdb.base/break.exp: Remove "catch" test.
* gdb.base/default.exp: Update expected output.
The function info_command has disappeared, so this breakpoint does not
work anymore.
"info_command" was a function for the prefix command "info",
giving the list of "info" subcommands.
It is not very clear what the removed breakpoint and its associated
command list was supposed to do.
Removed and pushed as obvious, after discussion with Tom.
Report LWP CREATE and LWP EXIT events and setup this on post_attach()
and post_startup_inferior().
Stop reinitializing the list of recognized threads in update_thread_list().
Handle LWP CREATE and EXIT events in nbsd_nat_target::wait().
gdb/ChangeLog:
* nbsd-nat.c (nbsd_enable_proc_events)
(nbsd_nat_target::post_startup_inferior): Add.
(nbsd_nat_target::post_attach): Call `nbsd_enable_proc_events'.
(nbsd_nat_target::update_thread_list): Rewrite.
(nbsd_nat_target::wait): Handle "PTRACE_LWP_EXIT" and
"PTRACE_LWP_CREATE".
* nbsd-nat.h (nbsd_nat_target::post_startup_inferior): Add.
This reverts commit 84ed7a4725.
The problem that the commit attempts to address has already been fixed in
commit 770479f223 "gdb: Fix toplevel types with -fdebug-types-section".
The commit itself is superfluous because it sets list_in_scope at a point that
it's already set (by start_symtab).
"frame" and "f" are created twice by stack.c _initialize_stack.
Remove the second creation.
Regression tested on amd64/Debian.
2020-04-30 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* stack.c (_initialize_stack): Remove duplicated creation
of "frame" command and "f" alias.
Sizes of stubbed types are calculated on demand in check_typedef, so the
same must also be done for arrays of stubbed types.
A stubbed type is usually a structure that has only been forward declared,
but can also happen if the structure has a virtual function that's not
inline in the class definition.
For these stubbed types, the size must be recalculated once the full
definition is available.
gdb/ChangeLog:
2020-04-30 Hannes Domani <ssbssa@yahoo.de>
PR gdb/18706
* gdbtypes.c (check_typedef): Calculate size of array of
stubbed type.
gdb/testsuite/ChangeLog:
2020-04-30 Hannes Domani <ssbssa@yahoo.de>
PR gdb/18706
* gdb.cp/stub-array-size.cc: New test.
* gdb.cp/stub-array-size.exp: New file.
* gdb.cp/stub-array-size.h: New test.
* gdb.cp/stub-array-size2.cc: New test.
Non-static member functions for Windows 32bit programs need the thiscall
calling convention, so the 'this' pointer needs to be passed in ECX.
gdb/ChangeLog:
2020-04-30 Hannes Domani <ssbssa@yahoo.de>
PR gdb/15559
* i386-tdep.c (i386_push_dummy_call): Call
i386_thiscall_push_dummy_call.
(i386_thiscall_push_dummy_call): New function.
* i386-tdep.h (i386_thiscall_push_dummy_call): Declare.
* i386-windows-tdep.c (i386_windows_push_dummy_call): New function.
(i386_windows_init_abi): Call set_gdbarch_push_dummy_call.
shellcheck reports:
In gdbarch.sh line 53:
while IFS='' read line
^--^ SC2162: read without -r will mangle backslashes.
See the rationale at [1]. In our case, we actually want the backslashes
to be interpreted and removed. Silence the warning using a directive.
[1] https://github.com/koalaman/shellcheck/wiki/SC2162
gdb/ChangeLog:
* gdbarch.sh (do_read): Add shellcheck disable directive for
warning SC2162.
Fix all instances of this kind of warning:
In gdbarch.sh line 96:
m ) staticdefault="${predefault}" ;;
^-----------^ SC2154: predefault is referenced but not assigned.
These warnings appear because we are doing something a bit funky when reading
the gdbarch fields. These variables are not assigned explicitly, but
using some `eval` commands.
I don't think there is so much we can fix about those warnings. To
silence them, I've changed `${foo}` to `${foo:-}`. This tells the shell
to substitute with an empty string if `foo` is not defined. This
retains the current behavior, but the warnings go away.
gdb/ChangeLog:
* gdbarch.sh: Use ${foo:-} where shellcheck would report a
"referenced but not assigned" warning.
shellcheck reports:
In gdbarch.sh line 139:
fallbackdefault="0"
^-------------^ SC2034: fallbackdefault appears unused. Verify use (or export if used externally).
Indeed, the `fallbackdefault` variable appears to be unused, remove the
code that sets it.
gdb/ChangeLog:
* gdbarch.sh: Remove code that sets fallbackdefault.
Fix all warnings of this type:
In gdbarch.sh line 1238:
if [ "x${invalid_p}" = "x0" -a -n "${postdefault}" ]
^-- SC2166: Prefer [ p ] && [ q ] as [ p -a q ] is not well defined.
See the rationale here [1].
[1] https://github.com/koalaman/shellcheck/wiki/SC2166
gdb/ChangeLog:
* gdbarch.sh: Use shell operators && and || instead of
-a and -o.
Fix all instances of:
In gdbarch.sh line 2195:
printf " `echo "$function" | sed -e 's/./ /g'` %s %s)\n" "$returntype" "$function"
^-- SC2006: Use $(...) notation instead of legacy backticked `...`.
Did you mean:
printf " $(echo "$function" | sed -e 's/./ /g') %s %s)\n" "$returntype" "$function"
See here [1] for the rationale.
[1] https://github.com/koalaman/shellcheck/wiki/SC2006
gdb/ChangeLog:
* gdbarch.sh: Use $(...) instead of `...`.
Fix all instances of:
In gdbarch.sh line 31:
if test ! -r ${file}
^-----^ SC2086: Double quote to prevent globbing and word splitting.
Did you mean:
if test ! -r "${file}"
Note that some instances of these are in text that is eval'ed. I'm
pretty sure that things could go wrong during the eval too, but that's
not something shellcheck can check.
gdb/ChangeLog:
* gdbarch.sh: Use double quotes around variables.
Fix all instances of this:
In gdbarch.sh line 2182:
printf " gdb_assert (!(${invalid_p}));\n"
^-- SC2059: Don't use variables in the printf format string. Use printf "..%s.." "$foo".
... by doing exactly as the message suggests.
The rationale explained here [1] makes sense, if there happens to be a
format specifier in text substituted for the variable, the printf won't
do what we expect.
[1] https://github.com/koalaman/shellcheck/wiki/SC2059
gdb/ChangeLog:
* gdbarch.sh: Use %s with printf, instead of variables in the
format string.
PR ada/25875 concerns a gdb crash when gdb.ada/arr_enum_idx_w_gap.exp
is run using the .debug_types board.
The problem turns out to be caused by weird compiler output. In this
test, the compiler emits a top-level type that refers to an
enumeration type which is nested in a function. However, this
function is just a declaration.
This results in gdb calling read_enumeration_type for the enum type,
but process_enumeration_scope is never called, yielding an enum with
no fields. This causes the crash.
This patch fixes the problem by arranging to create the enum fields in
read_enumeration_type.
Tested on x86-64 Fedora 30.
gdb/ChangeLog
2020-04-29 Tom Tromey <tromey@adacore.com>
PR ada/25875:
* dwarf2/read.c (update_enumeration_type_from_children): Compute
type fields here.
(read_enumeration_type): Call
update_enumeration_type_from_children later. Update comments.
(process_enumeration_scope): Don't create type fields.
The syscall literal names are not stable on NetBSD and can change
once a syscall is versioned. Thus these names are internal to the
system and in GDB mostly descriptive, not intended to be a stable
interface with fixed names across GDB and NetBSD versions to track
certain syscalls.
gdb/ChangeLog:
* nbsd-tdep.c: Include "xml-syscall.h".
(nbsd_init_abi): Call `set_xml_syscall_file_name'.
Implement the following events:
- single step (TRAP_TRACE)
- software breakpoint (TRAP_DBREG)
- exec() (TRAP_EXEC)
- syscall entry/exit (TRAP_SCE / TRAP_SCX)
Add support for NetBSD specific ::wait () and ::resume ().
Instruct the generic code that exec and syscall events are supported.
Define an empty nbsd_get_syscall_number as it is prerequisite for
catching syscall entry and exit events, even if it is unused.
This function is used to detect whether the gdbarch supports the
'catch syscall' feature.
gdb/ChangeLog:
* nbsd-nat.c: Include "sys/wait.h".
(nbsd_resume, nbsd_nat_target::resume, nbsd_wait)
(nbsd_nat_target::wait, nbsd_nat_target::insert_exec_catchpoint)
(nbsd_nat_target::remove_exec_catchpoint)
(nbsd_nat_target::set_syscall_catchpoint): Add.
* nbsd-nat.h (nbsd_nat_target::resume, nbsd_nat_target::wait)
(nbsd_nat_target::insert_exec_catchpoint)
(nbsd_nat_target::remove_exec_catchpoint)
(nbsd_nat_target::set_syscall_catchpoint): Add.
* nbsd-tdep.c (nbsd_get_syscall_number): Add.
(nbsd_init_abi): Call `set_gdbarch_get_syscall_number' and pass
`nbsd_get_syscall_number'.
print_block_frame_labels has been commented out since 2010.
I don't think we need it; this patch removes it.
2020-04-29 Tom Tromey <tom@tromey.com>
* stack.c (print_block_frame_labels): Remove.
Currently, printing with array pretty formatting makes the output actually
less readable than without:
(gdb) p -array on -- {{1,2,3},{4,5,6}}
$1 = { {1,
2,
3},
{4,
5,
6}}
(gdb) p -array on -array-indexes on -- {{1,2,3},{4,5,6}}
$2 = {[0] = {[0] = 1,
[1] = 2,
[2] = 3},
[1] = {[0] = 4,
[1] = 5,
[2] = 6}}
These changes now also put the first element and the array end bracket on a new
line, similar to the structure pretty formatter:
(gdb) p -array on -- {{1,2,3},{4,5,6}}
$1 = {
{
1,
2,
3
},
{
4,
5,
6
}
}
(gdb) p -array on -array-indexes on -- {{1,2,3},{4,5,6}}
$2 = {
[0] = {
[0] = 1,
[1] = 2,
[2] = 3
},
[1] = {
[0] = 4,
[1] = 5,
[2] = 6
}
}
gdb/ChangeLog:
2020-04-29 Hannes Domani <ssbssa@yahoo.de>
PR gdb/17320
* ada-valprint.c (val_print_packed_array_elements): Move array
end bracket to new line.
(ada_val_print_string): Remove extra spaces before first array
element.
* c-valprint.c (c_value_print_array): Likewise.
* m2-valprint.c (m2_print_array_contents): Likewise.
(m2_value_print_inner): Likewise.
* p-valprint.c (pascal_value_print_inner): Likewise.
* valprint.c (generic_val_print_array): Likewise.
(value_print_array_elements): Move first array element and array
end bracket to new line.
gdb/testsuite/ChangeLog:
2020-04-29 Hannes Domani <ssbssa@yahoo.de>
PR gdb/17320
* gdb.base/pretty-array.c: New test.
* gdb.base/pretty-array.exp: New file.
With target board debug-types, we have:
...
FAIL: gdb.cp/cpexprs.exp: list policy1::function
...
This is a regression triggered by commit 770479f223 "gdb: Fix toplevel types
with -fdebug-types-section".
However, the FAIL is caused by commit 4dedf84da9 "Change
decode_compound_collector to use std::vector" which changes a VEC_iterate loop
into a range loop:
...
- for (ix = 0; VEC_iterate (symbolp, sym_classes, ix, sym); ++ix)
+ unsigned int ix = 0;
+ for (const auto &sym : *sym_classes)
...
but fails to ensure that the increment of ix happens every iteration.
Fix this by calculating the index variable at the start of the loop body:
...
for (const auto &elt : *sym_classes)
{
unsigned int ix = &elt - &*sym_classes->begin ();
...
Tested on x86_64-linux, with native and target board debug-types.
gdb/ChangeLog:
2020-04-29 Tom de Vries <tdevries@suse.de>
PR symtab/25889
* linespec.c (find_method): Fix ix calculation.
gdb/testsuite/ChangeLog:
2020-04-29 Tom de Vries <tdevries@suse.de>
PR symtab/25889
* gdb.cp/cpexprs.exp: Adapt for inclusion.
* gdb.cp/cpexprs-debug-types.exp: New file. Set -fdebug-types-section
and include cpexprs.exp.
All platforms on NetBSD use a shared system call table, so use a
single XML file to describe the system calls available on each NetBSD
platform.
gdb/ChangeLog:
* syscalls/update-netbsd.sh: New file.
* syscalls/netbsd.xml: Regenerate.
* data-directory/Makefile.in: Register `netbsd.xml' in
`SYSCALLS_FILES'
shellcheck reports:
In update-freebsd.sh line 72:
}' $1 >> freebsd.xml.tmp
^-- SC2086: Double quote to prevent globbing and word splitting.
Did you mean:
}' "$1" >> freebsd.xml.tmp
For more information:
https://www.shellcheck.net/wiki/SC2086 -- Double quote to prevent globbing ...
Add double quotes to fix it.
gdb/ChangeLog:
* syscalls/update-freebsd.sh: Add double quotes.
Now that Python code can create TUI windows, it seemed appropriate to
allow Python commands to appear in the "TUI" help class. This patch
adds this capability.
gdb/ChangeLog
2020-04-28 Tom Tromey <tom@tromey.com>
* NEWS: Update.
* python/py-cmd.c (gdbpy_initialize_commands): Add COMMAND_TUI.
(cmdpy_init): Allow class_tui.
gdb/doc/ChangeLog
2020-04-28 Tom Tromey <tom@tromey.com>
* python.texi (Commands In Python): Document gdb.COMMAND_TUI.