gdb/remote: Restore support for 'S' stop reply packet
A regression was introduced such that the W and X packets would give a
warning in some cases. The warning was:
warning: multi-threaded target stopped without sending a thread-id, using first non-exited thread
This problem would arise when:
1. The multi-process extensions to the remote protocol were not
being used, and
2. The inferior has multiple threads.
In this case when the W (or X) packet arrives the ptid of the
stop_reply is set to null_ptid, then when we arrive in
process_stop_reply GDB spots that we have multiple non-exited theads,
but the stop event didn't specify a thread-id.
The problem with this is that the W (and X) packets are actually
process wide events, they apply to all threads. So not specifying a
thread-id is not a problem, in fact, the best these packets allow is
for the remote to specify a process-id, not a thread-id.
If we look at how the W (and X) packets deal with a specified
process-id, then what happens is GDB sets to stop_reply ptid to a
value which indicates all threads in the process, this is done by
creating a value `ptid_t (pid)`, which sets the pid field of the
ptid_t, but leaves the tid field as 0, indicating all threads.
So, this commit does the same thing for the case where there is not
process-id specified. In process_stop_reply we not distinguish
between stop events that apply to all threads, and those that apply to
only one. If the stop event applies to only one thread then we treat
it as before. If, however, the stop event applies to all threads,
then we find the first non-exited thread, and use the pid from this
thread to create a `ptid_t (pid)` value.
If the target has multiple inferiors, and receives a process wide
event without specifying a process-id GDB now gives this warning:
warning: multi-inferior target stopped without sending a process-id, using first non-exited inferior
gdb/ChangeLog:
* remote.c (remote_target::process_stop_reply): Handle events for
all threads differently.
gdb/testsuite/ChangeLog:
* gdb.server/exit-multiple-threads.c: New file.
* gdb.server/exit-multiple-threads.exp: New file.
Andrew Burgess [Sat, 8 Feb 2020 21:26:31 +0000 (21:26 +0000)]
gdb/testsuite/fortran: Add mixed language stack test
This commit adds a test that builds a mixed language stack, the stack
contains frames of Fortran, C, and C++. The test prints the backtrace
and explores the stack printing arguments of different types in frames
of different languages.
The core of the test is repeated with GDB's language set to auto,
fortran, c, and c++ in turn to ensure that GDB is happy to print
frames and frame arguments when the language is set to a value that
doesn't match the frame language.
This test currently passes, and there are no known bugs in this area.
The aim of this commit is simply to increase test coverage, as I don't
believe this functionality is currently tested.
gdb/testsuite/ChangeLog:
* gdb.fortran/mixed-lang-stack.c: New file.
* gdb.fortran/mixed-lang-stack.cpp: New file.
* gdb.fortran/mixed-lang-stack.exp: New file.
* gdb.fortran/mixed-lang-stack.f90: New file.
(gdb) break get_va<TAB>
(gdb) break get_value(object<RETURN>
Function "get_value(object" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
The reason this happens is that we add completions based on the
msymbol names and on the symbol names. For C++ both of these names
include the parameter list, however, the msymbol names have some
differences from the symbol names, for example:
+ typedefs are resolved,
+ whitespace rules are different around pointers,
+ the 'const' keyword is placed differently.
What this means is that the msymbol names and symbol names appear to
be completely different to GDB's completion tracker, and therefore to
readline when it offers the completions.
This commit builds on the previous commit which reworked the
completion_tracker class. It is now trivial to add a
remove_completion member function, this is then used along with
cp_canonicalize_string_no_typedefs to remove the msymbol aliases from
the completion tracker as we add the symbol names.
Now, for the above program GDB only presents a single completion for
'get_value', which is 'get_value(object_p)'.
It is still possible to reference the symbol using the msymbol name,
so a user can manually type out 'break get_value (object *)' if they
wish and will get the expected behaviour.
I did consider adding an option to make this alias exclusion optional,
in the end I didn't bother as I didn't think it would be very useful,
but I can easily add such an option if people think it would be
useful.
gdb/ChangeLog:
* completer.c (completion_tracker::remove_completion): Define new
function.
* completer.h (completion_tracker::remove_completion): Declare new
function.
* symtab.c (completion_list_add_symbol): Remove aliasing msymbols
when adding a C++ function symbol.
gdb/testsuite/ChangeLog:
* gdb.linespec/cp-completion-aliases.cc: New file.
* gdb.linespec/cp-completion-aliases.exp: New file.
Andrew Burgess [Mon, 27 Jan 2020 17:37:20 +0000 (17:37 +0000)]
gdb: Restructure the completion_tracker class
In this commit I rewrite how the completion tracker tracks the
completions, and builds its lowest common denominator (LCD) string.
The LCD string is now built lazily when required, and we only track
the completions in one place, the hash table, rather than maintaining
a separate vector of completions.
The motivation for these changes is that the next commit will add the
ability to remove completions from the list, removing a completion
will invalidate the LCD string, so we need to keep hold of enough
information to recompute the LCD string as needed.
Additionally, keeping the completions in a vector makes removing a
completion expensive, so better to only keep the completions in the
hash table.
This commit doesn't add any new functionality itself, and there should
be no user visible changes after this commit.
For testing, I ran the testsuite as usual, but I also ran some manual
completion tests under valgrind, and didn't get any reports about
leaked memory.
gdb/ChangeLog:
* completer.c (completion_tracker::completion_hash_entry): Define
new class.
(advance_to_filename_complete_word_point): Call
recompute_lowest_common_denominator.
(completion_tracker::completion_tracker): Call discard_completions
to setup the hash table.
(completion_tracker::discard_completions): Allow for being called
from the constructor, pass new equal function, and element deleter
when constructing the hash table. Initialise new class member
variables.
(completion_tracker::maybe_add_completion): Remove use of
m_entries_vec, and store more information into m_entries_hash.
(completion_tracker::recompute_lcd_visitor): New function, most
content taken from...
(completion_tracker::recompute_lowest_common_denominator):
...here, this now just visits each item in the hash calling the
above visitor.
(completion_tracker::build_completion_result): Remove use of
m_entries_vec, call recompute_lowest_common_denominator.
* completer.h (completion_tracker::have_completions): Remove use
of m_entries_vec.
(completion_tracker::completion_hash_entry): Declare new class.
(completion_tracker::recompute_lowest_common_denominator): Change
function signature.
(completion_tracker::recompute_lcd_visitor): Declare new function.
(completion_tracker::m_entries_vec): Delete.
(completion_tracker::m_entries_hash): Initialize to NULL.
(completion_tracker::m_lowest_common_denominator_valid): New
member variable.
(completion_tracker::m_lowest_common_denominator_max_length): New
member variable.
When running test-case gdb.opt/inline-locals.exp, I get:
...
Running src/gdb/testsuite/gdb.opt/inline-locals.exp ...
KPASS: gdb.opt/inline-locals.exp: info locals above bar 2 (PRMS gdb/xyz)
KPASS: gdb.opt/inline-locals.exp: info locals above bar 3 (PRMS gdb/xyz)
...
I've opened PR25695 - 'abstract and concrete variable listed both with "info
locals"' to refer to in the PRMS field, and this patch adds that reference.
Furthermore, I noticed that while I see KPASSes, given the problem description
the tests should actually be KFAILs. This patch also fixes that.
Tested on x86_64-linux. With gcc 7.5.0, I get 2 KFAILs. With clang 5.0.2,
the tests pass.
gdb/testsuite/ChangeLog:
2020-03-19 Tom de Vries <tdevries@suse.de>
* gdb.opt/inline-locals.exp: Add kfail PR number. Make kfail matching
more precise.
Alan Modra [Thu, 19 Mar 2020 05:03:03 +0000 (15:33 +1030)]
Don't use bfd.h in binutils/elfcomm.c
Better than warning about bfd types, just don't include bfd.h and
warn against including the header again.
* elfcomm.c: Don't include bfd.h or bucomm.h.
(program_name): Declare.
(process_archive_index_and_symbols): Replace bfd_boolean with int,
and substitute FALSE and TRUE.
(setup_archive, setup_nested_archive): Likewise.
* elfcomm.h: Likewise.
Kamil Rytarowski [Tue, 17 Mar 2020 14:07:39 +0000 (15:07 +0100)]
Inherit sh_nbsd_nat_target from nbsd_nat_target
gdb/ChangeLog:
* sh-nbsd-nat.c (sh_nbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* sh-nbsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Tom de Vries [Tue, 17 Mar 2020 07:56:36 +0000 (08:56 +0100)]
[gdb] Skip imports of c++ CUs
The DWARF standard appendix E.1 describes techniques that can be used for
compression and deduplication: DIEs can be factored out into a new compilation
unit, and referenced using DW_FORM_ref_addr.
Such a new compilation unit can either use a DW_TAG_compile_unit or
DW_TAG_partial_unit. If a DW_TAG_compile_unit is used, its contents is
evaluated by consumers as though it were an ordinary compilation unit. If a
DW_TAG_partial_unit is used, it's only considered by consumers in the context
of a DW_TAG_imported_unit.
An example of when DW_TAG_partial_unit is required is when the factored out
DIEs are not top-level, f.i. because they were children of a namespace. In
such a case the corresponding DW_TAG_imported_unit will occur as child of the
namespace.
In the case of factoring out DIEs from c++ compilation units, we can factor
out into a new DW_TAG_compile_unit, and no DW_TAG_imported_unit is required.
This begs the question how to interpret a top-level DW_TAG_imported_unit of a
c++ DW_TAG_compile_unit compilation unit. The semantics of
DW_TAG_imported_unit describe that the imported unit logically appears at the
point of the DW_TAG_imported_unit entry. But it's not clear what the effect
should be in this case, since all the imported DIEs are already globally
visible anyway, due to the use of DW_TAG_compile_unit.
So, skip top-level imports of c++ DW_TAG_compile_unit compilation units in
process_imported_unit_die.
Using the cc1 binary from PR23710 comment 1 and setting a breakpoint on do_rpo_vn:
...
$ gdb \
-batch \
-iex "maint set dwarf max-cache-age 316" \
-iex "set language c++" \
-ex "b do_rpo_vn" \
cc1
...
we get a 8.1% reduction in execution time, due to reducing the number of
partial symtabs expanded into full symtabs from 212 to 175.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-03-17 Tom de Vries <tdevries@suse.de>
PR gdb/23710
* dwarf2/read.h (struct dwarf2_per_cu_data): Add unit_type and lang
fields.
* dwarf2/read.c (process_psymtab_comp_unit): Initialize unit_type and lang
fields.
(process_imported_unit_die): Skip import of c++ CUs.
Tom Tromey [Tue, 17 Mar 2020 00:32:44 +0000 (18:32 -0600)]
Initialize base_value in pascal_object_print_value
The val_print removal series introduced a new possibly-uninitialized
warning in p-valprint.c. Examination of the code shows that the
warning does not indicate a real bug, so this patch silences the
warning by setting the variable in the catch clause of a try/catch.
(The obvious initialization did not work due to a "goto" in this
function.)
gdb/ChangeLog
2020-03-16 Tom Tromey <tom@tromey.com>
Anton Kolesov [Wed, 25 Oct 2017 18:51:54 +0000 (21:51 +0300)]
arc: Migrate to new target features
This patch replaces usage of target descriptions in ARC, where the whole
description is fixed in XML, with new target descriptions where XML describes
individual features, and GDB assembles those features into actual target
description.
v2:
Removed arc.c from ALLDEPFILES in gdb/Makefile.in.
Removed vim modeline from arc-tdep.c to have it in a separate patch.
Removed braces from one line "if/else".
Undid the type change for "jb_pc" (kept it as "int").
Joined the unnecessary line breaks into one line.
No more moving around arm targets in gdb/features/Makefile.
Changed pattern checking for ARC features from "arc/{aux,core}" to "arc/".
v3:
Added include gaurds to arc.h.
Added arc_read_description to _create_ target descriptions less.
v4:
Got rid of ARC_SYS_TYPE_NONE.
Renamed ARC_SYS_TYPE_INVALID to ARC_SYS_TYPE_NUM.
Fixed a few indentations/curly braces.
Converted arc_sys_type_to_str from a macro to an inline function.
gdb/ChangeLog:
2020-03-16 Anton Kolesov <anton.kolesov@synopsys.com>
Shahab Vahedi <shahab@synopsys.com>
* Makefile.in: Add arch/arc.o
* configure.tgt: Likewise.
* arc-tdep.c (arc_tdesc_init): Use arc_read_description.
(_initialize_arc_tdep): Don't initialize old target descriptions.
(arc_read_description): New function to cache target descriptions.
* arc-tdep.h (arc_read_description): Add proto type.
* arch/arc.c: New file.
* arch/arc.h: Likewise.
* features/Makefile: Replace old target descriptions with new.
* features/arc-arcompact.c: Remove.
* features/arc-arcompact.xml: Likewise.
* features/arc-v2.c: Likewise
* features/arc-v2.xml: Likewise
* features/arc/aux-arcompact.xml: New file.
* features/arc/aux-v2.xml: Likewise.
* features/arc/core-arcompact.xml: Likewise.
* features/arc/core-v2.xml: Likewise.
* features/arc/aux-arcompact.c: Generate.
* features/arc/aux-v2.c: Likewise.
* features/arc/core-arcompact.c: Likewise.
* features/arc/core-v2.c: Likewise.
* target-descriptions (maint_print_c_tdesc_cmd): Support ARC features.
Tom Tromey [Mon, 16 Mar 2020 21:00:52 +0000 (15:00 -0600)]
Fix dwarf2_name caching bug
PR gdb/25663 points out that dwarf2_name will cache a value in the
bcache and then return a substring. However, this substring return is
only done on the branch that caches the value -- so if the function is
called twice with the same arguments, it will return different values.
This patch fixes this problem.
This area is strange. We cache the entire demangled string, but only
return the suffix. I looked at caching just the suffix, but it turns
out that anonymous_struct_prefix assumes that the entire string is
stored. Also weird is that this code is demangling the linkage name
and then storing the demangled form back into the linkage name
attribute -- that seems bad, because what if some code wants to find
the actual linkage name?
Fixing these issues was non-trivial, though; and in the meantime this
patch seems like an improvement. Regression tested on x86-64
Fedora 30.
gdb/ChangeLog
2020-03-16 Tom Tromey <tromey@adacore.com>
PR gdb/25663:
* dwarf2/read.c (dwarf2_name): Strip leading namespaces after
putting value into bcache.
Simon Marchi [Mon, 16 Mar 2020 20:56:36 +0000 (16:56 -0400)]
gdb: define builtin long type to be 64 bits on amd64 Cygwin
On Windows x86-64 (when building with MinGW), the size of the "long"
type is 32 bits. amd64_windows_init_abi therefore does:
set_gdbarch_long_bit (gdbarch, 32);
This is also used when the chosen OS ABI is Cygwin, where the "long"
type is 64 bits. GDB therefore gets sizeof(long) wrong when using the
builtin long type:
$ ./gdb -nx --data-directory=data-directory -batch -ex "set architecture i386:x86-64" -ex "set osabi Cygwin" -ex "print sizeof(long)"
The target architecture is assumed to be i386:x86-64
$1 = 4
This patch makes GDB avoid setting the size of the long type to 32 bits
when using the Cygwin OS ABI. it will inherit the value set in
amd64_init_abi.
With this patch, I get:
$ ./gdb -nx --data-directory=data-directory -batch -ex "set architecture i386:x86-64" -ex "set osabi Cygwin" -ex "print sizeof(long)"
The target architecture is assumed to be i386:x86-64
$1 = 8
gdb/ChangeLog:
PR gdb/21500
* amd64-windows-tdep.c (amd64_windows_init_abi): Rename
to...
(amd64_windows_init_abi_common): ... this. Don't set size of
long type.
(amd64_windows_init_abi): New function.
(amd64_cygwin_init_abi): New function.
(_initialize_amd64_windows_tdep): Use amd64_cygwin_init_abi for
the Cygwin OS ABI.
* i386-windows-tdep.c (_initialize_i386_windows_tdep): Clarify
comment.
Simon Marchi [Mon, 16 Mar 2020 20:56:36 +0000 (16:56 -0400)]
gdb: select "Cygwin" OS ABI for Cygwin binaries
Before this patch, the "Windows" OS ABI is selected for all Windows
executables, including Cygwin ones. This patch makes GDB differentiate
Cygwin binaries from non-Cygwin ones, and selects the "Cygwin" OS ABI
for the Cygwin ones.
To check whether a Windows PE executable is a Cygwin one, we check the
library list in the .idata section, see if it contains "cygwin1.dll".
I had to add code to parse the .idata section, because BFD doesn't seem
to expose this information. BFD does parse this information, but only
to print it in textual form (function pe_print_idata):
(gdb) file some_mingw_x86_64_binary.exe
Reading symbols from some_mingw_x86_64_binary.exe...
(gdb) show osabi
The current OS ABI is "auto" (currently "Windows").
The default OS ABI is "GNU/Linux".
(gdb) file some_mingw_i386_binary.exe
Reading symbols from some_mingw_i386_binary.exe...
(gdb) show osabi
The current OS ABI is "auto" (currently "Windows").
The default OS ABI is "GNU/Linux".
(gdb) file some_cygwin_x86_64_binary.exe
Reading symbols from some_cygwin_x86_64_binary.exe...
(gdb) show osabi
The current OS ABI is "auto" (currently "Cygwin").
The default OS ABI is "GNU/Linux".
gdb/ChangeLog:
* windows-tdep.h (is_linked_with_cygwin_dll): New declaration.
* windows-tdep.c (CYGWIN_DLL_NAME): New.
(pe_import_directory_entry): New struct type.
(is_linked_with_cygwin_dll): New function.
* amd64-windows-tdep.c (amd64_windows_osabi_sniffer): Select
GDB_OSABI_CYGWIN if the BFD is linked with the Cygwin DLL.
* i386-windows-tdep.c (i386_windows_osabi_sniffer): Likewise.
Simon Marchi [Mon, 16 Mar 2020 20:56:35 +0000 (16:56 -0400)]
gdb: rename content of i386-windows-tdep.c, cygwin to windows
i386-cygwin-tdep.c has just been renamed to i386-windows-tdep.c, this
patch now renames everything in it that is not Cygwin-specific to
replace "cygwin" with "windows".
Note that I did not rename i386_cygwin_core_osabi_sniffer, since that
appears to be Cygwin-specific.
gdb/ChangeLog:
* i386-windows-tdep.c: Mass-rename "cygwin" to "windows", except
i386_cygwin_core_osabi_sniffer.
Simon Marchi [Mon, 16 Mar 2020 20:56:35 +0000 (16:56 -0400)]
gdb: rename i386-cygwin-tdep.c to i386-windows-tdep.c
Since this file contains things that apply not only to Cygwin binaries,
but also to non-Cygwin Windows binaries, I think it would make more
sense for it to be called i386-windows-tdep.c. It is analogous to
amd64-windows-tdep.c, which we already have.
Simon Marchi [Mon, 16 Mar 2020 20:56:34 +0000 (16:56 -0400)]
gdb: add Windows OS ABI
GDB currently uses the "Cygwin" OS ABI (GDB_OSABI_CYGWIN) for everything
related to Windows. If you build a GDB for a MinGW or Cygwin target, it
will have "Cygwin" as the default OS ABI in both cases (see
configure.tgt). If you load either a MinGW or Cygwin binary, the
"Cygwin" OS ABI will be selected in both cases.
This is misleading, because Cygwin binaries are a subset of the binaries
running on Windows. When building something with MinGW, the resulting
binary has nothing to do with Cygwin. Cygwin binaries are only special
in that they are Windows binaries that link to the cygwin1.dll library
(if my understanding is correct).
Looking at i386-cygwin-tdep.c, we can see that GDB does nothing
different when dealing with Cygwin binaries versus non-Cygwin Windows
binaries. However, there is at least one known bug which would require
us to make a distinction between the two OS ABIs, and that is the size
of the built-in "long" type on x86-64. On native Windows, this is 4,
whereas on Cygwin it's 8.
So, this patch adds a new OS ABI, "Windows", and makes GDB use it for
i386 and x86-64 PE executables, instead of the "Cygwin" OS ABI. A
subsequent patch will improve the OS ABI detection so that GDB
differentiates the non-Cygwin Windows binaries from the Cygwin Windows
binaries, and applies the "Cygwin" OS ABI for the latter.
The default OS ABI remains "Cygwin" for the GDBs built with a Cygwin
target.
I've decided to split the i386_cygwin_osabi_sniffer function in two,
I think it's cleaner to have a separate sniffer for Windows binaries and
Cygwin cores, each checking one specific thing.
gdb/ChangeLog:
* osabi.h (enum gdb_osabi): Add GDB_OSABI_WINDOWS.
* osabi.c (gdb_osabi_names): Add "Windows".
* i386-cygwin-tdep.c (i386_cygwin_osabi_sniffer): Return
GDB_OSABI_WINDOWS when the binary's target is "pei-i386".
(i386_cygwin_core_osabi_sniffer): New function, extracted from
i386_cygwin_osabi_sniffer.
(_initialize_i386_cygwin_tdep): Register OS ABI
GDB_OSABI_WINDOWS for i386.
* amd64-windows-tdep.c (amd64_windows_osabi_sniffer): Return
GDB_OSABI_WINDOWS when the binary's target is "pei-x86-64".
(_initialize_amd64_windows_tdep): Register OS ABI GDB_OSABI_WINDOWS
for x86-64.
* configure.tgt: Use GDB_OSABI_WINDOWS as the default OS ABI
when the target matches '*-*-mingw*'.
Simon Marchi [Mon, 16 Mar 2020 20:56:33 +0000 (16:56 -0400)]
gdb: recognize 64 bits Windows executables as Cygwin osabi
If I generate two Windows PE executables, one 32 bits and one 64 bits:
$ x86_64-w64-mingw32-gcc test.c -g3 -O0 -o test_64
$ i686-w64-mingw32-gcc test.c -g3 -O0 -o test_32
$ file test_64
test_64: PE32+ executable (console) x86-64, for MS Windows
$ file test_32
test_32: PE32 executable (console) Intel 80386, for MS Windows
When I load the 32 bits binary in my GNU/Linux-hosted GDB, the osabi is
correctly recognized as "Cygwin":
$ ./gdb --data-directory=data-directory -nx test_32
(gdb) show osabi
The current OS ABI is "auto" (currently "Cygwin").
When I load the 64 bits binary in GDB, the osabi is incorrectly
recognized as "GNU/Linux":
$ ./gdb --data-directory=data-directory -nx test_64
(gdb) show osabi
The current OS ABI is "auto" (currently "GNU/Linux").
The 32 bits one gets recognized by the i386_cygwin_osabi_sniffer
function, by its target name:
if (strcmp (target_name, "pei-i386") == 0)
return GDB_OSABI_CYGWIN;
The target name for the 64 bits binaries is "pei-x86-64". It doesn't
get recognized by any osabi sniffer, so GDB falls back on its default
osabi, "GNU/Linux".
This patch adds an osabi sniffer function for the Windows 64 bits
executables in amd64-windows-tdep.c. With it, the osabi is recognized
as "Cygwin", just like with the 32 bits binary.
Note that it may seems strange to have a binary generated by MinGW
(which has nothing to do with Cygwin) be recognized as a Cygwin binary.
This is indeed not accurate, but at the moment GDB uses the Cygwin for
everything Windows. Subsequent patches will add a separate "Windows" OS
ABI for Windows binaries that are not Cygwin binaries.
gdb/ChangeLog:
* amd64-windows-tdep.c (amd64_windows_osabi_sniffer): New
function.
(_initialize_amd64_windows_tdep): Register osabi sniffer.
Tom de Vries [Mon, 16 Mar 2020 13:39:07 +0000 (14:39 +0100)]
[gdb/testsuite] Add cache_verify option for gdb_caching_procs
Test-case gdb.base/gdb-caching-proc.exp tests whether procs declared using
gdb_caching_proc give the same results when called more than once.
While this tests consistency of the procs in the context of that test-case, it
doesn't test consistency across the call sites.
Add a local variable cache_verify to proc gdb_do_cache, that can be set to 1
to verify gdb_caching_proc consistency across the call sites.
Likewise, add a local variable cache_verify_proc to set to the name of the
gdb_caching_proc to verify. This can f.i. be used when changing an existing
proc into a gdb_caching_proc.
Tested on x86_64-linux, with cache_verify set to both 0 and 1.
gdb/testsuite/ChangeLog:
2020-03-16 Tom de Vries <tdevries@suse.de>
* lib/cache.exp (gdb_do_cache): Add and handle local variables
cache_verify and cache_verify_proc.
Alan Modra [Mon, 16 Mar 2020 00:01:45 +0000 (10:31 +1030)]
asan: readelf leak in hppa_process_unwind
This extracts code reading symbol tables into a common function that
tidies up after errors. I've also changed an error reporting multiple
string tables to an error on multiple symbol tables.
* readelf.c (get_symbols): New function.
(process_relocs, ia64_process_unwind, hppa_process_unwind),
(arm_process_unwind, get_symbol_for_build_attribute): Use it.
Alan Modra [Sun, 15 Mar 2020 22:24:16 +0000 (08:54 +1030)]
ubsan: shift exponent 70 is too large
* unwind-ia64.c (unw_decode_uleb128): Prevent overlarge shifts.
Detect shift overflows and check that terminating byte is found.
Print an error on a bad uleb128.
Alan Modra [Sun, 15 Mar 2020 22:14:38 +0000 (08:44 +1030)]
asan: alpha-vms: null dereference
* vms-alpha.c (dst_restore_location): Validate index into
dst_ptr_offsets array before accessing. Return status.
(dst_retrieve_location): Similarly, making "loc" parameter a
pointer to return value.
(_bfd_vms_slurp_etir): Update calls to above functions.
Tom de Vries [Sun, 15 Mar 2020 14:15:56 +0000 (15:15 +0100)]
[gdb/testsuite] Fix solib-list.exp test-case for exec with debug-info
Since commit a2fedca99c "Implement 'set/show exec-file-mismatch'.", I see the
following regression on openSUSE Leap 15.1:
...
FAIL: gdb.server/solib-list.exp: non-stop 0: target remote \
(got interactive prompt)
FAIL: gdb.server/solib-list.exp: non-stop 1: target remote \
(got interactive prompt)
...
The first FAIL in more detail:
...
(gdb) PASS: gdb.server/solib-list.exp: non-stop 0: file binfile
target remote localhost:2346
Remote debugging using localhost:2346
warning: Mismatch between current exec-file /data/gdb_versions/devel/build/\
gdb/testsuite/outputs/gdb.server/solib-list/solib-list
and automatically determined exec-file /lib64/ld-2.26.so
exec-file-mismatch handling is currently "ask"
Load new symbol table from "/lib64/ld-2.26.so"? (y or n) n
warning: loading /lib64/ld-2.26.so Not confirmed.
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
warning: File transfers from remote targets can be slow. \
Use "set sysroot" to access files locally instead.
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...
Reading /lib64/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target...
Reading /lib64/.debug/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote \
target...
Reading /data/gdb_versions/devel/install/lib64/debug//lib64/\
ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target...
Reading /data/gdb_versions/devel/install/lib64/debug/lib64/\
/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target...
Reading target:/data/gdb_versions/devel/install/lib64/debug/lib64/\
/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target...
(No debugging symbols found in target:/lib64/ld-linux-x86-64.so.2)
0x00007ffff7dd7ea0 in ?? ()
(gdb) FAIL: gdb.server/solib-list.exp: non-stop 0: target remote (got \
interactive prompt)
...
The commit introduces the "Load new symbol table from" question, and
gdb_test_multiple defaults to answering "no" and reporting the
"got interactive prompt" FAIL.
This FAIL is not seen on f.i. debian 10.2. The difference originates from the
fact that the solib-list executable has debug-info in the openSUSE case, while
it doesn't in the debian case.
We can prevent the failure on openSUSE by stripping the executable from
debug-info:
...
+ exec strip --strip-debug ${binfile}
...
The difference in behaviour is a bug or improvement opportunity in the
exec-file-mismatch, filed as PR25475.
This patch fixes the FAIL by handling the question in the test-case.
Tested on x86_64-linux.
Tested on x86_64-linux with the gdbserver part of the patch introducing the
test-case reverted to ensure that this still FAILs.
gdb/testsuite/ChangeLog:
2020-03-15 Tom de Vries <tdevries@suse.de>
* gdb.server/solib-list.exp: Handle
'Load new symbol table from "/lib64/ld-2.26.so"? (y or n)'.
Tom de Vries [Sun, 15 Mar 2020 09:43:43 +0000 (10:43 +0100)]
[gdb/testsuite] Fix check-read1 FAIL with gdb.base/maint.exp
When running test-case gdb.base/maint.exp with check-read1, I run into:
...
FAIL: gdb.base/maint.exp: (timeout) maint print objfiles
...
The FAIL happens because command output contains long lines like this:
...
file1 at $hex, file2 at $hex, ..., $file$n at $hex,
...
F.i., such a line for libc.so.debug contains 82000 chars.
Fix this this by reading long lines bit by bit.
Also, replace the testing of the command output formulated using a gdb_send
combined with gdb_expect-in-a-loop, with a regular gdb_test_multiple with
exp_continue.
Tested on x86_64-linux, with make targets check and check-read1.
gdb/testsuite/ChangeLog:
2020-03-15 Tom de Vries <tdevries@suse.de>
* gdb.base/maint.exp: Use exp_continue in long lines for "maint print
objfiles".
Tom Tromey [Sat, 14 Mar 2020 18:11:42 +0000 (12:11 -0600)]
Add C parser support for "restrict" and "_Atomic"
A user noticed that "watch -location" would fail with a "restrict"
pointer. The issue here is that if the DWARF mentions "restrict", gdb
will put this into the type name -- but then the C parser will not be
able to parse this type.
This patch adds support for "restrict" and "_Atomic" to the C parser.
C++ doesn't have "restrict", but does have some GCC extensions. The
type printer is changed to handle this difference as well, so that
watch expressions will work properly.
gdb/ChangeLog
2020-03-14 Tom Tromey <tom@tromey.com>
Kamil Rytarowski [Sat, 14 Mar 2020 15:54:42 +0000 (16:54 +0100)]
Inherit m68k_bsd_nat_target from nbsd_nat_target
gdb/ChangeLog:
* m68k-bsd-nat.c (m68k_bsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* m68k-bsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Kamil Rytarowski [Sat, 14 Mar 2020 15:05:24 +0000 (16:05 +0100)]
Inherit alpha_netbsd_nat_target from nbsd_nat_target
gdb/ChangeLog:
* alpha-bsd-nat.c (alpha_netbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* alpha-bsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Tom de Vries [Sat, 14 Mar 2020 14:48:26 +0000 (15:48 +0100)]
[gdb/testsuite] Fix check-read1 FAIL in attach-many-short-lived-threads.exp
When running test-case gdb.threads/attach-many-short-lived-threads.exp with
check-read1, I ran into:
...
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 1: \
no new threads (timeout)
...
Fix this by rewriting the gdb_test_multiple call using -lbl and exp_continue.
Tested on x86_64-linux, with make targets check and check-read1.
gdb/testsuite/ChangeLog:
2020-03-14 Tom de Vries <tdevries@suse.de>
* gdb.threads/attach-many-short-lived-threads.exp: Read "info threads"
result in line-by-line fashion.
Kamil Rytarowski [Sat, 14 Mar 2020 13:50:51 +0000 (14:50 +0100)]
Inherit arm_netbsd_nat_target from nbsd_nat_target
gdb/ChangeLog:
* arm-nbsd-nat.c (arm_netbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* arm-nbsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Kamil Rytarowski [Sat, 14 Mar 2020 12:21:58 +0000 (13:21 +0100)]
Inherit vax_bsd_nat_target from nbsd_nat_target
gdb/ChangeLog:
* vax-bsd-nat.c (vax_bsd_nat_target): Inherit from nbsd_nat_target
instead of inf_ptrace_target.
* vax-bsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Alan Modra [Sat, 14 Mar 2020 08:28:11 +0000 (18:58 +1030)]
Re: asan: more readelf leaks
In git commit fd486f32d15e I put some static variables used by
get_symbol_for_build_attribute in a file scope ba_cache struct. This
was to prevent leaks in get_symbol_for_build_attribute, and to tidy up
before readelf exited. The patch wasn't quite right though. When
readelf processes more than one file it was possible to double free
arrays allocated in get_symbol_for_build_attribute.
Alan Modra [Sat, 14 Mar 2020 01:20:57 +0000 (11:50 +1030)]
BFD_FAKE_SECTIONS formatting
After the ld non-contiguous memory support my regen of bfd-in2.h
didn't match exactly what was committed, so I took the opportunity to
line up all the comments.
Tom Tromey [Fri, 13 Mar 2020 23:39:52 +0000 (17:39 -0600)]
Change extension language pretty-printers to use value API
This changes the extension language pretty-printers to use the value
API.
Note that new functions were needed, for both Guile and Python.
Currently both languages always wrap values by removing the values
from the value chain. This makes sense to avoid strange behavior with
watchpoints, and to avoid excessive memory use. However, when
printing, it's important to leave the passed-in value untouched, in
case pretty-printing does nothing -- that way the caller can still
access it.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (do_val_print): Update.
* python/python-internal.h (gdbpy_apply_val_pretty_printer): Take
a struct value.
(value_to_value_object_no_release): Declare.
* python/py-value.c (value_to_value_object_no_release): New
function.
* python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Take a
struct value.
* guile/scm-value.c (vlscm_scm_from_value_no_release): New
function.
* guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer): Take
a struct value.
* guile/guile-internal.h (vlscm_scm_from_value_no_release):
Declare.
(gdbscm_apply_val_pretty_printer): Take a struct value.
* extension.h (apply_ext_lang_val_pretty_printer): Take a struct
value.
* extension.c (apply_ext_lang_val_pretty_printer): Take a struct
value.
* extension-priv.h (struct extension_language_ops)
<apply_val_pretty_printer>: Take a struct value.
* cp-valprint.c (cp_print_value): Create a struct value.
(cp_print_value): Update.
Tom Tromey [Fri, 13 Mar 2020 23:39:52 +0000 (17:39 -0600)]
Introduce ada_value_print_array
This adds ada_value_print_array, a value-based analogue of
ada_val_print_array. It also removes some unused parameters from a
couple of helper functions.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (val_print_packed_array_elements): Remove
bitoffset and val parameters. Call common_val_print.
(ada_val_print_string): Remove offset, address, and original_value
parameters.
(ada_val_print_array): Update.
(ada_value_print_array): New function.
(ada_value_print_1): Call it.
Tom Tromey [Fri, 13 Mar 2020 23:39:52 +0000 (17:39 -0600)]
Rewrite ada_value_print_inner
This rewrites ada_value_print_inner, introducing a new
ada_value_print_1, an analogue of ada_val_print_1. Because it was
simple to do, this also converts ada_val_print_gnat_array to be
valued-based and updates the uses.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_val_print_gnat_array): Take a struct value;
call common_val_print.
(ada_val_print_1): Update.
(ada_value_print_1): New function.
(ada_value_print_inner): Rewrite.
Tom Tromey [Fri, 13 Mar 2020 23:39:52 +0000 (17:39 -0600)]
Introduce cp_print_value_fields and c_value_print_struct
This adds cp_print_value_fields and c_value_print_struct, value-based
analogues of the corresponding val-printing functions. Note that the
Modula-2 printing code also calls cp_print_val_fields, and so is
updated to call the function function.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* m2-valprint.c (m2_value_print_inner): Use
cp_print_value_fields.
* cp-valprint.c (cp_print_value_fields): New function.
* c-valprint.c (c_value_print_struct): New function.
(c_value_print_inner): Use c_value_print_struct.
* c-lang.h (cp_print_value_fields): Declare.
Tom Tromey [Fri, 13 Mar 2020 23:39:52 +0000 (17:39 -0600)]
Rewrite c_value_print_inner
This rewrites c_value_print_inner, copying in the body of
c_val_print_inner and adusting as needed. This will form the base of
future changes to fully convert this to using the value-based API
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 13 Mar 2020 23:39:52 +0000 (17:39 -0600)]
Simplify generic_val_print_float
This changes generic_val_print_float not to call
val_print_scalar_formatted. This lets generic_value_print then use
value_print_scalar_formatted instead.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
projects / thirdparty / binutils-gdb.git / log
