gdb/ChangeLog:
* ppc-nbsd-nat.c (ppc_nbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* ppc-nbsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* hppa-nbsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* (store_registers): Likewise.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* ppc-nbsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* (store_registers): Likewise.
Unlike most other Operating Systems, NetBSD tracks both pid and lwp.
The process id on NetBSD is stored always in the pid field of ptid.
gdb/ChangeLog:
* inf-ptrace.h: Disable get_ptrace_pid on NetBSD.
* inf-ptrace.c: Likewise.
* (gdb_ptrace): Add.
* (inf_ptrace_target::resume): Update.
* (inf_ptrace_target::xfer_partial): Likewise.
* (inf_ptrace_peek_poke): Change argument `pid' to `ptid'.
* (inf_ptrace_peek_poke): Update.
I was doing some SVE tests on system QEMU and noticed quite a few failures
related to inferior function calls. Any attempt to do an inferior function
call would result in the following:
Unable to set VG register.: Success.
This happens because, after an inferior function call, GDB attempts to restore
the regcache state and updates the SVE register in order. Since the Z registers
show up before the VG register, VG is still INVALID by the time the first Z
register is being updated. So when executing the following code in
aarch64_sve_set_vq:
if (reg_buf->get_register_status (AARCH64_SVE_VG_REGNUM) != REG_VALID)
return false;
By returning false, we signal something is wrong, then we get to this:
/* First store vector length to the thread. This is done first to ensure the
ptrace buffers read from the kernel are the correct size. */
if (!aarch64_sve_set_vq (tid, regcache))
perror_with_name (_("Unable to set VG register."));
Ideally we'd always have a valid VG before attempting to set the Z registers,
but in this case the ordering of registers doesn't make that possible.
I considered reordering the registers to put VG before the Z registers, like
the DWARF numbering, but that would break backwards compatibility with
existing implementations. Also, the Z register numbering is pinned to the V
registers, and adding VG before Z would create a gap for non-SVE targets,
since we wouldn't be able to undefine VG for non-SVE targets.
As a compromise, it seems we can safely fetch the VG register value from
ptrace. The value in the kernel is likely the updated value anyway.
This patch fixed all the failures i saw in the testsuite and caused no further
regressions.
gdb/ChangeLog:
2020-03-19 Luis Machado <luis.machado@linaro.org>
* nat/aarch64-sve-linux-ptrace.c (aarch64_sve_set_vq): If vg is not
valid, fetch vg value from ptrace.
Add gdb_ptrace() that wraps the ptrace(2) API and correctly passes
the pid,lwp pair to the calls on NetBSD; and the result of
get_ptrace_pid() on other BSD Operating Systems.
gdb/ChangeLog:
* x86-bsd-nat.c (gdb_ptrace): New.
* (x86bsd_dr_set): Add new argument `ptid'.
* (x86bsd_dr_get, x86bsd_dr_set, x86bsd_dr_set_control,
x86bsd_dr_set_addr): Update.
In this commit:
commit 24ed6739b6
Date: Thu Jan 30 14:35:40 2020 +0000
gdb/remote: Restore support for 'S' stop reply packet
A regression was introduced such that the W and X packets would give a
warning in some cases. The warning was:
warning: multi-threaded target stopped without sending a thread-id, using first non-exited thread
This problem would arise when:
1. The multi-process extensions to the remote protocol were not
being used, and
2. The inferior has multiple threads.
In this case when the W (or X) packet arrives the ptid of the
stop_reply is set to null_ptid, then when we arrive in
process_stop_reply GDB spots that we have multiple non-exited theads,
but the stop event didn't specify a thread-id.
The problem with this is that the W (and X) packets are actually
process wide events, they apply to all threads. So not specifying a
thread-id is not a problem, in fact, the best these packets allow is
for the remote to specify a process-id, not a thread-id.
If we look at how the W (and X) packets deal with a specified
process-id, then what happens is GDB sets to stop_reply ptid to a
value which indicates all threads in the process, this is done by
creating a value `ptid_t (pid)`, which sets the pid field of the
ptid_t, but leaves the tid field as 0, indicating all threads.
So, this commit does the same thing for the case where there is not
process-id specified. In process_stop_reply we not distinguish
between stop events that apply to all threads, and those that apply to
only one. If the stop event applies to only one thread then we treat
it as before. If, however, the stop event applies to all threads,
then we find the first non-exited thread, and use the pid from this
thread to create a `ptid_t (pid)` value.
If the target has multiple inferiors, and receives a process wide
event without specifying a process-id GDB now gives this warning:
warning: multi-inferior target stopped without sending a process-id, using first non-exited inferior
gdb/ChangeLog:
* remote.c (remote_target::process_stop_reply): Handle events for
all threads differently.
gdb/testsuite/ChangeLog:
* gdb.server/exit-multiple-threads.c: New file.
* gdb.server/exit-multiple-threads.exp: New file.
Consider debugging the following C++ program:
struct object
{ int a; };
typedef object *object_p;
static int
get_value (object_p obj)
{
return obj->a;
}
int
main ()
{
object obj;
obj.a = 0;
return get_value (&obj);
}
Now in a GDB session:
(gdb) complete break get_value
break get_value(object*)
break get_value(object_p)
Or:
(gdb) break get_va<TAB>
(gdb) break get_value(object<RETURN>
Function "get_value(object" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
The reason this happens is that we add completions based on the
msymbol names and on the symbol names. For C++ both of these names
include the parameter list, however, the msymbol names have some
differences from the symbol names, for example:
+ typedefs are resolved,
+ whitespace rules are different around pointers,
+ the 'const' keyword is placed differently.
What this means is that the msymbol names and symbol names appear to
be completely different to GDB's completion tracker, and therefore to
readline when it offers the completions.
This commit builds on the previous commit which reworked the
completion_tracker class. It is now trivial to add a
remove_completion member function, this is then used along with
cp_canonicalize_string_no_typedefs to remove the msymbol aliases from
the completion tracker as we add the symbol names.
Now, for the above program GDB only presents a single completion for
'get_value', which is 'get_value(object_p)'.
It is still possible to reference the symbol using the msymbol name,
so a user can manually type out 'break get_value (object *)' if they
wish and will get the expected behaviour.
I did consider adding an option to make this alias exclusion optional,
in the end I didn't bother as I didn't think it would be very useful,
but I can easily add such an option if people think it would be
useful.
gdb/ChangeLog:
* completer.c (completion_tracker::remove_completion): Define new
function.
* completer.h (completion_tracker::remove_completion): Declare new
function.
* symtab.c (completion_list_add_symbol): Remove aliasing msymbols
when adding a C++ function symbol.
gdb/testsuite/ChangeLog:
* gdb.linespec/cp-completion-aliases.cc: New file.
* gdb.linespec/cp-completion-aliases.exp: New file.
Change-Id: Ie5c7c9fc8ecf973072cfb4a9650867104bf7f50c
In this commit I rewrite how the completion tracker tracks the
completions, and builds its lowest common denominator (LCD) string.
The LCD string is now built lazily when required, and we only track
the completions in one place, the hash table, rather than maintaining
a separate vector of completions.
The motivation for these changes is that the next commit will add the
ability to remove completions from the list, removing a completion
will invalidate the LCD string, so we need to keep hold of enough
information to recompute the LCD string as needed.
Additionally, keeping the completions in a vector makes removing a
completion expensive, so better to only keep the completions in the
hash table.
This commit doesn't add any new functionality itself, and there should
be no user visible changes after this commit.
For testing, I ran the testsuite as usual, but I also ran some manual
completion tests under valgrind, and didn't get any reports about
leaked memory.
gdb/ChangeLog:
* completer.c (completion_tracker::completion_hash_entry): Define
new class.
(advance_to_filename_complete_word_point): Call
recompute_lowest_common_denominator.
(completion_tracker::completion_tracker): Call discard_completions
to setup the hash table.
(completion_tracker::discard_completions): Allow for being called
from the constructor, pass new equal function, and element deleter
when constructing the hash table. Initialise new class member
variables.
(completion_tracker::maybe_add_completion): Remove use of
m_entries_vec, and store more information into m_entries_hash.
(completion_tracker::recompute_lcd_visitor): New function, most
content taken from...
(completion_tracker::recompute_lowest_common_denominator):
...here, this now just visits each item in the hash calling the
above visitor.
(completion_tracker::build_completion_result): Remove use of
m_entries_vec, call recompute_lowest_common_denominator.
* completer.h (completion_tracker::have_completions): Remove use
of m_entries_vec.
(completion_tracker::completion_hash_entry): Declare new class.
(completion_tracker::recompute_lowest_common_denominator): Change
function signature.
(completion_tracker::recompute_lcd_visitor): Declare new function.
(completion_tracker::m_entries_vec): Delete.
(completion_tracker::m_entries_hash): Initialize to NULL.
(completion_tracker::m_lowest_common_denominator_valid): New
member variable.
(completion_tracker::m_lowest_common_denominator_max_length): New
member variable.
Change-Id: I9d1db52c489ca0041b8959ca0d53b7d3af8aea72
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
Define gdb_ptrace() a wrapper function for ptrace(2) that properly passes
the pid,lwp pair on NetBSD and the result of get_ptrace_pid() for others.
gdb/ChangeLog:
* i386-bsd-nat.c (gdb_ptrace): New.
* (i386bsd_fetch_inferior_registers,
i386bsd_store_inferior_registers) Switch from pid_t to ptid_t.
* (i386bsd_fetch_inferior_registers,
i386bsd_store_inferior_registers) Use gdb_ptrace.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
Define gdb_ptrace() a wrapper function for ptrace(2) that properly passes
the pid,lwp pair on NetBSD and the result of get_ptrace_pid() for others.
gdb/ChangeLog:
* amd64-bsd-nat.c (gdb_ptrace): New.
* (amd64bsd_fetch_inferior_registers,
amd64bsd_store_inferior_registers) Switch from pid_t to ptid_t.
* (amd64bsd_fetch_inferior_registers,
amd64bsd_store_inferior_registers) Use gdb_ptrace.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
Define gdb_ptrace() a wrapper function for ptrace(2) that properly passes
the pid,lwp pair on NetBSD and the result of get_ptrace_pid() for others.
gdb/ChangeLog:
* sparc-nat.c (gdb_ptrace): New.
* sparc-nat.c (sparc_fetch_inferior_registers)
(sparc_store_inferior_registers) Remove obsolete comment.
* sparc-nat.c (sparc_fetch_inferior_registers)
(sparc_store_inferior_registers) Switch from pid_t to ptid_t.
* sparc-nat.c (sparc_fetch_inferior_registers)
(sparc_store_inferior_registers) Use gdb_ptrace.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* sh-nbsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* sh-nbsd-nat.c (store_registers): Likewise.
gdb/ChangeLog:
* sh-nbsd-nat.c (sh_nbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* sh-nbsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
procfs on NetBSD is optional and not recommended.
* nbsd-nat.c: Include <sys/types.h>, <sys/ptrace.h> and
<sys/sysctl.h>.
* nbsd-nat.c (nbsd_nat_target::pid_to_exec_file): Rewrite.
The DWARF standard appendix E.1 describes techniques that can be used for
compression and deduplication: DIEs can be factored out into a new compilation
unit, and referenced using DW_FORM_ref_addr.
Such a new compilation unit can either use a DW_TAG_compile_unit or
DW_TAG_partial_unit. If a DW_TAG_compile_unit is used, its contents is
evaluated by consumers as though it were an ordinary compilation unit. If a
DW_TAG_partial_unit is used, it's only considered by consumers in the context
of a DW_TAG_imported_unit.
An example of when DW_TAG_partial_unit is required is when the factored out
DIEs are not top-level, f.i. because they were children of a namespace. In
such a case the corresponding DW_TAG_imported_unit will occur as child of the
namespace.
In the case of factoring out DIEs from c++ compilation units, we can factor
out into a new DW_TAG_compile_unit, and no DW_TAG_imported_unit is required.
This begs the question how to interpret a top-level DW_TAG_imported_unit of a
c++ DW_TAG_compile_unit compilation unit. The semantics of
DW_TAG_imported_unit describe that the imported unit logically appears at the
point of the DW_TAG_imported_unit entry. But it's not clear what the effect
should be in this case, since all the imported DIEs are already globally
visible anyway, due to the use of DW_TAG_compile_unit.
So, skip top-level imports of c++ DW_TAG_compile_unit compilation units in
process_imported_unit_die.
Using the cc1 binary from PR23710 comment 1 and setting a breakpoint on do_rpo_vn:
...
$ gdb \
-batch \
-iex "maint set dwarf max-cache-age 316" \
-iex "set language c++" \
-ex "b do_rpo_vn" \
cc1
...
we get a 8.1% reduction in execution time, due to reducing the number of
partial symtabs expanded into full symtabs from 212 to 175.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-03-17 Tom de Vries <tdevries@suse.de>
PR gdb/23710
* dwarf2/read.h (struct dwarf2_per_cu_data): Add unit_type and lang
fields.
* dwarf2/read.c (process_psymtab_comp_unit): Initialize unit_type and lang
fields.
(process_imported_unit_die): Skip import of c++ CUs.
The val_print removal series introduced a new possibly-uninitialized
warning in p-valprint.c. Examination of the code shows that the
warning does not indicate a real bug, so this patch silences the
warning by setting the variable in the catch clause of a try/catch.
(The obvious initialization did not work due to a "goto" in this
function.)
gdb/ChangeLog
2020-03-16 Tom Tromey <tom@tromey.com>
* p-valprint.c (pascal_object_print_value): Initialize
base_value.
This patch replaces usage of target descriptions in ARC, where the whole
description is fixed in XML, with new target descriptions where XML describes
individual features, and GDB assembles those features into actual target
description.
v2:
Removed arc.c from ALLDEPFILES in gdb/Makefile.in.
Removed vim modeline from arc-tdep.c to have it in a separate patch.
Removed braces from one line "if/else".
Undid the type change for "jb_pc" (kept it as "int").
Joined the unnecessary line breaks into one line.
No more moving around arm targets in gdb/features/Makefile.
Changed pattern checking for ARC features from "arc/{aux,core}" to "arc/".
v3:
Added include gaurds to arc.h.
Added arc_read_description to _create_ target descriptions less.
v4:
Got rid of ARC_SYS_TYPE_NONE.
Renamed ARC_SYS_TYPE_INVALID to ARC_SYS_TYPE_NUM.
Fixed a few indentations/curly braces.
Converted arc_sys_type_to_str from a macro to an inline function.
gdb/ChangeLog:
2020-03-16 Anton Kolesov <anton.kolesov@synopsys.com>
Shahab Vahedi <shahab@synopsys.com>
* Makefile.in: Add arch/arc.o
* configure.tgt: Likewise.
* arc-tdep.c (arc_tdesc_init): Use arc_read_description.
(_initialize_arc_tdep): Don't initialize old target descriptions.
(arc_read_description): New function to cache target descriptions.
* arc-tdep.h (arc_read_description): Add proto type.
* arch/arc.c: New file.
* arch/arc.h: Likewise.
* features/Makefile: Replace old target descriptions with new.
* features/arc-arcompact.c: Remove.
* features/arc-arcompact.xml: Likewise.
* features/arc-v2.c: Likewise
* features/arc-v2.xml: Likewise
* features/arc/aux-arcompact.xml: New file.
* features/arc/aux-v2.xml: Likewise.
* features/arc/core-arcompact.xml: Likewise.
* features/arc/core-v2.xml: Likewise.
* features/arc/aux-arcompact.c: Generate.
* features/arc/aux-v2.c: Likewise.
* features/arc/core-arcompact.c: Likewise.
* features/arc/core-v2.c: Likewise.
* target-descriptions (maint_print_c_tdesc_cmd): Support ARC features.
PR gdb/25663 points out that dwarf2_name will cache a value in the
bcache and then return a substring. However, this substring return is
only done on the branch that caches the value -- so if the function is
called twice with the same arguments, it will return different values.
This patch fixes this problem.
This area is strange. We cache the entire demangled string, but only
return the suffix. I looked at caching just the suffix, but it turns
out that anonymous_struct_prefix assumes that the entire string is
stored. Also weird is that this code is demangling the linkage name
and then storing the demangled form back into the linkage name
attribute -- that seems bad, because what if some code wants to find
the actual linkage name?
Fixing these issues was non-trivial, though; and in the meantime this
patch seems like an improvement. Regression tested on x86-64
Fedora 30.
gdb/ChangeLog
2020-03-16 Tom Tromey <tromey@adacore.com>
PR gdb/25663:
* dwarf2/read.c (dwarf2_name): Strip leading namespaces after
putting value into bcache.
On Windows x86-64 (when building with MinGW), the size of the "long"
type is 32 bits. amd64_windows_init_abi therefore does:
set_gdbarch_long_bit (gdbarch, 32);
This is also used when the chosen OS ABI is Cygwin, where the "long"
type is 64 bits. GDB therefore gets sizeof(long) wrong when using the
builtin long type:
$ ./gdb -nx --data-directory=data-directory -batch -ex "set architecture i386:x86-64" -ex "set osabi Cygwin" -ex "print sizeof(long)"
The target architecture is assumed to be i386:x86-64
$1 = 4
This patch makes GDB avoid setting the size of the long type to 32 bits
when using the Cygwin OS ABI. it will inherit the value set in
amd64_init_abi.
With this patch, I get:
$ ./gdb -nx --data-directory=data-directory -batch -ex "set architecture i386:x86-64" -ex "set osabi Cygwin" -ex "print sizeof(long)"
The target architecture is assumed to be i386:x86-64
$1 = 8
gdb/ChangeLog:
PR gdb/21500
* amd64-windows-tdep.c (amd64_windows_init_abi): Rename
to...
(amd64_windows_init_abi_common): ... this. Don't set size of
long type.
(amd64_windows_init_abi): New function.
(amd64_cygwin_init_abi): New function.
(_initialize_amd64_windows_tdep): Use amd64_cygwin_init_abi for
the Cygwin OS ABI.
* i386-windows-tdep.c (_initialize_i386_windows_tdep): Clarify
comment.
Before this patch, the "Windows" OS ABI is selected for all Windows
executables, including Cygwin ones. This patch makes GDB differentiate
Cygwin binaries from non-Cygwin ones, and selects the "Cygwin" OS ABI
for the Cygwin ones.
To check whether a Windows PE executable is a Cygwin one, we check the
library list in the .idata section, see if it contains "cygwin1.dll".
I had to add code to parse the .idata section, because BFD doesn't seem
to expose this information. BFD does parse this information, but only
to print it in textual form (function pe_print_idata):
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/peXXigen.c;h=e42d646552a0ca1e856e082256cd3d943b54ddf0;hb=HEAD#l1261
Here's the relevant portion of the PE format documentation:
https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-idata-section
This page was also useful:
https://blog.kowalczyk.info/articles/pefileformat.html#9ccef823-67e7-4372-9172-045d7b1fb006
With this patch applied, this is what I get:
(gdb) file some_mingw_x86_64_binary.exe
Reading symbols from some_mingw_x86_64_binary.exe...
(gdb) show osabi
The current OS ABI is "auto" (currently "Windows").
The default OS ABI is "GNU/Linux".
(gdb) file some_mingw_i386_binary.exe
Reading symbols from some_mingw_i386_binary.exe...
(gdb) show osabi
The current OS ABI is "auto" (currently "Windows").
The default OS ABI is "GNU/Linux".
(gdb) file some_cygwin_x86_64_binary.exe
Reading symbols from some_cygwin_x86_64_binary.exe...
(gdb) show osabi
The current OS ABI is "auto" (currently "Cygwin").
The default OS ABI is "GNU/Linux".
gdb/ChangeLog:
* windows-tdep.h (is_linked_with_cygwin_dll): New declaration.
* windows-tdep.c (CYGWIN_DLL_NAME): New.
(pe_import_directory_entry): New struct type.
(is_linked_with_cygwin_dll): New function.
* amd64-windows-tdep.c (amd64_windows_osabi_sniffer): Select
GDB_OSABI_CYGWIN if the BFD is linked with the Cygwin DLL.
* i386-windows-tdep.c (i386_windows_osabi_sniffer): Likewise.
i386-cygwin-tdep.c has just been renamed to i386-windows-tdep.c, this
patch now renames everything in it that is not Cygwin-specific to
replace "cygwin" with "windows".
Note that I did not rename i386_cygwin_core_osabi_sniffer, since that
appears to be Cygwin-specific.
gdb/ChangeLog:
* i386-windows-tdep.c: Mass-rename "cygwin" to "windows", except
i386_cygwin_core_osabi_sniffer.
Since this file contains things that apply not only to Cygwin binaries,
but also to non-Cygwin Windows binaries, I think it would make more
sense for it to be called i386-windows-tdep.c. It is analogous to
amd64-windows-tdep.c, which we already have.
gdb/ChangeLog:
* i386-cygwin-tdep.c: Rename to...
* i386-windows-tdep.c: ... this.
* Makefile.in (ALL_TARGET_OBS): Rename i386-cygwin-tdep.c to
i386-windows-tdep.c.
* configure.tgt: Likewise.
GDB currently uses the "Cygwin" OS ABI (GDB_OSABI_CYGWIN) for everything
related to Windows. If you build a GDB for a MinGW or Cygwin target, it
will have "Cygwin" as the default OS ABI in both cases (see
configure.tgt). If you load either a MinGW or Cygwin binary, the
"Cygwin" OS ABI will be selected in both cases.
This is misleading, because Cygwin binaries are a subset of the binaries
running on Windows. When building something with MinGW, the resulting
binary has nothing to do with Cygwin. Cygwin binaries are only special
in that they are Windows binaries that link to the cygwin1.dll library
(if my understanding is correct).
Looking at i386-cygwin-tdep.c, we can see that GDB does nothing
different when dealing with Cygwin binaries versus non-Cygwin Windows
binaries. However, there is at least one known bug which would require
us to make a distinction between the two OS ABIs, and that is the size
of the built-in "long" type on x86-64. On native Windows, this is 4,
whereas on Cygwin it's 8.
So, this patch adds a new OS ABI, "Windows", and makes GDB use it for
i386 and x86-64 PE executables, instead of the "Cygwin" OS ABI. A
subsequent patch will improve the OS ABI detection so that GDB
differentiates the non-Cygwin Windows binaries from the Cygwin Windows
binaries, and applies the "Cygwin" OS ABI for the latter.
The default OS ABI remains "Cygwin" for the GDBs built with a Cygwin
target.
I've decided to split the i386_cygwin_osabi_sniffer function in two,
I think it's cleaner to have a separate sniffer for Windows binaries and
Cygwin cores, each checking one specific thing.
gdb/ChangeLog:
* osabi.h (enum gdb_osabi): Add GDB_OSABI_WINDOWS.
* osabi.c (gdb_osabi_names): Add "Windows".
* i386-cygwin-tdep.c (i386_cygwin_osabi_sniffer): Return
GDB_OSABI_WINDOWS when the binary's target is "pei-i386".
(i386_cygwin_core_osabi_sniffer): New function, extracted from
i386_cygwin_osabi_sniffer.
(_initialize_i386_cygwin_tdep): Register OS ABI
GDB_OSABI_WINDOWS for i386.
* amd64-windows-tdep.c (amd64_windows_osabi_sniffer): Return
GDB_OSABI_WINDOWS when the binary's target is "pei-x86-64".
(_initialize_amd64_windows_tdep): Register OS ABI GDB_OSABI_WINDOWS
for x86-64.
* configure.tgt: Use GDB_OSABI_WINDOWS as the default OS ABI
when the target matches '*-*-mingw*'.
I think it makes sense to have it there instead of in the catch-all
defs.h.
gdb/ChangeLog:
* defs.h (enum gdb_osabi): Move to...
* osabi.h (enum gdb_osabi): ... here.
* gdbarch.sh: Include osabi.h in gdbarch.h.
* gdbarch.h: Re-generate.
If I generate two Windows PE executables, one 32 bits and one 64 bits:
$ x86_64-w64-mingw32-gcc test.c -g3 -O0 -o test_64
$ i686-w64-mingw32-gcc test.c -g3 -O0 -o test_32
$ file test_64
test_64: PE32+ executable (console) x86-64, for MS Windows
$ file test_32
test_32: PE32 executable (console) Intel 80386, for MS Windows
When I load the 32 bits binary in my GNU/Linux-hosted GDB, the osabi is
correctly recognized as "Cygwin":
$ ./gdb --data-directory=data-directory -nx test_32
(gdb) show osabi
The current OS ABI is "auto" (currently "Cygwin").
When I load the 64 bits binary in GDB, the osabi is incorrectly
recognized as "GNU/Linux":
$ ./gdb --data-directory=data-directory -nx test_64
(gdb) show osabi
The current OS ABI is "auto" (currently "GNU/Linux").
The 32 bits one gets recognized by the i386_cygwin_osabi_sniffer
function, by its target name:
if (strcmp (target_name, "pei-i386") == 0)
return GDB_OSABI_CYGWIN;
The target name for the 64 bits binaries is "pei-x86-64". It doesn't
get recognized by any osabi sniffer, so GDB falls back on its default
osabi, "GNU/Linux".
This patch adds an osabi sniffer function for the Windows 64 bits
executables in amd64-windows-tdep.c. With it, the osabi is recognized
as "Cygwin", just like with the 32 bits binary.
Note that it may seems strange to have a binary generated by MinGW
(which has nothing to do with Cygwin) be recognized as a Cygwin binary.
This is indeed not accurate, but at the moment GDB uses the Cygwin for
everything Windows. Subsequent patches will add a separate "Windows" OS
ABI for Windows binaries that are not Cygwin binaries.
gdb/ChangeLog:
* amd64-windows-tdep.c (amd64_windows_osabi_sniffer): New
function.
(_initialize_amd64_windows_tdep): Register osabi sniffer.
A user noticed that "watch -location" would fail with a "restrict"
pointer. The issue here is that if the DWARF mentions "restrict", gdb
will put this into the type name -- but then the C parser will not be
able to parse this type.
This patch adds support for "restrict" and "_Atomic" to the C parser.
C++ doesn't have "restrict", but does have some GCC extensions. The
type printer is changed to handle this difference as well, so that
watch expressions will work properly.
gdb/ChangeLog
2020-03-14 Tom Tromey <tom@tromey.com>
* c-typeprint.c (cp_type_print_method_args): Print "__restrict__"
for C++.
(c_type_print_modifier): Likewise. Add "language" parameter.
(c_type_print_varspec_prefix, c_type_print_base_struct_union)
(c_type_print_base_1): Update.
* type-stack.h (enum type_pieces) <tp_atomic, tp_restrict>: New
constants.
* type-stack.c (type_stack::insert): Handle tp_atomic and
tp_restrict.
(type_stack::follow_type_instance_flags): Likewise.
(type_stack::follow_types): Likewise. Merge type-following code.
* c-exp.y (RESTRICT, ATOMIC): New tokens.
(space_identifier, cv_with_space_id)
(const_or_volatile_or_space_identifier_noopt)
(const_or_volatile_or_space_identifier): Remove.
(single_qualifier, qualifier_seq_noopt, qualifier_seq): New
rules.
(ptr_operator, typebase): Update.
(enum token_flag) <FLAG_C>: New constant.
(ident_tokens): Add "restrict", "__restrict__", "__restrict", and
"_Atomic".
(lex_one_token): Handle FLAG_C.
gdb/testsuite/ChangeLog
2020-03-14 Tom Tromey <tom@tromey.com>
* gdb.base/cvexpr.exp: Add test for _Atomic and restrict.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* m68k-bsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* m68k-bsd-nat.c (store_registers): Likewise.
gdb/ChangeLog:
* m68k-bsd-nat.c (m68k_bsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* m68k-bsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* m68k-bsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* alpha-bsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* alpha-bsd-nat.c (store_registers): Likewise.
gdb/ChangeLog:
* alpha-bsd-nat.c (alpha_netbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* alpha-bsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* alpha-bsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
gdb/ChangeLog:
* arm-nbsd-nat.c (arm_netbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* arm-nbsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
NetBSD ptrace(2) PT_GETDBREGS/PT_SETDBREGS accepts thread id (LWP)
as the 4th argument for threads.
gdb/ChangeLog:
* x86-bsd-nat.c (x86bsd_dr_get): New variable lwp and pass
it to the ptrace call.
* x86-bsd-nat.c (x86bsd_dr_set): Likewise.
ptrace(2) PT_GETREGS/PT_SETREGS accepts thread id (LWP) as the 4th
argument for threads.
gdb/ChangeLog:
* vax-bsd-nat.c (vaxbsd_supply_gregset): New variable lwp and pass
it to the ptrace call.
* vax-bsd-nat.c (vaxbsd_collect_gregset): Likewise.
gdb/ChangeLog:
* vax-bsd-nat.c (vax_bsd_nat_target): Inherit from nbsd_nat_target
instead of inf_ptrace_target.
* vax-bsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* mips-nbsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* ppc-nbsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* vax-bsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
This changes the extension language pretty-printers to use the value
API.
Note that new functions were needed, for both Guile and Python.
Currently both languages always wrap values by removing the values
from the value chain. This makes sense to avoid strange behavior with
watchpoints, and to avoid excessive memory use. However, when
printing, it's important to leave the passed-in value untouched, in
case pretty-printing does nothing -- that way the caller can still
access it.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (do_val_print): Update.
* python/python-internal.h (gdbpy_apply_val_pretty_printer): Take
a struct value.
(value_to_value_object_no_release): Declare.
* python/py-value.c (value_to_value_object_no_release): New
function.
* python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Take a
struct value.
* guile/scm-value.c (vlscm_scm_from_value_no_release): New
function.
* guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer): Take
a struct value.
* guile/guile-internal.h (vlscm_scm_from_value_no_release):
Declare.
(gdbscm_apply_val_pretty_printer): Take a struct value.
* extension.h (apply_ext_lang_val_pretty_printer): Take a struct
value.
* extension.c (apply_ext_lang_val_pretty_printer): Take a struct
value.
* extension-priv.h (struct extension_language_ops)
<apply_val_pretty_printer>: Take a struct value.
* cp-valprint.c (cp_print_value): Create a struct value.
(cp_print_value): Update.
This converts print_field_values to use the value-based API, by having
it call common_val_print rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (print_field_values): Call common_val_print.
This adds ada_value_print_array, a value-based analogue of
ada_val_print_array. It also removes some unused parameters from a
couple of helper functions.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (val_print_packed_array_elements): Remove
bitoffset and val parameters. Call common_val_print.
(ada_val_print_string): Remove offset, address, and original_value
parameters.
(ada_val_print_array): Update.
(ada_value_print_array): New function.
(ada_value_print_1): Call it.
This converts ada_value_print to the value-based API by using
common_val_print rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_value_print): Use common_val_print.
This converts ada_val_print_ref to the value-based API by using
common_val_print rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_val_print_ref): Use common_val_print.
This adds ada_value_print_num, a value-based analogue of
ada_val_print_num.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_value_print_num): New function.
(ada_value_print_1): Use it.
This rewrites the TYPE_CODE_FLT case in ada_value_print_1 to be purely
value-based.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_value_print_1) <TYPE_CODE_FLT>: Rewrite.
This adds ada_value_print_ptr, a value-based analogue of
ada_val_print_ptr.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_value_print_ptr): New function.
(ada_value_print_1): Use it.
This rewrites ada_value_print_inner, introducing a new
ada_value_print_1, an analogue of ada_val_print_1. Because it was
simple to do, this also converts ada_val_print_gnat_array to be
valued-based and updates the uses.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_val_print_gnat_array): Take a struct value;
call common_val_print.
(ada_val_print_1): Update.
(ada_value_print_1): New function.
(ada_value_print_inner): Rewrite.
This adds cp_print_value, a value-based analogue of cp_print_val, and
changes cp_print_value_fields to use it.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* cp-valprint.c (cp_print_value_fields): Update.
(cp_print_value): New function.
This adds cp_print_value_fields and c_value_print_struct, value-based
analogues of the corresponding val-printing functions. Note that the
Modula-2 printing code also calls cp_print_val_fields, and so is
updated to call the function function.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* m2-valprint.c (m2_value_print_inner): Use
cp_print_value_fields.
* cp-valprint.c (cp_print_value_fields): New function.
* c-valprint.c (c_value_print_struct): New function.
(c_value_print_inner): Use c_value_print_struct.
* c-lang.h (cp_print_value_fields): Declare.
This adds c_value_print_array, a value-based analogue of
c_val_print_array.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print_array): New function.
(c_value_print_inner): Use it.
This adds c_value_print_memberptr, a value-based analogue of
c_val_print_memberptr.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print_memberptr): New function.
(c_value_print_inner): Use it.
This adds c_value_print_int, a value-based analogue of
c_val_print_int.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print_int): New function.
(c_value_print_inner): Use it.
This adds c_value_print_ptr, a value-based analogue of
c_val_print_ptr.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print_ptr): New function.
(c_value_print_inner): Use it.
This rewrites c_value_print_inner, copying in the body of
c_val_print_inner and adusting as needed. This will form the base of
future changes to fully convert this to using the value-based API
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print_inner): Rewrite.
This adds generic_value_print_complex, a value-based analogue of
generic_val_print_complex.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print_complex): New function.
(generic_value_print): Use it.
This changes generic_val_print_float not to call
val_print_scalar_formatted. This lets generic_value_print then use
value_print_scalar_formatted instead.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_val_print_float): Don't call
val_print_scalar_formatted.
(generic_val_print, generic_value_print): Update.
This adds generic_value_print_char, a value-based analogue of
generic_val_print_char.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print_char): New function
(generic_value_print): Use it.
This adds generic_value_print_int, a value-based analogue of
generic_val_print_int.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print_int): New function.
(generic_value_print): Use it.
This adds generic_value_print_bool, a value-based analogue of
generic_val_print_bool.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print_bool): New function.
(generic_value_print): Use it.
This removes the call to val_print_scalar_formatted from
generic_val_print_func, allowing generic_value_print to call the
value-based variant instead.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_val_print_func): Simplify.
(generic_val_print, generic_value_print): Update.
This remove generic_val_print_flags in favor of using the value-based
API where possible.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_val_print_flags): Remove.
(generic_val_print, generic_value_print): Update.
(val_print_type_code_flags): Add original_value parameter.
This removes a call to val_print_scalar_formatted from
generic_val_print_enum, preferring to do the work in the callers.
This lets generic_value_print use the value-based API.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_val_print): Update.
(generic_value_print): Update.
* valprint.c (generic_val_print_enum): Don't call
val_print_scalar_formatted.
This introduces generic_value_print_ptr, a value-based analogue of
generic_val_print_ptr, and changes generic_value_print to use it.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print): Call generic_value_print_ptr.
* valprint.c (generic_value_print_ptr): New function.
This rewrites generic_value_print, by copying in the body of
generic_val_print and making the needed adjustments.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print): Rewrite.
This finishes the conversion of Pascal to the value-based API, by
introducing two more value-based analogues of existing val-print
functions.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* p-valprint.c (pascal_object_print_value_fields)
(pascal_object_print_value): New functions.
This rewrites pascal_value_print_inner, copying in the body of
pascal_val_print_inner and adusting as needed. This will form the
base of future changes to fully convert this to using the value-based
API.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* p-valprint.c (pascal_value_print_inner): Rewrite.
This finishes the conversion of the Fortran printing code to the
value-based API. The body of f_val_print is copied into
f_value_print_innner, and then modified as needed to use the value
API.
Note that not all calls must be updated. For example, f77_print_array
remains "val-like", because it does not result in any calls to
val_print (f77_print_array_1 calls common_val_print, which is
nominally value-based).
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* f-valprint.c (f_value_print_innner): Rewrite.
This finishes the conversion of Modula-2 printing to the value-based
API. It does so by copying the body of m2_val_print into
m2_value_print_inner, and then introducing new functions as needed to
use the value API.
The "val_" API code continues to exist, because it's still possible
for it to be called via some paths. This code will all be removed at
the end of the series.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* m2-valprint.c (m2_print_unbounded_array): New overload.
(m2_print_unbounded_array): Update.
(m2_print_array_contents): Take a struct value.
(m2_value_print_inner): Rewrite.
As with Rust and Go, it was straightforward to convert D to the
value-based API directly.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* d-valprint.c (dynamic_array_type): Call d_value_print_inner.
(d_value_print_inner): New function.
* d-lang.h (d_value_print_inner): Declare.
* d-lang.c (d_language_defn): Use d_value_print_inner.
This introduces go_value_print_inner, a modified copy of go_val_print.
Unlike some of the other languages, Go was straightforward to convert
to the value-based API all at once, so this patch takes that approach.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* go-valprint.c (go_value_print_inner): New function.
* go-lang.h (go_value_print_inner): Declare.
* go-lang.c (go_language_defn): Use go_value_print_inner.
For Rust, it was simple to convert the printing code to the
value-based API all at once.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* rust-lang.c (val_print_struct, rust_print_enum): Use the value
API.
(rust_val_print): Rewrite.
(rust_value_print_inner): New function, from rust_val_print.
(rust_language_defn): Use rust_value_print_inner.
This introduces c_value_print_inner, which implements the
la_value_print_inner method for the C family of languages. In this
patch, it is just a simple wrapper of c_val_print. However,
subsequent patches will convert it to use the value API. The
transformation is done this way to make each patch easier to review.
Future patches will apply this same treatment to other languages as
well.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* opencl-lang.c (opencl_language_defn): Use c_value_print_inner.
* objc-lang.c (objc_language_defn): Use c_value_print_inner.
* c-valprint.c (c_value_print_inner): New function.
* c-lang.h (c_value_print_inner): Declare.
* c-lang.c (c_language_defn, cplus_language_defn)
(asm_language_defn, minimal_language_defn): Use
c_value_print_inner.
pascal_object_print_value_fields is only needed in p-valprint.c, so
make it static.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* p-valprint.c (pascal_object_print_value_fields): Now static.
* p-lang.h (pascal_object_print_value_fields): Don't declare.
This slightly simplifies c_val_print_array by moving a variable to a
more inner scope and removing a dead assignment.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_val_print_array): Simplify.
This introduces value_print_array_elements, which is an analogue of
val_print_array_elements that uses the value API.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (value_print_array_elements): New function.
* valprint.h (value_print_array_elements): Declare.
A couple of spots could be easily converted to use
value_print_scalar_formatted. This patch makes this change.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* printcmd.c (print_formatted): Use value_print_scalar_formatted.
* mips-tdep.c (mips_print_register): Use
value_print_scalar_formatted.
This introduces a value_print_scalar_formatted, which is an analogue
of val_print_scalar_formatted that uses the value API.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.h (value_print_scalar_formatted): Declare.
* valprint.c (value_print_scalar_formatted): New function.
This introduces generic_value_print, which is a value-based analogue
to generic_val_print. For now this is unused and simply calls
generic_val_print, but subsequent patches will both change this
function to work using the value API directly, and convert callers of
generic_val_print to call this instead.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.h (generic_value_print): Declare.
* valprint.c (generic_value_print): New function.
The plan for removing val_print is, essentially, to first duplicate
printing code as needed to use the value API; and then remove the
val_print code. This makes it possible to do the changes
incrementally while keeping everything working.
This adds a new la_value_print_inner function pointer to struct
language_defn. Eventually this will replace la_val_print. This patch
also changes printing to prefer this API, when available -- but no
language defines it yet.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (do_val_print): Call la_value_print_inner, if
available.
* rust-lang.c (rust_language_defn): Update.
* p-lang.c (pascal_language_defn): Update.
* opencl-lang.c (opencl_language_defn): Update.
* objc-lang.c (objc_language_defn): Update.
* m2-lang.c (m2_language_defn): Update.
* language.h (struct language_defn) <la_value_print_inner>: New
member.
* language.c (unknown_language_defn, auto_language_defn): Update.
* go-lang.c (go_language_defn): Update.
* f-lang.c (f_language_defn): Update.
* d-lang.c (d_language_defn): Update.
* c-lang.c (c_language_defn, cplus_language_defn)
(asm_language_defn, minimal_language_defn): Update.
* ada-lang.c (ada_language_defn): Update.
This changes c_value_print to call common_val_print. This is more
complicated than the usual sort of common_val_print change, due to the
handling of RTTI.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print): Use common_val_print.
gdb/testsuite/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* gdb.base/printcmds.exp (test_print_strings): Add regression
test.
* gdb.base/printcmds.c (charptr): New typedef.
(teststring2): New global.
This changes a spot in cp-valprint.c to use common_val_print rather
than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* cp-valprint.c (cp_print_static_field): Use common_val_print.
This changes a couple spots in f-valprint.c to use common_val_print
rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* f-valprint.c (f77_print_array_1, f_val_print): Use
common_val_print.
This changes some spots in riscv-tdep.c to use common_val_print rather
than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* riscv-tdep.c (riscv_print_one_register_info): Use
common_val_print.
This changes a spot in mi-main.c to use common_val_print rather than
val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* mi/mi-main.c (output_register): Use common_val_print.
This changes some spots in infcmd.c to use common_val_print (which,
despite its name, is a value-based API) rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* infcmd.c (default_print_one_register_info): Use
common_val_print.
A (much) later patch will remove the call to value_check_printable
from common_val_print. This will needed to preserve some details of
how optimized-out structures are printed.
However, doing this will also break dw2-op-out-param.exp. Making the
change causes "bt" to print:
However, the test wants to see:
... operand2=<optimized out>
That is, a wholly-optimized out structure should not print its fields.
So, this patch introduces a new common_val_print_checked, which calls
value_check_printable first, and then arranges to use it in the one
spot that affects the test suite.
I was not completely sure if it would be preferable to change the
test. However, I reasoned that, assuming this output was intentional
in the first place, in a backtrace space is at a premium and so this
is a reasonable approach. In other spots calling common_val_print,
this behavior is probably unintended, or at least a "don't care".
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.h (common_val_print_checked): Declare.
* valprint.c (common_val_print_checked): New function.
* stack.c (print_frame_arg): Use common_val_print_checked.
This changes val_print and common_val_print to use a new helper
function. A theme in the coming patches is that calls to val_print
itself should be removed. This is the first such patch; at the end of
the series, we'll remove val_print and simplify do_val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (do_val_print): New function, from val_print.
(val_print): Use do_val_print.
(common_val_print): Use do_val_print.
Switching the low-level printing to use the value API means we will be
using more temporary values. This adds a scoped_value_mark to
value_print, so that these intermediates are destroyed in a timely
way.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (value_print): Use scoped_value_mark.
Consider test-case gdb.dwarf2/imported-unit.exp.
It contains a CU with type int:
...
<0><129>: Abbrev Number: 2 (DW_TAG_compile_unit)
<12a> DW_AT_language : 4 (C++)
<12b> DW_AT_name : imported_unit.c
<1><13b>: Abbrev Number: 3 (DW_TAG_base_type)
<13c> DW_AT_byte_size : 4
<13d> DW_AT_encoding : 5 (signed)
<13e> DW_AT_name : int
...
which is imported in another CU:
...
<0><d2>: Abbrev Number: 2 (DW_TAG_compile_unit)
<d3> DW_AT_language : 4 (C++)
<d4> DW_AT_name : <artificial>
<1><e1>: Abbrev Number: 3 (DW_TAG_imported_unit)
<e2> DW_AT_import : <0x129> [Abbrev Number: 2]
...
However, if we print the partial symbols:
...
$ gdb -batch imported-unit -ex "maint print psymbols"
...
we see type int both in the importing CU:
...
Partial symtab for source file <artificial>@0xc7 (object 0x29f9b80)
...
Depends on 1 other partial symtabs.
0 0x2a24240 imported_unit.c
Global partial symbols:
`main', function, 0x4004b2
Static partial symbols:
`int', type, 0x0
...
and in the imported CU:
...
Partial symtab for source file imported_unit.c (object 0x2a24240)
...
Depends on 0 other partial symtabs.
Shared partial symtab with user 0x29f9b80
Static partial symbols:
`int', type, 0x0
...
This is an artefact resulting from the fact that all CUs in an objfile
share the same storage array for static partial symbols (and another array for
global partial symbols), using a range to describe their symbols.
Then when scanning the partial symbols of a CU and encountering an import, either:
- the referred CU has not been parsed yet, and will be parsed, and the range of
static partial symbols of the referred CU will be a subrange of the range of
static partial symbols of this CU, or
- the referred CU has already been parsed, and the range of static partial
symbols of the referred CU will not be a subrange of the range of static
partial symbols of this CU.
This is inconsistent handling, and confuses the notion of a symbol belonging to
a single symtab.
Furthermore, it might slow down searches, given that the symbol needs to be
skipped twice.
Finally, the same issue holds for global partial symbols, where the range of a
CU is sorted after parsing is finished. Obviously sorting the range of a CU
may invalidate subranges, effectively moving symbols in and out of imported
CUs.
Fix this for both static and global partial symbols, by gathering partial
symbols in a per-CU vector, and adding those symbols to the per-objfile
storage only once complete.
Tested on x86_64-linux, with native and board cc-with-dwz and cc-with-dwz-m.
gdb/ChangeLog:
2020-03-13 Tom de Vries <tdevries@suse.de>
PR symtab/25646
* psymtab.c (partial_symtab::partial_symtab): Don't set
globals_offset and statics_offset. Push element onto
current_global_psymbols and current_static_psymbols stacks.
(concat): New function.
(end_psymtab_common): Set globals_offset and statics_offset. Pop
element from current_global_psymbols and current_static_psymbols
stacks. Concat popped elements to global_psymbols and
static_symbols.
(add_psymbol_to_list): Use current_global_psymbols and
current_static_psymbols stacks.
* psymtab.h (class psymtab_storage): Add current_global_psymbols and
current_static_psymbols fields.
gdb/testsuite/ChangeLog:
2020-03-13 Tom de Vries <tdevries@suse.de>
PR symtab/25646
* gdb.dwarf2/imported-unit.exp: Add test.
There are no more callers to deprecated_add_core_fns, now that I have
removed the usage from CRIS and ARM/NetBSD. So this patch cleans up
all the related code and makes corelow.c a lot more readable.
gdb/ChangeLog:
2020-03-12 Christian Biesinger <cbiesinger@google.com>
* corelow.c (sniff_core_bfd): Remove.
(class core_target) <m_core_vec>: Remove.
(core_target::core_target): Update.
(core_file_fns): Remove.
(deprecated_add_core_fns): Remove.
(default_core_sniffer): Remove.
(sniff_core_bfd): Remove.
(default_check_format): Remove.
(gdb_check_format): Remove.
(core_target_open): Update.
(core_target::get_core_register_section): Update.
(get_core_registers_cb): Update.
(core_target::fetch_registers): Update.
* gdbcore.h (struct core_fns): Remove.
(deprecated_add_core_fns): Remove.
(default_core_sniffer): Remove.
(default_check_format): Remove.
Some arm-tdep.c data structures use a bfd_vma. A couple of spots will
warn about an implicit narrowing cast when building a gdb where
CORE_ADDR is 64-bit but bfd_vma is 32-bit.
This patch silences these warnings by changing the types in question
to CORE_ADDR.
gdb/ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* arm-tdep.c (struct arm_mapping_symbol) <value>: Now a
CORE_ADDR.
(struct arm_exidx_entry) <addr>: Now a CORE_ADDR.
A few spots in gdb use sprintf_vma to print a CORE_ADDR. This will
fail on a 32-bit build once CORE_ADDR is always a 64-bit type.
This patch replaces these calls with phex instead.
gdb/ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* remote.c (remote_target::download_tracepoint)
(remote_target::enable_tracepoint)
(remote_target::disable_tracepoint): Use phex, not sprintf_vma.
* breakpoint.c (print_recreate_masked_watchpoint): Use phex, not
sprintf_vma.
symfile-mem.c has some assertions about the size of various types, to
ensure that gdb and BFD don't get out of sync in a way that would
cause bugs.
Once CORE_ADDR is always 64-bit, one of these assertions can fail for
a 32-bit BFD build. However, the real requirement here is just that
CORE_ADDR is wider -- because this code promotes a bfd_vma to a
CORE_ADDR.
This patch corrects the assert.
gdb/ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* symfile-mem.c: Update CORE_ADDR size assert.
The selftest.m4 file is used by gdb, gdbserver and gdbsupport, I think
it belongs in gdbsupport.
gdb/ChangeLog:
* selftest.m4: Move to gdbsupport/.
* acinclude.m4: Update path to selftest.m4.
gdbserver/ChangeLog:
* acinclude.m4: Update path to selftest.m4.
gdbsupport/ChangeLog:
* selftest.m4: Moved from gdb/.
* acinclude.m4: Update path to selftest.m4.
While working on the preceding selftests patches, I noticed that some
selftests-specific files are included in the build even when selftests
are disabled, namely disasm-selftest.c and gdbarch-selftests.c. These
files are entirely #if'ed out when building with selftests disabled.
This is not a huge problem, but I think it would make more sense if
these files were simply not built.
With this patch, I propose to put all the selftests-specific source
files into a SELFTESTS_SRCS Makefile variable (even selftest-arch.c,
which is currently added by the configure script).
gdb/ChangeLog:
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Rename to...
(SELFTESTS_SRCS): ... this. Add disasm-selftests.c,
gdbarch-selfselftests.c and selftest-arch.c.
(SUBDIR_UNITTESTS_OBS): Rename to...
(SELFTESTS_OBS): ... this.
(COMMON_SFILES): Remove disasm-selftests.c and
gdbarch-selftests.c.
* configure.ac: Don't add selftest-arch.{c,o} to
CONFIG_{SRCS,OBS}.
* disasm-selftests.c, gdbarch-selftests.c: Remove GDB_SELF_TEST
preprocessor conditions.
The same is done for gdb, gdbserver and gdbsupport. I therefore think
it makes sense to move that to GDB_AC_COMMON.
It is required to move the call to GDB_AC_COMMON so it is before
GDB_AC_SELFTEST in gdbserver/configure.ac, otherwise the $development
variable isn't set when the code behind GDB_AC_SELFTEST executes.
gdb/ChangeLog:
* configure.ac: Don't source bfd/development.sh.
* selftest.m4: Modify comment.
* configure: Re-generate.
gdbserver/ChangeLog:
* configure.ac: Don't source bfd/development.sh, move
GDB_AC_COMMON higher.
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure.ac: Don't source bfd/development.sh.
* common.m4: Source bfd/development.sh.
* configure: Re-generate.
Before commit 3d1e5a43cb ("gdbsupport/configure.ac: source
development.sh"), the GDB build in non-development mode (turn
development to false in bfd/development.sh if you want to try) was
broken because the gdbsupport configure script didn't source
bfd/development.sh to set the development variable.
Since the GDB_AC_SELFTEST macro relies on the `development` variable, I
propose to modify it such that it errors out if $development does not
have an expected value of "true" or "false". This could prevent a
future similar problem from happening while refactoring the configure
scripts. It would have caught the problem fixed by the patch mentioned
earlier.
gdb/ChangeLog:
* selftest.m4 (GDB_AC_SELFTEST): Error out if $development is
not "true" or "false".
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure: Re-generate.
This is in preparation for deleting deprecated_add_core_fns and
related code.
As a side-effect, this makes it possible to read NetBSD/ARM
core files on non-NetBSD/ARM platforms, subject to PR corefiles/25638.
I have removed this comment:
- /* This is ok: we're running native... */
Since we are using the gdbarch from the regcache, we should be
guaranteed to be calling the right function here, so it shouldn't
matter whether we are running native.
Tested by reading a NetBSD/ARM core file on Linux/x86-64 and NetBSD/ARM;
the "info registers" output matches the one from the system GDB.
gdb/ChangeLog:
2020-03-12 Christian Biesinger <cbiesinger@google.com>
* Makefile.in (HFILES_NO_SRCDIR): Add new arm-nbsd-tdep.h file.
* arm-nbsd-nat.c (arm_supply_gregset): Moved to arm-nbsd-tdep and
renamed to arm_nbsd_supply_gregset.
(fetch_register): Update to call arm_nbsd_supply_gregset.
(fetch_regs): Remove in favor of fetch_register with a -1 regno.
(arm_netbsd_nat_target::fetch_registers): Update.
(fetch_elfcore_registers): Removed.
(_initialize_arm_netbsd_nat): Removed call to deprecated_add_core_fns.
* arm-nbsd-tdep.c (struct arm_nbsd_reg): New struct.
(arm_nbsd_supply_gregset): Moved from arm-nbsd-nat.c and updated to
not require NetBSD system headers.
(arm_nbsd_regset): New struct.
(arm_nbsd_iterate_over_regset_sections): New function.
(arm_netbsd_init_abi_common): Updated to call
set_gdbarch_iterate_over_regset_sections.
* arm-nbsd-tdep.h: New file.
A patch somewhat like this patch has been in Fedora GDB for well over
a decade. The Fedora patch was written by Jan Kratochvil. The Fedora
version prints a warning and attempts to continue. This version will
error out, fatally. An earlier version of this patch was more like
the Fedora version than this one. Simon Marchi recommended use of an
assertion to test for the infinite recursion; I decided to use an
explicit test (with an "if" statement) along with a call to
internal_error() if the condition is met. This way, I could include
a plea to file a bug report.
It was motivated by a customer reported bug (back in 2006!) which
showed infinite mutual recursion between find_pc_sect_line and
find_pc_line. Here is a portion of the backtrace from the bug report:
(gdb) bt
#0 0x00000000004450a4 in lookup_minimal_symbol_by_pc_section (
pc=251700325328, section=0x570f500) at gdb/minsyms.c:484
#1 0x00000000004bbfb2 in find_pc_sect_line (pc=251700325328,
section=0x570f500, notcurrent=0) at gdb/symtab.c:2057
#2 0x00000000004bc480 in find_pc_line (pc=251700325328, notcurrent=0)
at gdb/symtab.c:2232
#3 0x00000000004bc1ff in find_pc_sect_line (pc=251700325328,
section=0x570f500, notcurrent=0) at gdb/symtab.c:2081
... (lots and lots of the same two functions with the same parameters)
#1070 0x00000000004bc480 in find_pc_line (pc=251700325328, notcurrent=0)
at gdb/symtab.c:2232
#1071 0x00000000004bc1ff in find_pc_sect_line (pc=251700325328,
section=0x570f500, notcurrent=0) at gdb/symtab.c:2081
#1072 0x00000000004bc480 in find_pc_line (pc=251700325328, notcurrent=0)
at gdb/symtab.c:2232
#1073 0x00000000004bc1ff in find_pc_sect_line (pc=251700325328,
section=0x570f500, notcurrent=0) at gdb/symtab.c:2081
#1074 0x00000000004bc480 in find_pc_line (pc=251700325328, notcurrent=0)
at gdb/symtab.c:2232
#1075 0x00000000004bc1ff in find_pc_sect_line (pc=251696794399,
section=0x59b0df8, notcurrent=0) at gdb/symtab.c:2081
#1076 0x00000000004bc480 in find_pc_line (pc=251696794399, notcurrent=0)
at gdb/symtab.c:2232
#1077 0x000000000055550e in find_frame_sal (frame=0xb3f3e0, sal=0x7fff1d1a8200)
at gdb/frame.c:1392
#1078 0x00000000004d86fd in set_current_sal_from_frame (frame=0x1648, center=1)
at gdb/stack.c:379
#1079 0x00000000004cf137 in normal_stop () at gdb/infrun.c:3147
...
The test case was a large application. Attempts were made to make a
small(er) test case, but those attempts were not successful.
Therefore, I cannot provide a new test for this patch.
That said, we ought to guard against recursively calling
find_pc_sect_line (via find_pc_line) with the identical PC value that
it had been called with. Should this happen, infinite recursion (as
shown in the above backtrace) is the result. This patch prevents
that from happening.
If this should happens, there is a bug somewhere, perhaps in GDB, perhaps
in some other part of the toolchain or a library. We error out fatally
with a message briefly describing the condition along with a plea to file
a bug report.
I spent some time looking at the surrounding code and commentary which
handle the case of PC being in a stub/trampoline. It first appeared
in the public GDB repository in April, 1999. The ChangeLog entry for
this commit is from 1998-12-31. The relevant portion is:
(find_pc_sect_line): Return correct information if pc is in import
or export stub (trampoline).
What's remarkable about the overall ChangeLog entry is that it's over
2500+ lines long! I believe that this was part of the infamous "HP
merge" (in which insufficient due diligence was given in accepting
a large batch of changes from an outside source). In the years that
followed, much of this code was either significantly revised or
outright removed.
For this particular case, I'm grateful that extensive comments were
provided by "RT". (I haven't been able to figure out who RT is/was.)
I've decided against attempting to revise this stub/trampoline handling
code any further than adding Jan's test which prevents an obvious case
of infinite recursion.
I've tested on Fedora 31, x86-64. I see no regressions. I've also
searched the logfile for the new message, but as expected, no message
was found (which is good).
gdb/ChangeLog:
* symtab.c (find_pc_sect_line): Add check which prevents infinite
recursion.
Change-Id: I595470be6ab5f61ca7e4e9e70c61a252c0deaeaa
While compiling with clang, I noticed it didn't catch cases where my
function declaration didn't match my function definition. This is
normally caught by gcc with -Wmissing-declarations.
On clang, this is caught by -Wmissing-prototypes instead.
Note that on gcc, -Wmissing-prototypes also exists, but is only valid
for C and Objective-C. It gets correctly rejected by the configure
script since gcc rejects it with:
cc1plus: error: command line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++ -Werror
So this warning flag ends up not used for gcc (which is what we want).
gdb/ChangeLog:
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure: Re-generate.
* warning.m4: Enable -Wmissing-prototypes.
A comment in ada-typeprint.c mentions the Unchecked_Variant pragma.
However, this does not exist, and the comment should actually mention
Unchecked_Union.
gdb/ChangeLog
2020-03-11 Tom Tromey <tromey@adacore.com>
* ada-typeprint.c (print_choices): Fix comment.
This commit:
commit 8c95582da8
Date: Mon Dec 30 21:04:51 2019 +0000
gdb: Add support for tracking the DWARF line table is-stmt field
Introduced an invalid memory access, by reading outside the bounds of
an array.
This would cause this valgrind error:
==7633== Invalid read of size 4
==7633== at 0x4D002C: buildsym_compunit::record_line(subfile*, int, unsigned long, bool) (buildsym.c:688)
==7633== by 0x5F60A5: dwarf_record_line_1(gdbarch*, subfile*, unsigned int, unsigned long, bool, dwarf2_cu*) (read.c:19956)
==7633== by 0x5F63B0: lnp_state_machine::record_line(bool) (read.c:20024)
==7633== by 0x5F5DD5: lnp_state_machine::handle_special_opcode(unsigned char) (read.c:19851)
==7633== by 0x5F6706: dwarf_decode_lines_1(line_header*, dwarf2_cu*, int, unsigned long) (read.c:20135)
==7633== by 0x5F6C57: dwarf_decode_lines(line_header*, char const*, dwarf2_cu*, dwarf2_psymtab*, unsigned long, int) (read.c:20328)
==7633== by 0x5DF5F1: handle_DW_AT_stmt_list(die_info*, dwarf2_cu*, char const*, unsigned long) (read.c:10748)
==7633== by 0x5DF823: read_file_scope(die_info*, dwarf2_cu*) (read.c:10796)
==7633== by 0x5DDA63: process_die(die_info*, dwarf2_cu*) (read.c:9815)
==7633== by 0x5DD44A: process_full_comp_unit(dwarf2_per_cu_data*, language) (read.c:9580)
==7633== by 0x5DAB58: process_queue(dwarf2_per_objfile*) (read.c:8867)
==7633== by 0x5CB30E: dw2_do_instantiate_symtab(dwarf2_per_cu_data*, bool) (read.c:2374)
==7633== Address 0xa467f48 is 8 bytes before a block of size 16,024 alloc'd
==7633== at 0x4C2CDCB: malloc (vg_replace_malloc.c:299)
==7633== by 0x451FC4: xmalloc (alloc.c:60)
==7633== by 0x4CFFDF: buildsym_compunit::record_line(subfile*, int, unsigned long, bool) (buildsym.c:678)
==7633== by 0x5F60A5: dwarf_record_line_1(gdbarch*, subfile*, unsigned int, unsigned long, bool, dwarf2_cu*) (read.c:19956)
==7633== by 0x5F63B0: lnp_state_machine::record_line(bool) (read.c:20024)
==7633== by 0x5F5DD5: lnp_state_machine::handle_special_opcode(unsigned char) (read.c:19851)
==7633== by 0x5F6706: dwarf_decode_lines_1(line_header*, dwarf2_cu*, int, unsigned long) (read.c:20135)
==7633== by 0x5F6C57: dwarf_decode_lines(line_header*, char const*, dwarf2_cu*, dwarf2_psymtab*, unsigned long, int) (read.c:20328)
==7633== by 0x5DF5F1: handle_DW_AT_stmt_list(die_info*, dwarf2_cu*, char const*, unsigned long) (read.c:10748)
==7633== by 0x5DF823: read_file_scope(die_info*, dwarf2_cu*) (read.c:10796)
==7633== by 0x5DDA63: process_die(die_info*, dwarf2_cu*) (read.c:9815)
==7633== by 0x5DD44A: process_full_comp_unit(dwarf2_per_cu_data*, language) (read.c:9580)
gdb/ChangeLog:
* buildsyms.c (buildsym_compunit::record_line): Avoid accessing
previous item in the list, when the list has no items.
When using the executable from test-case gdb.ada/access_to_packed_array.exp
(read-in using -readnow) and printing the symbols using "maint print symbols",
we run into a segv:
...
$ gdb -readnow -batch access_to_packed_array/foo -ex "maint print symbols"
...
info: array (<>) of character; computed at runtime
ptr: range 0 .. 2147483647; computed at runtime
Aborted (core dumped)
...
What happens is that dwarf2_evaluate_property gets called and sets the local
frame variable to the current frame, which happens to be NULL. Subsequently
the PROP_LOCLIST handling code is executed, where get_frame_address_in_block
gets called with argument NULL, and the segv is triggered.
Fix this by handling a NULL frame in the PROP_LOCLIST handling code in
dwarf2_evaluate_property.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-03-11 Tom de Vries <tdevries@suse.de>
* dwarf2/loc.c (dwarf2_evaluate_property): Handle NULL frame in
PROP_LOCLIST handling code.
gdb/testsuite/ChangeLog:
2020-03-11 Tom de Vries <tdevries@suse.de>
* gdb.ada/access_to_packed_array.exp: Test printing of expanded
symtabs.
This commit brings support for the DWARF line table is_stmt field to
GDB. The is_stmt field is used by the compiler when a single source
line is split into multiple assembler instructions, especially if the
assembler instructions are interleaved with instruction from other
source lines.
The compiler will set the is_stmt flag false from some instructions
from the source lines, these instructions are not a good place to
insert a breakpoint in order to stop at the source line.
Instructions which are marked with the is_stmt flag true are a good
place to insert a breakpoint for that source line.
Currently GDB ignores all instructions for which is_stmt is false.
This is fine in a lot of cases, however, there are some cases where
this means the debug experience is not as good as it could be.
Consider stopping at a random instruction, currently this instruction
will be attributed to the last line table entry before this point for
which is_stmt was true - as these are the only line table entries that
GDB tracks. This can easily be incorrect in code with even a low
level of optimisation.
With is_stmt tracking in place, when stopping at a random instruction
we now attribute the instruction back to the real source line, even
when is_stmt is false for that instruction in the line table.
When inserting breakpoints we still select line table entries for
which is_stmt is true, so the breakpoint placing behaviour should not
change.
When stepping though code (at the line level, not the instruction
level) we will still stop at instruction where is_stmt is true, I
think this is more likely to be the desired behaviour.
Instruction stepping is, of course, unchanged, stepping one
instruction at a time, but we should now report more accurate line
table information with each instruction step.
The original motivation for this work was a patch posted by Bernd
here:
https://sourceware.org/ml/gdb-patches/2019-11/msg00792.html
As part of that thread it was suggested that many issues would be
resolved if GDB supported line table views, this isn't something I've
attempted in this patch, though reading the spec, it seems like this
would be a useful feature to support in GDB in the future. The spec
is here:
http://dwarfstd.org/ShowIssue.php?issue=170427.1
And Bernd gives a brief description of the benefits here:
https://sourceware.org/ml/gdb-patches/2020-01/msg00147.html
With that all said, I think that there is benefit to having proper
is_stmt support regardless of whether we have views support, so I
think we should consider getting this in first, and then building view
support on top of this.
The gdb.cp/step-and-next-inline.exp test is based off a test proposed
by Bernd Edlinger in this message:
https://sourceware.org/ml/gdb-patches/2019-12/msg00842.html
gdb/ChangeLog:
* buildsym-legacy.c (record_line): Pass extra parameter to
record_line.
* buildsym.c (buildsym_compunit::record_line): Take an extra
parameter, reduce duplication in the line table, and record the
is_stmt flag in the line table.
* buildsym.h (buildsym_compunit::record_line): Add extra
parameter.
* disasm.c (do_mixed_source_and_assembly_deprecated): Ignore
non-statement lines.
* dwarf2/read.c (dwarf_record_line_1): Add extra parameter, pass
this to the symtab builder.
(dwarf_finish_line): Pass extra parameter to dwarf_record_line_1.
(lnp_state_machine::record_line): Pass a suitable is_stmt flag
through to dwarf_record_line_1.
* infrun.c (process_event_stop_test): When stepping, don't stop at
a non-statement instruction, and only refresh the step info when
we land in the middle of a line's range. Also add an extra
comment.
* jit.c (jit_symtab_line_mapping_add_impl): Initialise is_stmt
field.
* record-btrace.c (btrace_find_line_range): Only record lines
marked as is-statement.
* stack.c (frame_show_address): Show the frame address if we are
in a non-statement sal.
* symmisc.c (dump_symtab_1): Print the is_stmt flag.
(maintenance_print_one_line_table): Print a header for the is_stmt
column, and include is_stmt information in the output.
* symtab.c (find_pc_sect_line): Find lines marked as statements in
preference to non-statements.
(find_pcs_for_symtab_line): Prefer is-statement entries.
(find_line_common): Likewise.
* symtab.h (struct linetable_entry): Add is_stmt field.
(struct symtab_and_line): Likewise.
* xcoffread.c (arrange_linetable): Initialise is_stmt field when
arranging the line table.
gdb/testsuite/ChangeLog:
* gdb.cp/step-and-next-inline.cc: New file.
* gdb.cp/step-and-next-inline.exp: New file.
* gdb.cp/step-and-next-inline.h: New file.
* gdb.dwarf2/dw2-is-stmt.c: New file.
* gdb.dwarf2/dw2-is-stmt.exp: New file.
* gdb.dwarf2/dw2-is-stmt-2.c: New file.
* gdb.dwarf2/dw2-is-stmt-2.exp: New file.
* gdb.dwarf2/dw2-ranges-base.exp: Update line table pattern.
Gcc supports an option -feliminate-dwarf2-dups (up until gcc-7, removed in
gcc-8).
When running tests with target board unix/-feliminate-dwarf2-dups, we run
into:
...
(gdb) PASS: gdb.ada/arraydim.exp: print m'length(3)
ptype global_3dim_for_gdb_testing^M
type = array (Unexpected type in ada_discrete_type_low_bound.^M
(gdb) FAIL: gdb.ada/arraydim.exp: ptype global_3dim_for_gdb_testing
...
The DWARF for the variable global_3dim_for_gdb_testing looks as follows:
...
<0><824>: Abbrev Number: 1 (DW_TAG_compile_unit)
<825> DW_AT_name : src/gdb/testsuite/gdb.ada/arraydim/inc.c
<1><832>: Abbrev Number: 2 (DW_TAG_array_type)
<833> DW_AT_type : <0x874>
<2><837>: Abbrev Number: 3 (DW_TAG_subrange_type)
<838> DW_AT_type : <0x84a>
<83c> DW_AT_upper_bound : 0
<2><83d>: Abbrev Number: 3 (DW_TAG_subrange_type)
<83e> DW_AT_type : <0x84a>
<842> DW_AT_upper_bound : 1
<2><843>: Abbrev Number: 3 (DW_TAG_subrange_type)
<844> DW_AT_type : <0x84a>
<848> DW_AT_upper_bound : 2
<2><849>: Abbrev Number: 0
<1><84a>: Abbrev Number: 4 (DW_TAG_typedef)
<84b> DW_AT_type : <0x86d>
<1><84f>: Abbrev Number: 0
<0><85b>: Abbrev Number: 5 (DW_TAG_compile_unit)
<861> DW_AT_name : src/gdb/testsuite/gdb.ada/arraydim/inc.c
<1><86d>: Abbrev Number: 6 (DW_TAG_base_type)
<86e> DW_AT_byte_size : 8
<86f> DW_AT_encoding : 7 (unsigned)
<870> DW_AT_name : long unsigned int
<1><874>: Abbrev Number: 7 (DW_TAG_base_type)
<875> DW_AT_byte_size : 4
<876> DW_AT_encoding : 5 (signed)
<877> DW_AT_name : int
<1><87b>: Abbrev Number: 8 (DW_TAG_variable)
<87c> DW_AT_name : global_3dim_for_gdb_testing
<882> DW_AT_type : <0x832>
<886> DW_AT_external : 1
...
The DWARF contains an anonymous typedef at 0x84a, referring to 0x86d.
Strictly speaking, the anonymous typedef is illegal DWARF, because a
DW_TAG_typedef is defined to have an DW_AT_name attribute containing the name
of the typedef as it appears in the source program.
The DWARF reading code creates a corresponding type for this typedef, which
goes on to confuse the code handling arrays.
Rather than trying to support the type representing this anonymous typedef in
all the locations where it causes problems, fix this by treating the anonymous
typedef as a forwarder DIE in the DWARF reader.
Tested on x86_64-linux, with target boards unix and
unix/-feliminate-dwarf2-dups.
This fixes ~85 failures for unix/-feliminate-dwarf2-dups.
gdb/ChangeLog:
2020-03-07 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (read_typedef): Treat anonymous typedef as forwarder
DIE.
While working on complex number support, I found a couple of
apparently obsolete coments. This removes them.
2020-03-07 Tom Tromey <tom@tromey.com>
* valops.c (value_literal_complex): Remove obsolete comment.
* gdbtypes.h (enum type_code) <TYPE_CODE_FLT>: Remove obsolete
comment.
[ Migrating this from Gerrit: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/321 ]
I noticed that some functions in infcmd and infrun call each other and
all call inferior_thread, while they could just get the thread_info
pointer from their caller. That means less calls to inferior_thread, so
less reliance on global state, since inferior_thread reads
inferior_ptid.
The paths I am unsure about are:
- fetch_inferior_event calls...
- step_command_fsm::should_stop calls...
- prepare_one_step
and
- process_event_stop_test calls...
- set_step_info
Before this patch, prepare_one_step gets the thread pointer using
inferior_thread. After this patch, it gets it from the
execution_control_state structure in fetch_inferior_event. Are we sure
that the thread from the execution_control_state structure is the same
as the one inferior_thread would return? This code path is used when a
thread completes a step, but the user had specified a step count (e.g.
"step 5") so we decide to do one more step. It would be strange (and
even a bug I suppose) if the thread in the ecs structure in
fetch_inferior_event was not the same thread that is prepared to stepped
by prepare_one_step. So I believe passing the ecs thread is fine.
The same logic applies to process_event_stop_test calling
set_step_info.
gdb/ChangeLog:
* infrun.h: Forward-declare thread_info.
(set_step_info): Add thread_info parameter, add doc.
* infrun.c (set_step_info): Add thread_info parameter, move doc
to header.
* infrun.c (process_event_stop_test): Pass thread to
set_step_info call.
* infcmd.c (set_step_frame): Add thread_info pointer, pass it to
set_step_info.
(prepare_one_step): Add thread_info parameter, pass it to
set_step_frame and prepare_one_step (recursive) call.
(step_1): Pass thread to prepare_one_step call.
(step_command_fsm::should_stop): Pass thread to
prepare_one_step.
(until_next_fsm): Pass thread to set_step_frame call.
(finish_command): Pass thread to set_step_info call.
The target_get_tib_address call always fails in this case, and there is an
error when changing the program with the file command:
(gdb) file allocer64.exe
Reading symbols from allocer64.exe...
You can't do that when your target is `exec'
Now it will skip this part, there is no need to rebase the executable without
an inferior anyways.
gdb/ChangeLog:
2020-03-06 Hannes Domani <ssbssa@yahoo.de>
* windows-tdep.c (windows_solib_create_inferior_hook):
Check if inferior is running.
Replace "the the" by "the".
gdb/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* NEWS: Fix "the the".
* ctfread.c: Same.
gdb/doc/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* gdb.texinfo: Fix "the the".
gdb/testsuite/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* README: Fix "the the".
* gdb.base/dprintf.exp: Same.
Using verbose, we get some detail on symbol loading:
...
$ gdb a.out -iex "set verbose on"
Reading symbols from a.out...
Reading in symbols for /home/vries/hello.c...done.
(gdb)
...
And using debug symtab-create, much more detail:
...
$ gdb a.out -iex "set verbose on" -iex "set debug symtab-create 1"
Reading symbols from a.out...
Reading minimal symbols of objfile /data/gdb_versions/devel/lto/a.out ...
Installing 30 minimal symbols of objfile /data/gdb_versions/devel/lto/a.out.
Done reading minimal symbols.
Creating one or more psymtabs for objfile /data/gdb_versions/devel/lto/a.out ...
Created psymtab 0x35a3de0 for module ../sysdeps/x86_64/start.S.
Created psymtab 0x353e4e0 for module init.c.
Created psymtab 0x353e560 for module ../sysdeps/x86_64/crti.S.
Created psymtab 0x353e5e0 for module /home/vries/hello.c.
Created psymtab 0x35bd530 for module elf-init.c.
Created psymtab 0x35bd5b0 for module ../sysdeps/x86_64/crtn.S.
Reading in symbols for /home/vries/hello.c...Created compunit symtab 0x354bd20 for hello.c.
done.
(gdb)
...
The "Created compunit symtab" message gets inbetween the "Reading in symbols"
and the trailing "done.". [ Strictly speaking this is a regression since
commit faa17681cc "Make gdb_flush also flush the wrap buffer", but the
same problem happens when using -batch before this commit. ]
Fix this by removing the trailing "done." altogether, such that we get:
...
Created psymtab 0x3590520 for module ../sysdeps/x86_64/crtn.S.
Reading in symbols for /home/vries/hello.c...
Created compunit symtab 0x359dd20 for hello.c.
(gdb)
...
[ Alternatively, we could fix this emitting a "Done reading in symbols" line
or some such, like is done for minimal symbols. See above. ]
[ Note: Removing the trailing "done." for the "Reading symbols from" message
was done in commit 3453e7e409 'Clean up "Reading symbols" output'. ]
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* psymtab.c (psymtab_to_symtab): Don't print "done.".
Copy the .dir-locls.el file from gdb/ to gdbserver/ and gdbsupport/ so
that we get the GNU/GDB style when editing these files in Emacs.
I initially wanted to remove the (c-mode . ((mode . c++))) that
switches c-mode files into c++-mode as we store C++ code in *.cc files
in the gdbserver/ directory, unlike gdb/ where we use *.c, however, I
was forgetting about the header files - we still use *.h for our C++
header files, so for now I left the settings in place to open all C
files in c++-mode.
We now have three copies of this file, which are all identical. It
would be nice if we could remove this duplication, however, for now we
haven't found a good way to do this.
Some options considered were:
1. Use symlinks to only have one copy of the file. This was
rejected as not all targets support symlinks in the way.
2. Have two of the .dir-locals.el files contain some mechanism by
which the third copy of the file is sourced. Though this would, in
theory, be possible, it would involve some advanced Emacs scripting,
would be fragile, and a maintenance burdon.
3. Move the .dir-locals up into top level src/ directory, then use
Emacs dir-locals directory pattern matching to only apply the rules
for the three directories we care about. The problem is that each
directory has to be listed separately, so we still end up having to
duplicate all the rules.
In the end, it was decided that having three copies of the file,
though not ideal, is probably easiest for now. This was all discussed
in this mailing list thread:
https://sourceware.org/ml/gdb-patches/2020-03/msg00024.html
The copyright date in the new files is left as for gdb/.dir-locals.el,
as the new files are a copy of the old, this is inline with this rule:
https://sourceware.org/gdb/wiki/ContributionChecklist#Copyright_Header
gdb/ChangeLog:
* .dir-locals.el: Add a comment referencing the other copies of
this file.
gdbserver/ChangeLog:
* .dir-locals.el: New file.
gdbsupport/ChangeLog:
* .dir-locals.el: New file.
Create .gitattributes files in gdb/, gdbserver/, and gdbsupport/.
The files specify cpp-style diffs for .h and .c files. This is
particularly helpful if a class in a header file is modified.
For instance, if the `stop_requested` field of `thread_info` in
gdb/gdbthread.h is modified, we get the following diff with
'git diff' (using git version 2.17.1):
@@ -379,7 +379,7 @@ public:
struct target_waitstatus pending_follow;
/* True if this thread has been explicitly requested to stop. */
- int stop_requested = 0;
+ bool stop_requested = 0;
/* The initiating frame of a nexting operation, used for deciding
which exceptions to intercept. If it is null_frame_id no
Note that the context of the change shows up as 'public:'; not so
useful. With the .gitattributes file, we get:
@@ -379,7 +379,7 @@ class thread_info : public refcounted_object
struct target_waitstatus pending_follow;
/* True if this thread has been explicitly requested to stop. */
- int stop_requested = 0;
+ bool stop_requested = 0;
/* The initiating frame of a nexting operation, used for deciding
which exceptions to intercept. If it is null_frame_id no
The context is successfully shown as 'class thread_info'.
This patch creates a .gitattributes file per each of gdb, gdbserver,
and gdbsupport folders. An alternative would be to define the
attributes in the root folder -- this would impact all the top-level
folders, though. I opted for the more conservative approach.
gdb/ChangeLog:
2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* .gitattributes: New file.
gdbserver/ChangeLog:
2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* .gitattributes: New file.
gdbsupport/ChangeLog:
2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* .gitattributes: New file.
This introduces a string cache on the per-BFD object, replacing the
macro and filename caches. Both of these caches just store strings,
so this consolidation by itself saves a little memory (about the size
of a bcache per objfile).
Then this patch switches some allocations on the objfile obstack to
use this bcache instead. This saves more space; and turns out to be a
bit faster as well.
Here are the before and after "maint time" + "maint space" results of
"file ./gdb":
Command execution time: 4.664021 (cpu), 4.728518 (wall)
Space used: 39190528 (+29212672 for this command)
Command execution time: 4.216209 (cpu), 4.107023 (wall)
Space used: 36667392 (+26689536 for this command)
The main interface to the string cache is a new pair of overloaded
methods, objfile::intern.
gdb/ChangeLog
2020-03-04 Tom Tromey <tom@tromey.com>
* symmisc.c (print_symbol_bcache_statistics)
(print_objfile_statistics): Update.
* symfile.c (allocate_symtab): Use intern.
* psymtab.c (partial_symtab::partial_symtab): Use intern.
* objfiles.h (struct objfile_per_bfd_storage) <filename_cache,
macro_cache>: Remove.
<string_cache>: New member.
(struct objfile) <intern>: New methods.
* elfread.c (elf_symtab_read): Use intern.
* dwarf2/read.c (fixup_go_packaging): Intern package name.
(dwarf2_compute_name, dwarf2_physname)
(create_dwo_unit_in_dwp_v1, create_dwo_unit_in_dwp_v2): Intern
names.
(guess_partial_die_structure_name): Update.
(partial_die_info::fixup): Intern name.
(dwarf2_canonicalize_name): Change parameter to objfile. Intern
name.
(dwarf2_name): Intern name. Update.
* buildsym.c (buildsym_compunit::get_macro_table): Use
string_cache.
I noticed that gnutarget was not "const". Since writing through this
pointer would probably be a bug, I think it ought to be. This patch
makes the change.
gdb/ChangeLog
2020-03-04 Tom Tromey <tom@tromey.com>
* jit.c (bfd_open_from_target_memory): Make "target" const.
* corefile.c (gnutarget): Now const.
* gdbcore.h (gnutarget): Now const.
Revert the change since it breaks existing behavior of "info registers"
for some architectures. At least AArch64 and ARM are impacted by this change.
gdb/ChangeLog:
2020-03-04 Luis Machado <luis.machado@linaro.org>
Revert aa66aac47b due to regressions
in "info registers" for AArch64/ARM.
The change caused "info registers" to not print GPR's.
gdb/ChangeLog:
2020-02-01 Shahab Vahedi <shahab@synopsys.com>
* target-descriptions.c (tdesc_register_in_reggroup_p): Return 0
when reg->group is empty and reggroup is not.
A customer reported a failure to unwind in a certain core dump. A
lengthy investigation showed that the problem came from the
interaction between the tailcall and inline frame sniffers.
Normally, the regular DWARF unwinder may discover a chain of tail
calls ending in the current frame. In this case, it sets a member on
the dwarf2_frame_cache object, so that a subsequent call into the
tailcall sniffer will create the tailcall frames.
However, in this scenario, what happened is that the DWARF unwinder
did find tailcall frames -- but then the PC of the first such frame
was recognized and claimed by the inline frame sniffer.
This then caused unwinding to go astray further up the stack.
This patch fixes the problem by arranging for the tailcall sniffer to
be called before the inline sniffer. This way, if a DWARF frame has
tailcall information, the tailcalls will always be processed first.
This is safe to do, because the tailcall sniffer can only claim a
frame if the previous frame did in fact find this information. (So,
for example, if no DWARF frame is ever found, then this sniffer will
never trigger.)
This patch also partially reverts:
commit 1ec56e88aa
Author: Pedro Alves <palves@redhat.com>
Date: Fri Nov 22 13:17:46 2013 +0000
Eliminate dwarf2_frame_cache recursion, don't unwind from the dwarf2 sniffer (move dwarf2_tailcall_sniffer_first elsewhere).
That patch moved the call to dwarf2_tailcall_sniffer_first out of
dwarf2_frame_cache, and into dwarf2_frame_prev_register. However, in
this situation, this is too late -- by the time
dwarf2_frame_prev_register is called, the frame in question is already
recognized by the inline frame sniffer.
Rather than fully revert that patch, though, this just arranges to
call dwarf2_tailcall_sniffer_first from dwarf2_frame_cache -- which is
called shortly after the DWARF frame sniffer succeeds, via
compute_frame_id.
I don't know how to write a test case for this.
gdb/ChangeLog
2020-03-03 Tom Tromey <tromey@adacore.com>
* dwarf2/frame.c (struct dwarf2_frame_cache)
<checked_tailcall_bottom, entry_cfa_sp_offset,
entry_cfa_sp_offset_p>: Remove members.
(dwarf2_frame_cache): Call dwarf2_tailcall_sniffer_first.
(dwarf2_frame_prev_register): Don't call
dwarf2_tailcall_sniffer_first.
(dwarf2_append_unwinders): Don't append tailcall unwinder.
* frame-unwind.c (add_unwinder): New fuction.
(frame_unwind_init): Use it. Add tailcall unwinder.
GDB is not able to print logical true values for Flang compiler.
Actual result:
(gdb) p l
$1 = 4294967295
Expected result:
(gdb) p l
$1 = .TRUE.
This is due to GDB expecting representation of true value being 1.
The Fortran standard doesnt specify how LOGICAL types are represented.
Different compilers use different non-zero values to represent logical
true. The gfortran compiler uses 1 to represent logical true and the
flang compiler uses -1. GDB should accept all the non-zero values as
true.
This is achieved by handling TYPE_CODE_BOOL in f_val_print and
printing any non-zero value as true.
gdb/ChangeLog:
* f-valprint.c (f_val_print): Handle TYPE_CODE_BOOL, any non-zero
value should be printed as true.
gdb/testsuite/ChangeLog:
* gdb.fortran/logical.exp: Add tests that any non-zero value is
printed as true.
Windows executables linked with -dynamicbase get a new base address
when loaded, which makes debugging impossible if the executable isn't
also rebased in gdb.
The new base address is read from the Process Environment Block.
gdb/ChangeLog:
2020-03-03 Hannes Domani <ssbssa@yahoo.de>
* windows-tdep.c (windows_solib_create_inferior_hook): New function.
(windows_init_abi): Set and use windows_so_ops.
Back at:
commit 1f6f6e21fa
Author: Philippe Waroquiers <philippe.waroquiers@skynet.be>
Date: Mon Jun 10 21:41:51 2019 +0200
Ensure GDB printf command can print convenience var strings without a target.
GDB was extended in order to allow the printing of convenience
variables that are strings without a target. However, this introduced
a regression that hasn't been caught by our testsuite (because there
were no tests for it).
The problem happens when we try to print a convenience variable that
holds the address of a string in the inferior. The following
two-liners can reproduce the issue:
$ echo -e 'int main(){const char a[]="test";return 0;}' | gcc -x c - -O0-g3
$ ./gdb/gdb --data-directory ./gdb/data-directory -q ./a.out -ex 'start' -ex 'set $x = (const char *) (&a[0] + 2)' -ex 'printf "%s\n", $x'
After some investigation, I found that the problem happens on
printcmd.c:printf_c_string. In the case above, we're taking the first
branch of the 'if' condition, which assumes that there will be a value
to be printed at "value_contents (value)". There isn't. We actually
need to obtain the address that the variable points to, and read the
contents from memory.
It seems to me that we should avoid this branch if the TYPE_CODE of
"value_type (value)" is TYPE_CODE_PTR (i.e., a pointer to the
inferior's memory). This is what this patch does.
I took the liberty to extend the current testcase under
gdb.base/printcmds.exp and create a test that exercises this scenario.
No regressions have been found on Buildbot.
gdb/ChangeLog:
2020-03-03 Sergio Durigan Junior <sergiodj@redhat.com>
* printcmd.c (print_c_string): Check also for TYPE_CODE_PTR
when verifying if dealing with a convenience variable.
gdb/testsuite/ChangeLog:
2020-03-03 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/printcmds.exp: Add test to verify printf of a
variable holding an address.
I noticed GDB didn't know a particular AT tag (51) when doing some debugging.
Turns out we're missing a few entries compared to glibc's headers.
This patch adds them to GDB and fixes a failure in gdb.base/auxv.exp as
a result.
gdb/ChangeLog:
2020-03-03 Luis Machado <luis.machado@linaro.org>
* auxv.c (default_print_auxv_entry): Add new AUXV entries.
This function returns the result of a quite big condition. I think it
would be more readeable if it was broken up in smaller pieces and
commented. This is what this patch does.
I also introduced gdbarch_supports_displaced_stepping, since it shows
the intent better than checking for gdbarch_displaced_step_copy_insn_p.
I also used that new function in displaced_step_prepare_throw.
I also updated the comment on top of can_use_displaced_stepping, which
seemed a bit outdated with respect to non-stop. The comment likely
dates from before it was possible to have targets that always operate
non-stop under the hood, even when the user-visible mode is all-stop.
No functional changes intended.
gdb/ChangeLog:
* infrun.c (gdbarch_supports_displaced_stepping): New.
(use_displaced_stepping): Break up conditions in smaller pieces.
Use gdbarch_supports_displaced_stepping.
(displaced_step_prepare_throw): Use
gdbarch_supports_displaced_stepping.
This commit aims to give a cleaner mechanism by which the user can
prevent GDB from trying to load any previous command history.
Currently the user can change the path to the history file, either
using a command line flag, or by setting the GDBHISTFILE environment
variable, and if the path is set to a non-existent file, then
obviously GDB wont load any command history. However, this feels like
a bit of a bodge, I'd like to add an official mechanism by which we
can disable command history loading.
Why would we want to prevent command history loading? The specific
use case I have is GDB starting with a CWD that is a network mounted
directory, and there is no command history present. Still GDB will
access the network in order to check for the file. In my particular
use case I'm actually starting a large number of GDB instances in
parallel, all in the same network mounted directory, the large number
of network accesses looking for this file introduces a noticeable
delay at GDB startup.
The approach I'm proposing here is a slight adjustment to the current
rules for setting up the history filename. Currently, if a user does
this, they see an error:
(gdb) set history filename
Argument required (filename to set it to.).
However, if a user does this:
$ GDBHISTFILE= gdb --quiet
(gdb) set history save on
(gdb) q
warning: Could not rename -gdb18416~ to : No such file or directory
So, we already have a bug in this area. My plan is to allow the empty
filename to be accepted, and for this to mean, neither load, nor save
the command history.
This does mean that we now have two mechanisms to prevent saving the
command history:
(gdb) set history filename
or
(gdb) set history save off
But the only way to prevent loading the command history is to set the
filename to the empty string _before_ you get to a GDB prompt, either
using a command line option, or the environment variable.
I've updated some of the show commands, for example this session:
(gdb) set history filename
(gdb) show history filename
There is no filename currently set for recording the command history in.
(gdb) show history save
Saving of the history record on exit is off.
(gdb) set history save on
(gdb) show history save
Saving of the history is disabled due to the value of 'history filename'.
(gdb) set history filename /tmp/hist
(gdb) show history save
Saving of the history record on exit is on.
I've updated the manual, and added some tests.
gdb/ChangeLog:
* NEWS: Mention new behaviour of the history filename.
* top.c (write_history_p): Add comment.
(show_write_history_p): Add header comment, give a different
message when history writing is on, but the history filename is
empty.
(history_filename): Add comment.
(history_filename_empty): New function.
(show_history_filename): Add header comment, give a different
message when the filename is empty.
(init_history): Compare history_filename against nullptr, and only
read history if the filename is not empty.
(set_history_filename): Add header comment, and only make
non-empty filenames absolute.
(init_main): Make the filename argument to 'set history filename'
optional.
gdb/doc/ChangeLog:
* gdb.texinfo (Command History): Extend description for
GDBHISTFILE and GDBHISTSIZE, add detail about the filename for
'set history filename' being optional. Describe the effect of an
empty history filename on 'set history save on'.
gdb/testsuite/ChangeLog:
* gdb.base/default.exp: Remove test of 'set history filename'.
* gdb.base/gdbinit-history.exp: Add tests for setting the history
filename to the empty string.
* lib/gdb.exp (gdb_init): Unset environment variables GDBHISTFILE
and GDBHISTSIZE.
Change-Id: Ia586e4311182fac99113b60f11ef8a11fbd5450b
The floating point register interface has changed to this:
https://github.com/NetBSD/src/blob/trunk/sys/arch/arm/include/reg.h
It now uses VFP instead of FPA registers. This patch updates
arm-nbsd-nat.c accordingly.
Also implements read_description so that these registers are correctly
printed by "info registers" et al.
Tested by compiling & running on arm-netbsd on qemu.
gdb/ChangeLog:
2020-03-02 Christian Biesinger <cbiesinger@google.com>
* arm-nbsd-nat.c (arm_supply_fparegset): Rename to...
(arm_supply_vfpregset): ...this, and update to use VFP registers.
(fetch_fp_register): Update.
(fetch_fp_regs): Update.
(store_fp_register): Update.
(store_fp_regs): Update.
(arm_netbsd_nat_target::read_description): New function.
(fetch_elfcore_registers): Update.
With this commit:
commit 5b6d1e4fa4
Date: Fri Jan 10 20:06:08 2020 +0000
Multi-target support
There was a regression in GDB's support for older aspects of the
remote protocol. Specifically, when a target sends the 'S' stop reply
packet (which doesn't include a thread-id) then GDB has to figure out
which thread actually stopped.
Before the above commit GDB figured this out by using inferior_ptid in
process_stop_reply, which contained the ptid of the current
process/thread. This would be fine for single threaded
targets (which is the only place using an S packet makes sense), but
in the general case, relying on inferior_ptid for processing a stop is
wrong - there's no reason to believe that what was GDB's current
thread will be the same thread that just stopped in the target.
With the above commit the inferior_ptid now has the value null_ptid
inside process_stop_reply, this can be seen in do_target_wait, where
we call switch_to_inferior_no_thread before calling do_target_wait_1.
The problem this causes can be seen in the new test that runs
gdbserver using the flag --disable-packet=T, and causes GDB to throw
this assertion:
inferior.c:279: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.
A similar problem was fixed in this commit:
commit 3cada74087
Date: Thu Jan 11 00:23:04 2018 +0000
Fix backwards compatibility with old GDBservers (PR remote/22597)
However, this commit deals with the case where the T packet doesn't
include a thread-id, not the S packet case. This commit solves the
problem providing a thread-id at the GDB side if the remote target
doesn't provide one. The thread-id provided comes from
remote_state::general_thread, however, though this does work, I don't
think it is the ideal solution.
The remote_state tracks two threads, the continue_thread and the
general_thread, these are updated when GDB asks the remote target to
switch threads. The general_thread is set before performing things
like register or memory accesses, and the continue_thread is set
before things like continue or step commands. Further, the
general_thread is updated after a target stops to reference the thread
that stopped.
The first thing to note from the above description is that we have a
cycle of dependency, when a T packet arrives without a thread-id we
fill in the thread-id from the general_thread data. The thread-id
from the stop event is then used to set the general_thread. This in
itself feels a little weird.
The second question is why use the general_thread at all? You'd think
given how they are originally set that the continue thread would be a
better choice. The problem with this is that the continue_thread, if
the user just does "continue", will be set to the minus_one_ptid, in
the remote protocol this means all threads. When the stop arrives
with no thread-id and we use continue_thread we end up with a very
similar assertion to before because we now end up trying to lookup a
thread using the minus_one_ptid. By contrast, once GDB has connected
to a remote target the general_thread will be set to a valid
thread-id, after which, if the target is single threaded, and stop
events arrive without a thread-id, everything works fine.
There is one slight weirdness with the above behaviour though. When
GDB first connects to the remote target inferior_ptid is null_ptid,
however, upon connecting we query the remote for its threads. As the
thread information arrives GDB adds the threads to its internal
database, and this process involves setting inferior_ptid to the id of
each new thread in turn. Once we know about all the threads we wait
for a stop event from the remote target to indicate that GDB is now in
control of the target.
The problem is that after adding the new threads we don't reset
inferior_ptid, and the code path we use to wait for a stop event from
the target also doesn't reset inferior_ptid, so it turns out that
during the initial connection inferior_ptid is not null_ptid. This is
lucky, because during the initial connection the general_thread
variable _is_ set to null_ptid.
So, during the initial connection, if the first stop event is missing
a thread-id then we "provide" a thead-id from general_thread. This
turns out to be null_ptid meaning no thread-id is known, and then
during process_stop_reply we fill in the missing thread-id using
inferior_ptid.
This was all discussed on the mailing list here:
https://sourceware.org/ml/gdb-patches/2020-02/msg01011.html
My proposal for a fix then is:
1. Move the call to switch_to_inferior_no_thread into
do_target_wait_1, this means that in all cases where we are waiting
for an inferior the inferior_ptid will be set to null_ptid. This is
good as no wait code should rely on inferior_ptid.
2. Remove the use of general_thread from the 'T' packet processing.
The general_thread read here was only ever correct by chance, and we
shouldn't be using it this way.
3. Remove use of inferior_ptid from process_stop_event as this is
wrong, and will always be null_ptid now anyway.
4. When a stop_event has null_ptid due to a lack of thread-id (either
from a T packet or an S packet) then pick the first non exited thread
in the target and use that. This will be fine for single threaded
targets. A multi-thread or multi-inferior aware remote target
should be using T packets with a thread-id, so we give a warning if
the target is multi-threaded, and we are still missing a thread-id.
5. Extend the existing test that covered the T packet with missing
thread-id to also cover the S packet.
gdb/ChangeLog:
* remote.c (remote_target::remote_parse_stop_reply): Don't use the
general_thread if the stop reply is missing a thread-id.
(remote_target::process_stop_reply): Use the first non-exited
thread if the target didn't pass a thread-id.
* infrun.c (do_target_wait): Move call to
switch_to_inferior_no_thread to ....
(do_target_wait_1): ... here.
gdb/testsuite/ChangeLog:
* gdb.server/stop-reply-no-thread.exp: Add test where T packet is
disabled.
* defs.h includes config.h
* config.h may define _GNU_SOURCE
* if _GNU_SOURCE is defined, that must be before including any system
header (see feature_test_macro(7))
This is necessary to ensure that a prototype for mkostemp() is brought
into scope by <stdlib.h> when compiling filestuff.h, on platforms where
_GNU_SOURCE isn't unconditionally defined for C++.
In file included from ../../gdb/../gdbsupport/scoped_fd.h:24,
from ../../gdb/debuginfod-support.c:22:
../../gdb/../gdbsupport/filestuff.h: In function ‘int gdb_mkostemp_cloexec(char*, int)’:
../../gdb/../gdbsupport/filestuff.h:59:10: error: ‘mkostemp’ was not declared in this scope; did you mean ‘mkstemp’?
gdb/ChangeLog:
2020-02-29 Jon Turney <jon.turney@dronecode.org.uk>
* debuginfod-support.c: Include defs.h first.
When language is set to auto, part of loading an executable is to update the
language accordingly. This is implemented by set_initial_language.
In case of a c++ executable without DW_AT_main_subprogram,
set_initial_language finds "main" in the minimal symbols, and does a lookup of
"main" in the symbol tables to determine the language of the symbol, and uses
that as initial language.
The symbol lookup is done using lookup_symbol which is a wrapper around
lookup_symbol_in_language, using the current language.
So, consider two c++ executables a.out and b.out, which we'll load one after
another. If we track the resulting lookup_symbol_in_language calls:
...
$ gdb -batch \
-ex "b lookup_symbol_in_language" \
-ex r -ex c -ex c \
--args gdb
...
we find that indeed lookup_symbol_in_language is called once using language_c, and
once using language_c_plus:
...
(gdb) file a.out
Reading symbols from a.out...
Breakpoint 1, lookup_symbol_in_language (name=0x5555568c2050 "main", \
block=0x0, domain=VAR_DOMAIN, lang=language_c, is_a_field_of_this=0x0) \
at ../../gdb/symtab.c:1905
1905 {
(gdb) file b.out
Load new symbol table from "b.out"? (y or n) y
Reading symbols from b.out...
Breakpoint 1, lookup_symbol_in_language (name=0x5555568c2030 "main", \
block=0x0, domain=VAR_DOMAIN, lang=language_cplus, is_a_field_of_this=0x0) \
at ../../gdb/symtab.c:1905
1905 {
(gdb)
...
It seems like a bad idea to have the previous language play a role
in determining the executable language.
Fix this by using lookup_symbol_in_language in set_initial_language with the
default language c as argument.
Tested on x86_64-linux.
gdb/ChangeLog:
2020-02-28 Tom de Vries <tdevries@suse.de>
* symfile.c (set_initial_language): Use default language for lookup.
Running anything with the fission.exp board fails since commit
c0ab21c22b ("Replace init_cutu_and_read_dies with a class").
GDB crashes while reading the DWARF info. cu is NULL in
read_signatured_type:
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x000055555780663e in read_signatured_type
sig_type=0x6210000c3600) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22782
22782 gdb_assert (cu->die_hash == NULL);
(top-gdb) bt
#0 0x000055555780663e in read_signatured_type (sig_type=0x6210000c3600) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22782
#1 0x00005555578062dd in load_full_type_unit (per_cu=0x6210000c3600) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22758
#2 0x00005555577c5fb7 in queue_and_load_dwo_tu (slot=0x60600007fc00, info=0x6210000c34e0) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:12674
#3 0x0000555559934232 in htab_traverse_noresize (htab=0x60b000063670, callback=0x5555577c5e61 <queue_and_load_dwo_tu(void**, void*)>, info=0x6210000c34e0)
at /home/simark/src/binutils-gdb/libiberty/hashtab.c:775
#4 0x00005555577c6252 in queue_and_load_all_dwo_tus (per_cu=0x6210000c34e0) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:12701
#5 0x000055555777ebd8 in dw2_do_instantiate_symtab (per_cu=0x6210000c34e0, skip_partial=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:2371
#6 0x000055555777eea2 in dw2_instantiate_symtab (per_cu=0x6210000c34e0, skip_partial=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:2395
#7 0x0000555557786ab6 in dw2_lookup_symbol (objfile=0x614000007240, block_index=GLOBAL_BLOCK, name=0x602000025310 "main", domain=VAR_DOMAIN)
at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:3539
After creating the reader object, the reader.cu field should not be
NULL. By checking the commit previous to the faulty one mentioned
above, I noticed that the cu field is normally set by
init_cu_die_reader, called from read_cutu_die_from_dwo, itself called
from cutu_reader::init_tu_and_read_dwo_dies, itself called from
cutu_reader's constructor.
However, cutu_reader::init_tu_and_read_dwo_dies calls
read_cutu_die_from_dwo, passing a pointer to a local `die_reader_specs`
variable. So it's the `cu` field of that object that gets set.
cutu_reader itself is a `die_reader_specs` (it inherits from it), and
the intention was most likely to pass `this` to read_cutu_die_from_dwo.
This way, the fields of the cutu_reader object, which
read_signatured_type will use, are set.
With this, I am able to use:
make check RUNTESTFLAGS='--target_board=fission'
and it looks much better. There are still some failures to be
investigated, but that's the usual state of the testsuite.
gdb/ChangeLog:
* dwarf2/read.c (cutu_reader::init_tu_and_read_dwo_dies): Remove
reader variable, pass `this` to read_cutu_die_from_dwo.
This fixes a regression caused by commit 0d79cdc494d5:
$ make check TESTS="gdb.dwarf2/dw2-ranges-base.exp"
[...]
ERROR: GDB process no longer exists
This error is caused by an abort during the computation of srcpath
when SYMTAB_DIRNAME (s) == NULL.
Computing srcpath only when SYMTAB_DIRNAME (s) is not NULL fixes this
error. Also change the condition for calling debuginfod_source_query
to include whether srcpath could be computed.
gdb/ChangeLog:
2020-02-27 Aaron Merey <amerey@redhat.com>
* source.c (open_source_file): Check for nullptr when computing
srcpath.
I noticed that there's no real reason to have field_info::nfields in
the DWARF reader. It simply mirrors information that is already
available. This patch removes it, in favor of a convenience method.
gdb/ChangeLog
2020-02-27 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (struct field_info) <nfields>: Now a method, not a
member.
(dwarf2_add_field): Don't update nfields.
(dwarf2_attach_fields_to_type, process_structure_scope): Update.
Use std::abs so that we get the C++ overloaded version that matches
the argument type instead of the C abs function which is only for int
arguments.
There should be no user visible change after this commit.
gdb/ChangeLog:
* gdbtypes.c (create_array_type_with_stride): Use std::abs not
abs.
Include files are represented by a partial symtab, but don't expand to
anything. From dwarf2_psymtab::expand_psymtab:
if (per_cu == NULL)
{
/* It's an include file, no symbols to read for it.
Everything is in the parent symtab. */
readin = true;
return;
}
This patch introduces a new specialization of partial_symtab to handle
this case. In addition to being slightly smaller, I believe an
include file is the only situation where a DWARF psymtab can result in
a null compunit_symtab. This adds an assert to that effect as well.
This change will simplify one of the psymtab sharing patches.
gdb/ChangeLog
2020-02-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (struct dwarf2_include_psymtab): New.
(dwarf2_create_include_psymtab): Use dwarf2_include_psymtab.
(dwarf2_psymtab::expand_psymtab, dwarf2_psymtab::readin_p)
(dwarf2_psymtab::get_compunit_symtab): Remove null checks for
per_cu_data.
dwarf2/index-write.c casts pointers to "dwarf2_psymtab *", but as far
as I can tell, it does not actually use any DWARF-specific fields of
the psymtab. So, this patch changes this code to use partial_symtab
instead. This removes nearly every cast, leaving just the unavoidable
one from addrmap iteration.
gdb/ChangeLog
2020-02-26 Tom Tromey <tom@tromey.com>
* dwarf2/index-write.c (psym_index_map): Change type.
(add_address_entry_worker, write_one_signatured_type)
(recursively_count_psymbols, recursively_write_psymbols)
(class debug_names, psyms_seen_size, write_gdbindex)
(write_debug_names): Use partial_symtab, not dwarf2_psymtab.
debuginfod is a lightweight web service that indexes ELF/DWARF debugging
resources by build-id and serves them over HTTP.
This patch enables GDB to query debuginfod servers for separate debug
files and source code when it is otherwise not able to find them.
GDB can be built with debuginfod using the --with-debuginfod configure
option.
This requires that libdebuginfod be installed and found at configure time.
debuginfod is packaged with elfutils, starting with version 0.178.
For more information see https://sourceware.org/elfutils/.
Tested on x86_64 Fedora 31.
gdb/ChangeLog:
2020-02-26 Aaron Merey <amerey@redhat.com>
* Makefile.in: Handle optional debuginfod support.
* NEWS: Update.
* README: Add --with-debuginfod summary.
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Handle optional debuginfod support.
* debuginfod-support.c: debuginfod helper functions.
* debuginfod-support.h: Ditto.
* doc/gdb.texinfo: Add --with-debuginfod to configure options
summary.
* dwarf2/read.c (dwarf2_get_dwz_file): Query debuginfod servers
when a dwz file cannot be found.
* elfread.c (elf_symfile_read): Query debuginfod servers when a
debuginfo file cannot be found.
* source.c (open_source_file): Query debuginfod servers when a
source file cannot be found.
* top.c (print_gdb_configuration): Include
--{with,without}-debuginfod in the output.
gdb/testsuite/ChangeLog:
2020-02-26 Aaron Merey <amerey@redhat.com>
* gdb.debuginfod: New directory for debuginfod tests.
* gdb.debuginfod/main.c: New test file.
* gdb.debuginfod/fetch_src_and_symbols.exp: New tests.
This makes the thread apply command print the thread's name. The use
of target_pid_to_str is replaced by thread_target_id_str, which
provides the same output as "info threads".
Before:
(gdb) thread apply 2 bt
Thread 2 (Thread 0x7fd245602700 (LWP 3837)):
[...]
After:
(gdb) thread apply 2 bt
Thread 2 (Thread 0x7fd245602700 (LWP 3837) "HT cleanup"):
[...]
The thread's description header is pre-computed before running the
command since the command may change the selected inferior. This is
not permitted by thread_target_id_str as target_thread_name asserts
that `info->inf == current_inferior ()`.
This situation arises in the `gdb.threads/threadapply.exp` test which
kills and removes the inferior as part of a "thread apply" command.
gdb/ChangeLog:
* thread.c (thr_try_catch_cmd): Print thread name.
All these functions have their implementations in dwarf2/read.c, so move
their declarations to dwarf2/read.h. Move the doc to the header, at the
same time.
gdb/ChangeLog:
* dwarf2/loc.h (dwarf2_fetch_die_loc_sect_off,
dwarf2_fetch_die_loc_cu_off, dwarf2_fetch_constant_bytes,
dwarf2_fetch_die_type_sect_off): Move to...
* dwarf2/read.h (dwarf2_fetch_die_loc_sect_off,
dwarf2_fetch_die_loc_cu_off, dwarf2_fetch_constant_bytes,
dwarf2_fetch_die_type_sect_off): ... here.
* dwarf2/read.c (dwarf2_fetch_die_loc_sect_off,
dwarf2_fetch_die_loc_cu_off, dwarf2_fetch_constant_bytes,
dwarf2_fetch_die_type_sect_off): Move doc to header file.
Initially, gdb sets the language to auto/c:
...
$ gdb -q
(gdb) show language
The current source language is "auto; currently c".
...
And after loading a c++ executable, that changes to auto/c++:
...
(gdb) file a.out
Reading symbols from a.out...
(gdb) show language
The current source language is "auto; currently c++".
...
Now consider setting the language manually to c:
...
$ gdb -q
(gdb) show language
The current source language is "auto; currently c".
(gdb) set language c
(gdb) show language
The current source language is "c".
...
The resulting language is manual/c.
Surprisingly, a subsequent load of the c++ executable:
...
(gdb) file a.out
Reading symbols from a.out...
(gdb) show language
The current source language is "c++".
...
gets us language manual/c++.
Loading the file should get us either:
- auto/c++, or
- manual/c.
That is, either the manual setting should be reset by loading, or the manual
setting should persist.
Fix this in the manual/c fashion. [ Though we could make some gdb setting to
choose one or the other. ]
Build and reg-tested on x86_64-linux.
[ Note: In PR23710 comment 1 a cc1 binary is attached for which gdb is slow when
loading and settting a breakpoint on do_rpo_vn:
...
$ time.sh gdb cc1 -batch -ex "b do_rpo_vn"
Breakpoint 1 at 0xd40e30: do_rpo_vn. (2 locations)
maxmem: 1463496
real: 8.88
user: 8.59
system: 0.35
...
This fix enables a speedup by manually setting the language before
loading, reducing executing time with ~17%, due to not having to load the full
symtab containing main:
...
$ time.sh gdb -iex "set language c++" cc1 -batch -ex "b do_rpo_vn"
Breakpoint 1 at 0xd40e30: do_rpo_vn. (2 locations)
maxmem: 1067308
real: 7.36
user: 7.14
system: 0.28
... ]
gdb/ChangeLog:
2020-02-26 Tom de Vries <tdevries@suse.de>
PR gdb/25603
* symfile.c (set_initial_language): Exit-early if
language_mode == language_mode_manual.
gdb/testsuite/ChangeLog:
2020-02-26 Tom de Vries <tdevries@suse.de>
PR gdb/25603
* gdb.base/persistent-lang.cc: New test.
* gdb.base/persistent-lang.exp: New file.
The implementation is in dwarf2/read.c, so the declaration belongs in
dwarf2/read.h. Also, move the documentation there.
gdb/ChangeLog:
* dwarf2/loc.h (dwarf2_read_addr_index): Move...
* dwarf2/read.h (dwarf2_read_addr_index): ... here.
* dwarf2/read.c (dwarf2_read_addr_index): Move doc to header.
This commit adds support for negative Fortran array strides in one
limited case, that is the case of a single element array with a
negative array stride.
The changes in this commit will be required in order for more general
negative array stride support to work correctly, however, right now
other problems in GDB prevent negative array strides from working in
the general case.
The reason negative array strides don't currently work in the general
case is that when dealing with such arrays, the base address for the
objects data is actually the highest addressed element, subsequent
elements are then accessed with a negative offset from that address,
and GDB is not currently happy with this configuration.
The changes here can be summarised as, stop treating signed values as
unsigned, specifically, the array stride, and offsets calculated using
the array stride.
This issue was identified on the mailing list by Sergio:
https://sourceware.org/ml/gdb-patches/2020-01/msg00360.html
The test for this issue is a new one written by me as the copyright
status of the original test is currently unknown.
gdb/ChangeLog:
* gdbtypes.c (create_array_type_with_stride): Handle negative
array strides.
* valarith.c (value_subscripted_rvalue): Likewise.
gdb/testsuite/ChangeLog:
* gdb.fortran/derived-type-striding.exp: Add a new test.
* gdb.fortran/derived-type-striding.f90: Add pointer variable for
new test.
Just a trivial typo fix in a comment.
gdb/ChangeLog
2020-02-25 Luis Machado <luis.machado@linaro.org>
* aarch64-tdep.c (aarch64_vnv_type): Fix comment typo.
Since its implementation is in dwarf2/read.c, its declaration belongs in
dwarf2/read.h. Move the documentation to the .h at the same time.
gdb/ChangeLog:
* loc.h (dwarf2_get_die_type): Move to...
* read.h (dwarf2_get_die_type): ... here.
* read.c (dwarf2_get_die_type): Move doc to header.
This will prevent this script from updating the copyright year range
for those files.
Note that aclocal.m4 and configure are already in the EXCLUDE_ALL_LIST,
so they don't need to be added to the EXCLUDE_LIST.
gdb/ChangeLog:
* copypright.py (EXCLUDE_LIST): Add 'gnulib/config.in' and
'gnulib/Makefile.in' to the list.
I noticed that setup_type_unit_groups leaks the symtab vector -- it
allocates this with XNEWVEC, but from what I can tell, nothing frees
it. This patch changes it to use XOBNEWVEC.
Also, the type_unit_unshareable::num_symtabs member is assigned but
never read. So, this removes it.
gdb/ChangeLog
2020-02-24 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct type_unit_unshareable) <num_symtabs>:
Remove.
* dwarf2/read.c (dwarf2_cu::setup_type_unit_groups): Use
XOBNEWVEC.
This converts the IS_TYPE_UNIT_GROUP to a method on
dwarf2_per_cu_data.
gdb/ChangeLog
2020-02-24 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct dwarf2_per_cu_data) <type_unit_group_p>:
New method.
* dwarf2/read.c (IS_TYPE_UNIT_GROUP): Remove.
(dw2_do_instantiate_symtab, dw2_get_file_names)
(build_type_psymtab_dependencies, load_full_type_unit): Update.
This simplifies the setting and clearing of reading_partial_symbols,
by using scoped_restore in the function that reads partial symbols.
gdb/ChangeLog
2020-02-24 Tom Tromey <tom@tromey.com>
* dwarf2read.c (dwarf2_build_psymtabs_hard): Use
make_scoped_restore.
(dwarf2_psymtab::read_symtab): Don't clear
reading_partial_symbols.
Consider a test-case compiled with -g:
...
int main (void) {
static int b = 2;
return 0;
}
...
When running info locals in main, we get:
...
(gdb) info locals
No locals.
...
The info locals documentation states:
...
Print the local variables of the selected frame, each on a separate line.
These are all variables (declared either static or automatic) accessible at
the point of execution of the selected frame.
...
So, "info locals" should have printed static variable b.
The variable is present in dwarf info:
...
<2><14a>: Abbrev Number: 6 (DW_TAG_variable)
<14b> DW_AT_name : b
<153> DW_AT_const_value : 2
...
but instead of a location attribute, it has a const_value attribute, which
causes the corresponding symbol to have LOC_CONST, which causes info locals to
skip it.
Fix this by handling LOC_CONST in iterate_over_block_locals.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-02-24 Tom de Vries <tdevries@suse.de>
PR gdb/25592
* stack.c (iterate_over_block_locals): Handle LOC_CONST.
gdb/testsuite/ChangeLog:
2020-02-24 Tom de Vries <tdevries@suse.de>
PR gdb/25592
* gdb.base/info-locals-unused-static-var.c: New test.
* gdb.base/info-locals-unused-static-var.exp: New file.
With test-case gdb.gdb/unittest.exp, I run into:
...
(gdb) maintenance selftest^M
...
Running selftest help_doc_invariants.^M
help doc broken invariant: command 'layout next' help doc first line is \
not terminated with a '.' character^M
help doc broken invariant: command 'layout prev' help doc first line is \
not terminated with a '.' character^M
help doc broken invariant: command 'layout regs' help doc first line is \
not terminated with a '.' character^M
Self test failed: self-test failed at help-doc-selftests.c:95^M
...
Fix this by adding the missing '.' character.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-02-24 Tom de Vries <tdevries@suse.de>
* tui/tui-layout.c (_initialize_tui_layout): Fix help messages for
commands layout next/prev/regs.
I noticed that dwarf2_compile_expr_to_ax can be static. Nothing
outside of loc.c calls it.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* dwarf2/loc.h (dwarf2_compile_expr_to_ax): Don't declare.
* dwarf2/loc.c (dwarf2_compile_expr_to_ax): Now static.
I noticed that the TUI_DISASM_WIN macro cast the disassembly window to
a base type, rather than its correct type. This patch fixes this
oversight.
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-data.h (TUI_DISASM_WIN): Cast to tui_disasm_window.
Change-Id: Ied3dbac9ef3dc48ceb9e0850fe4ada3c316dd769
This adds "usage" text to the help for all all the TUI commands. In
some cases the usage is borderline, but I tend to think being complete
is preferable.
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (_initialize_tui_win): Add usage text.
* tui/tui-stack.c (_initialize_tui_stack): Add usage text.
* tui/tui-regs.c (_initialize_tui_regs): Add usage text.
* tui/tui.c (_initialize_tui): Add usage text.
Change-Id: I727f7a7cfc03efa248ef98f30a18be393819e30b
This changes a couple of TUI commands to use error_no_arg. The
commands are also simplified a bit, and changed to use other gdb CLI
utility functions like skip_to_space. This lets us removes a couple
of defines that don't interact properly with gettext.
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_set_focus_command)
(tui_set_win_height_command): Use error_no_arg.
(_initialize_tui_win): Update help text.
(FOCUS_USAGE, WIN_HEIGHT_USAGE): Don't define.
Change-Id: I2bf95c2e5cfe1472d068388fa39f0cf07591b76c
This patch adds support for writing new TUI windows in Python.
2020-02-22 Tom Tromey <tom@tromey.com>
* NEWS: Add entry for gdb.register_window_type.
* tui/tui-layout.h (window_factory): New typedef.
(tui_register_window): Declare.
* tui/tui-layout.c (saved_tui_windows): New global.
(tui_apply_current_layout): Use it.
(tui_register_window): New function.
* python/python.c (do_start_initialization): Call
gdbpy_initialize_tui.
(python_GdbMethods): Add "register_window_type" function.
* python/python-internal.h (gdbpy_register_tui_window)
(gdbpy_initialize_tui): Declare.
* python/py-tui.c: New file.
* Makefile.in (SUBDIR_PYTHON_SRCS): Add py-tui.c.
gdb/doc/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* python.texi (Python API): Add menu item.
(TUI Windows In Python): New node.
gdb/testsuite/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* gdb.python/tui-window.exp: New file.
* gdb.python/tui-window.py: New file.
Change-Id: I85fbfb923a1840450a00a7dce113a05d7f048baa
do_tui_putc has some code to remove annotations from gdb output. This
was added in 2001, see commit a198b876bb.
However, I think this code is not needed. It seems very unlikely to
enable both annotations and the TUI, and in any case I think this is
something that should not be supported.
So, this patch removes this code.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-io.c (do_tui_putc): Don't omit annotations.
Change-Id: I05728110365a362d37c9821df9c8779316100bb8
I noticed that the TUI had two functions with similar names:
tui_set_win_focus_to and tui_set_win_with_focus.
However, one was just an implementation detail of the latter. So,
this patch removes tui_set_win_with_focus entirely, to avoid any
temptation to call it.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_set_win_focus_to): Move to tui-data.c.
* tui/tui-data.h (tui_set_win_with_focus): Don't declare.
* tui/tui-data.c (tui_set_win_with_focus): Remove.
(tui_set_win_focus_to): Move from tui-win.c.
Change-Id: Idffddab773436bdf80d55480906d76b292981ef2
This adds a new global that maps from window names to window
constructor functions, and then changes tui_get_window_by_name and
validate_window_name to use it. This is another step toward
user-defined window types.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-layout.c (make_standard_window, get_locator_window): New
functions.
(known_window_types): New global.
(tui_get_window_by_name): Reimplement.
(initialize_known_windows): New function.
(validate_window_name): Rewrite.
(_initialize_tui_layout): Call initialize_known_windows.
Change-Id: I9037aac550299b9d945899220a30c2d3af9dd0de
TUI windows no longer need to store their type -- there's only a
single spot that uses this information, and it can be changed to use
dynamic_cast. (It could be cleaned up even more, by using a virtual
method, but I haven't done so.) This patch removes the "type" field
from tui_gen_win_info, and this in turn allows removing a couple of
enumerator constants.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui.h (enum tui_win_type) <LOCATOR_WIN, DATA_ITEM_WIN>:
Remove constants.
* tui/tui-winsource.h (struct tui_source_window_base)
<tui_source_window_base>: Remove parameter.
* tui/tui-winsource.c
(tui_source_window_base::tui_source_window_base): Remove
parameter.
(tui_source_window_base::refill): Update.
* tui/tui-stack.h (struct tui_locator_window)
<tui_locator_window>: Update.
* tui/tui-source.h (struct tui_source_window) <tui_source_window>:
Default the constructor.
* tui/tui-regs.h (struct tui_data_item_window)
<tui_data_item_window>: Default the constructor.
(struct tui_data_window) <tui_data_window>: Likewise.
* tui/tui-disasm.h (struct tui_disasm_window) <tui_disasm_window>:
Default the constructor.
* tui/tui-data.h (struct tui_gen_win_info) <tui_gen_win_info>:
Default the constructor.
<type>: Remove.
(struct tui_win_info) <tui_win_info>: Default the constructor.
* tui/tui-data.c (tui_win_info::tui_win_info): Remove.
* tui/tui-command.h (struct tui_cmd_window) <tui_cmd_window>:
Default the constructor.
Change-Id: I594cd07d2e0bba71ad594a6fb263904ce2febcd6
tui_delete_invisible_windows is only needed after applying a layout,
and tui_make_all_invisible is only needed before applying a layout.
This patch removes these functions, in favor of doing this management
directly in tui_apply_current_layout. This is needed so that the
lifetimes of non-built-in windows will be properly managed.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-wingeneral.h (tui_make_all_invisible): Don't declare.
* tui/tui-wingeneral.c (tui_make_all_invisible): Remove.
* tui/tui-win.c (tui_resize_all): Don't call
tui_delete_invisible_windows.
* tui/tui-layout.c (tui_apply_current_layout): Delete windows when
done.
(tui_set_layout): Update.
(tui_add_win_to_layout): Don't call tui_delete_invisible_windows.
* tui/tui-data.h (tui_delete_invisible_windows): Don't declare.
* tui/tui-data.c (tui_delete_invisible_windows): Remove.
Change-Id: Ia3603b021dcb7ec31700a4a32640cd09b00b8f3b
This changes tui_partial_win_by_name to correctly handle an ambiguous
name prefix. This will be important once the user can register new
window types.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_partial_win_by_name): Handle ambiguity
correctly.
Change-Id: I59aaacd697eeab649164183457ef722dae58d60d
This reimplements tui_next_win and tui_prev_win. Now they account for
the possibility of windows not on tui_win_list.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-data.c (tui_next_win, tui_prev_win): Reimplement.
Change-Id: Ifcd402f76fe0a16e0fe9275a185d550279c01660
This changes the TUI to track all the instantiated windows in a new
global vector. After this, iteration over TUI windows is done by
simply iterating over this vector.
This approach makes it simpler to define new window types. In
particular, a subsequent patch will add the ability to define a TUI
window from Python.
Note that this series will not remove tui_win_list. This will
continue to exist in parallel, only because it was simpler to leave
this alone. Perhaps it could still be removed in the future.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.h (struct tui_source_window_iterator)
<inner_iterator>: New etytypedef.
<tui_source_window_iterator>: Take "end" parameter.
<tui_source_window_iterator>: Take iterator.
<operator*, advance>: Update.
<m_iter>: Change type.
<m_end>: New field.
(struct tui_source_windows) <begin, end>: Update.
* tui/tui-layout.c (tui_windows): New global.
(tui_apply_current_layout): Clear tui_windows.
(tui_layout_window::apply): Update tui_windows.
* tui/tui-data.h (tui_windows): Declare.
(all_tui_windows): Now inline function.
(class tui_window_iterator, struct all_tui_windows): Remove.
Change-Id: I6ab77976d6326f427178f725434f8f82046e0bbf
This changes the TUI layout engine to add horizontal splitting. Now,
windows can be side-by-side.
A horizontal split is defined using the "-horizontal" parameter to
"tui new-layout".
This also adds the first "winheight" test to the test suite. One open
question is whether we want a new "winwidth" command, now that
horizontal layouts are possible. This is easily done using the
generic layout code.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
PR tui/17850:
* tui/tui-win.c (tui_gen_win_info::max_width): New method.
* tui/tui-layout.h (class tui_layout_base) <get_sizes>: Add
"height" argument.
(class tui_layout_window) <get_sizes>: Likewise.
(class tui_layout_split) <tui_layout_split>: Add "vertical"
argument.
<get_sizes>: Add "height" argument.
<m_vertical>: New field.
* tui/tui-layout.c (tui_layout_split::clone): Update.
(tui_layout_split::get_sizes): Add "height" argument.
(tui_layout_split::adjust_size, tui_layout_split::apply): Update.
(tui_new_layout_command): Parse "-horizontal".
(_initialize_tui_layout): Update help string.
(tui_layout_split::specification): Add "-horizontal" when needed.
* tui/tui-layout.c (tui_layout_window::get_sizes): Add "height"
argument.
* tui/tui-data.h (struct tui_gen_win_info) <max_width, min_width>:
New methods.
gdb/doc/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
PR tui/17850:
* gdb.texinfo (TUI Commands): Document horizontal layouts.
gdb/testsuite/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
PR tui/17850:
* gdb.tui/new-layout.exp: Add horizontal layout and winheight
tests.
Change-Id: I38b35e504f34698578af86686be03c0fefd954ae
This changes tui_layout_base::adjust_size to return a new enum type.
I broke this out into a separate patch because it simplifies a
subsequent patch.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-layout.h (enum tui_adjust_result): New.
(class tui_layout_base) <adjust_size>: Return tui_adjust_result.
(class tui_layout_window) <adjust_size>: Return
tui_adjust_result. Rewrite.
(class tui_layout_split) <adjust_size>: Return tui_adjust_result.
* tui/tui-layout.c (tui_layout_split::adjust_size): Update.
Change-Id: I821b48ab06a9b9485875e147bd08a3bc46b900a0
The new TUI layout engine has support for "sub-layouts" -- this is a
layout that includes another layout as a child. A sub-layout is
treated as a unit when allocating space.
There's not a very strong reason to use sub-layouts currently. This
patch exists to introduce the idea, and to simplify the subsequent
patch that adds horizontal layouts -- where sub-layouts are needed.
Because this patch won't go in on its own, I chose to defer
documenting this change until the subsequent horizontal layout patch.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-layout.h (class tui_layout_split) <add_split>: Change
parameter and return types.
(class tui_layout_base) <specification>: Add "depth".
(class tui_layout_window) <specification>: Add "depth".
(class tui_layout_split) <specification>: Add "depth".
* tui/tui-layout.c (tui_layout_split::add_split): Change parameter
and return types.
(tui_new_layout_command): Parse sub-layouts.
(_initialize_tui_layout): Update help string.
(tui_layout_window::specification): Add "depth".
(add_layout_command): Update.
gdb/testsuite/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* gdb.tui/new-layout.exp: Add sub-layout tests.
Change-Id: Iddf52d067a552c168b8a67f29caf7ac86404b10c
This adds a new command, "tui new-layout". This command can be used
to define a new TUI window layout.
The command is used like:
(gdb) tui new-layout name src 1 regs 1 status 0 cmd 1
The first argument is the name of the layout. In this example, it is
"name", so the new layout could be seen by "layout name".
Subsequent arguments come in pairs, where the first item in a pair is
the name of a window, and the second item in a pair is the window's
weight. A weight is just an integer -- a window's allocated size is
proportional to the total of the weights given. So, in the above
example, all windows will have the same size (the status windows's
weight does not matter, because it has fixed height).
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* NEWS: Add "tui new-layout" item.
* tui/tui-layout.c (add_layout_command): Return cmd_list_element.
Add new-layout command to help text.
(validate_window_name): New function.
(tui_new_layout_command): New function.
(_initialize_tui_layout): Register "new-layout".
(tui_layout_window::specification): New method.
(tui_layout_window::specification): New method.
* tui/tui-layout.h (class tui_layout_base) <specification>: New
method.
(class tui_layout_window) <specification>: New method.
(class tui_layout_split) <specification>: New method.
gdb/doc/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* gdb.texinfo (TUI Overview): Mention user layouts.
(TUI Commands): Document "tui new-layout".
gdb/testsuite/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* gdb.tui/new-layout.exp: New file.
Change-Id: Id7c3ace20ab1e8924f8f4ad788f40210f58a5c05
This changes the TUI so that the available layouts are no longer
completely hard-coded. "enum tui_layout_type" is removed, and then
all the fallout from this is fixed up.
This patch also reimplements the "layout" command to be a prefix
command. The concrete layouts are simply sub-commands now. This
provides completion and correct abbreviation behavior for free.
Finally, this also changes the name of the locator window to "status".
This matches the documentation and will be exposed to the user in a
subsequent patch.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui.c (tui_enable): Call tui_set_initial_layout.
* tui/tui-win.c (window_name_completer): Update comment.
* tui/tui-layout.h (class tui_layout_base) <replace_window>:
Declare method.
(class tui_layout_window) <replace_window>: Likewise.
(class tui_layout_split) <replace_window>: Likewise.
(tui_set_layout): Don't declare.
(tui_set_initial_layout): Declare function.
* tui/tui-layout.c (layouts, applied_skeleton, src_regs_layout)
(asm_regs_layout): New globals.
(tui_current_layout, show_layout): Remove.
(tui_set_layout, tui_add_win_to_layout): Rewrite.
(find_layout, tui_apply_layout): New function.
(layout_completer): Remove.
(tui_next_layout): Reimplement.
(tui_next_layout_command): New function.
(tui_set_initial_layout, tui_prev_layout_command): New functions.
(tui_regs_layout): Reimplement.
(tui_regs_layout_command): New function.
(extract_display_start_addr): Rewrite.
(next_layout, prev_layout): Remove.
(tui_layout_window::replace_window): New method.
(tui_layout_split::replace_window): New method.
(destroy_layout): New function.
(layout_list): New global.
(add_layout_command): New function.
(initialize_layouts): Update.
(tui_layout_command): New function.
(_initialize_tui_layout): Install "layout" commands.
* tui/tui-data.h (enum tui_layout_type): Remove.
(tui_current_layout): Don't declare.
Change-Id: I9b5f7ab3ce838d6b340b8c373ef649a8e0a74b73
This reimplements the low-level layout function that is used by the
"tui reg" command. Now it simply calls into the existing "layout"
command, though this will be changed again in a subsequent patch. The
rationale for this patch is that it makes it simpler to remove
"enum tui_layout_type".
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-regs.c (tui_reg_layout): Remove.
(tui_reg_command): Use tui_regs_layout.
* tui/tui-layout.h (tui_reg_command): Declare.
* tui/tui-layout.c (tui_reg_command): New function.
Change-Id: I0ca6884e2967005e7d3fbf5f13a0ac8f9c3298cf
The TUI "C-x 1" key binding removes TUI windows, based on the current
layout. With user-defined layouts, this is no longer easy to do.
This patch changes "C-x 1" to simply delete windows, leaving just the
focus window, the locator, and the command window.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui.c (tui_rl_delete_other_windows): Call
tui_remove_some_windows.
* tui/tui-layout.h (class tui_layout_base) <remove_windows>:
Declare method.
(class tui_layout_window) <remove_windows>: New method.
(class tui_layout_split) <remove_windows>: Declare.
(tui_remove_some_windows): Declare.
* tui/tui-layout.c (tui_remove_some_windows): New function.
(tui_layout_split::remove_windows): New method.
Change-Id: If186f9c3f263913e963b965204481d1b4385c6d4
The TUI "C-x 2" binding tries to switch to a different layout based on
the current layout. Once user-defined layouts are available, this
won't really make sense. I wasn't entirely sure how to handle this.
This patch changes the binding to simply cycle through the existing
layouts. I considered this a reasonable, though not ideal,
compromise.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui.c (tui_rl_change_windows): Call tui_next_layout.
* tui/tui-layout.h (tui_next_layout): Declare.
* tui/tui-layout.c (tui_next_layout): New function.
Change-Id: Ic101f0e3831a4235a048b3090ef60f025f7449bb
tui_data_window creates new curses windows, but does not pass in
coordinates relative to the data window's origin. This means that the
data window could only ever be displayed as the topmost window in a
layout. This is not a currently problem, because all the existing
layouts do this; but a subsequent patch will add user-defined layouts,
which could do otherwise.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-regs.c (tui_data_window::display_registers_from): Use
correct coordinates.
Change-Id: I5101f2b2869557b87381ebdeebd9b7fd28687831
tui_add_win_to_layout is only ever called for the source or assembly
windows. This simplifies the function by removing the DATA_WIN case.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-layout.h (tui_add_win_to_layout): Add comment.
* tui/tui-layout.c (tui_add_win_to_layout): Add assert. Remove
DATA_WIN case.
Change-Id: Idfca902c6c90153acc5d19af4c33aa74bc3caf31
This is a minor cleanup to change tui_get_low_disassembly_address to
use TUI_DISASM_WIN, rather than the tui_win_list array. This is more
in line with what the rest of the TUI code does.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* tui/tui-disasm.c (tui_get_low_disassembly_address): Use
TUI_DISASM_WIN, not tui_win_list.
Change-Id: I999335ee3f63a4b570e84f320236b78f2bd5b780
This changes gdb to use the "variable" style when printing field
names. I've added new tests for C and Rust, but not other languages.
I chose "variable" because that seemed most straightforward. However,
another option would be to introduce a new "field" style. Similarly,
this patch uses the variable style for enumerator constants -- but
again, a new style could be used if that's preferred.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* valprint.c (generic_val_print_enum_1)
(val_print_type_code_flags): Style member names.
* rust-lang.c (val_print_struct, rust_print_enum)
(rust_print_struct_def, rust_internal_print_type): Style member
names.
* p-valprint.c (pascal_object_print_value_fields): Style member
names. Only call fprintf_symbol_filtered for static members.
* m2-typeprint.c (m2_record_fields, m2_enum): Style member names.
* f-valprint.c (f_val_print): Style member names.
* f-typeprint.c (f_type_print_base): Style member names.
* cp-valprint.c (cp_print_value_fields): Style member names. Only
call fprintf_symbol_filtered for static members.
(cp_print_class_member): Style member names.
* c-typeprint.c (c_print_type_1, c_type_print_base_1): Style
member names.
* ada-valprint.c (ada_print_scalar): Style enum names.
(ada_val_print_enum): Likewise.
* ada-typeprint.c (print_enum_type): Style enum names.
gdb/testsuite/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* gdb.rust/rust-style.rs: New file.
* gdb.rust/rust-style.exp: New file.
* gdb.base/style.exp: Test structure printing.
* gdb.base/style.c (struct some_struct): New type.
(enum etype): New type.
(struct_value): New global.
Change-Id: I070e1293c6cc830c9ea916af8243410aa384e944
The introductory comment for partial_symtab has been mildly incorrect
since the partial symtab code was changed to allocate partial symtabs
with "new". This patch removes the incorrect text.
gdb/ChangeLog
2020-02-21 Tom Tromey <tom@tromey.com>
* psympriv.h (struct partial_symtab): Update comment.
My earlier patch to fix a declaration mismatch in mips-tdep.h missed a
couple of spots. Basically, I sent it too soon.
This patch fixes a couple more mismatches between a declaration (using
bfd_vma) and the definition (using CORE_ADDR).
gdb/ChangeLog
2020-02-21 Tom Tromey <tromey@adacore.com>
* mips-tdep.h (mips_pc_is_mips16, mips_pc_is_micromips): Parameter
type is CORE_ADDR.
I noticed a regression with board cc-with-dwz:
...
FAIL: gdb.cp/m-static.exp: static const int initialized elsewhere
FAIL: gdb.cp/m-static.exp: info variable everywhere
...
The problem started with commit 0494dbecdf "Consolidate partial symtab
dependency reading".
The commit replaces the dwarf2_psymtab::expand_psymtab specific reading of
dependencies, which contains a "dependencies[i]->user == NULL" test, with a
generic partial_symtab::read_dependencies call, which does not test the user
field.
This patch fixes the regression by adding back the test, in the generic
partial_symtab::read_dependencies.
Build and reg-tested on x86_64-linux.
Tested natively, as well as with boards cc-with-dwz and cc-with-dwz-m.
The patch fixes all 33 regressions with cc-with-dwz, and all 2929 regression
with cc-with-dwz-m.
gdb/ChangeLog:
2020-02-21 Tom de Vries <tdevries@suse.de>
PR gdb/25534
* psymtab.c (partial_symtab::read_dependencies): Don't read dependency
if dependencies[i]->user != NULL.
I am sending this patch on behalf of kmoy@google.com, who discovered the bug
and wrote the fix.
gdb_demangle can return null for strings that don't properly demangle. The null
check was mistakenly removed in commit 43816ebc33. Without this check, GDB
aborts when loading symbols from some binaries.
gdb/ChangeLog
2020-02-21 Ali Tamur <tamur@google.com>
* dwarf2/read.c (dwarf2_name): Add null check.
dwarf2_find_containing_comp_unit has this in its binary search:
if (mid_cu->is_dwz > offset_in_dwz
|| (mid_cu->is_dwz == offset_in_dwz
&& mid_cu->sect_off + mid_cu->length >= sect_off))
high = mid;
The intent here is to determine whether SECT_OFF appears in or before
MID_CU.
I believe this has an off-by-one error, and that the check should use
">" rather than ">=". If the two side are equal, then SECT_OFF
actually appears at the start of the next CU.
I've had this patch kicking around for ages but I forget how I found
the problem.
gdb/ChangeLog
2020-02-20 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf2_find_containing_comp_unit): Use ">", not
">=", in binary search.
(dwarf2_find_containing_comp_unit): New overload.
(run_test): New self-test.
(_initialize_dwarf2_read): Register new test.
According to the riscv privilege spec, some CSR are only valid when rv32 or
the specific extension is set. We extend the DECLARE_CSR and DECLARE_CSR_ALIAS
to record more informaton we need, and then check whether the CSR is valid
according to these information. We report warning message when the CSR is
invalid, so we have a choice between error and warning by --fatal-warnings
option. Also, a --no-warn/-W option is used to turn the warnings off, if
people don't want the warnings.
gas/
* config/tc-riscv.c (enum riscv_csr_class): New enum. Used to decide
whether or not this CSR is legal in the current ISA string.
(struct riscv_csr_extra): New structure to hold all extra information
of CSR.
(riscv_init_csr_hash): New function. According to the DECLARE_CSR and
DECLARE_CSR_ALIAS, insert CSR extra information into csr_extra_hash.
Call hash_reg_name to insert CSR address into reg_names_hash.
(md_begin): Call riscv_init_csr_hashes for each DECLARE_CSR.
(reg_csr_lookup_internal, riscv_csr_class_check): New functions.
Decide whether the CSR is valid according to the csr_extra_hash.
(init_opcode_hash): Update 'if (hash_error != NULL)' as hash_error is
not a boolean. This is same as riscv_init_csr_hash, so keep the
consistent usage.
* testsuite/gas/riscv/csr-dw-regnums.d: Add -march=rv32if option.
* testsuite/gas/riscv/priv-reg.d: Add f-ext by -march option.
* testsuite/gas/riscv/priv-reg-fail-fext.d: New testcase. The source
file is `priv-reg.s`, and the ISA is rv32i without f-ext, so the
f-ext CSR are not allowed.
* testsuite/gas/riscv/priv-reg-fail-fext.l: Likewise.
* testsuite/gas/riscv/priv-reg-fail-rv32-only.d: New testcase. The
source file is `priv-reg.s`, and the ISA is rv64if, so the
rv32-only CSR are not allowed.
* testsuite/gas/riscv/priv-reg-fail-rv32-only.l: Likewise.
include/
* opcode/riscv-opc.h: Extend DECLARE_CSR and DECLARE_CSR_ALIAS to
record riscv_csr_class.
opcodes/
* riscv-dis.c (print_insn_args): Updated since the DECLARE_CSR is changed.
gdb/
* riscv-tdep.c: Updated since the DECLARE_CSR is changed.
* riscv-tdep.h: Likewise.
* features/riscv/rebuild-csr-xml.sh: Generate the 64bit-csr.xml without
rv32-only CSR.
* features/riscv/64bit-csr.xml: Regernated.
binutils/
* dwarf.c: Updated since the DECLARE_CSR is changed.
There is currently a regression when using
'{putchar,fputc}_unfiltered' with 'puts_unfiltered' which was
introduced by one of the commits that reworked the unfiltered print
code.
The regression makes it impossible to use '{putchar,fputc}_unfiltered'
with 'puts_unfiltered', because the former writes directly to the
ui_file stream using 'stream->write', while the latter uses a buffered
mechanism (see 'wrap_buffer') and delays the printing.
If you do a quick & dirty hack on e.g. top.c:show_gdb_datadir:
@@ -2088,6 +2088,13 @@ static void
show_gdb_datadir (struct ui_file *file, int from_tty,
struct cmd_list_element *c, const char *value)
{
+ putchar_unfiltered ('\n');
+ puts_unfiltered ("TEST");
+ putchar_unfiltered ('>');
+ puts_unfiltered ("PUTS");
+ putchar_unfiltered ('\n');
rebuild GDB and invoke the "show data-directory" command, you will
see:
(gdb) show data-directory
>
TESTPUTSGDB's data directory is "/usr/local/share/gdb".
Note how the '>' was printed before the output, and "TEST" and "PUTS"
were printed together.
My first attempt to fix this was to always call 'flush_wrap_buffer' at
the end of 'fputs_maybe_filtered', since it seemed to me that the
function should always print what was requested. But I wasn't sure
this was the right thing to do, so I talked to Tom on IRC and he gave
me another, simpler idea: make '{putchar,fputc}_unfiltered' call into
the already existing 'fputs_unfiltered' function.
This patch implements the idea. I regtested it on the Buildbot, and
no regressions were detected.
gdb/ChangeLog:
2020-02-20 Sergio Durigan Junior <sergiodj@redhat.com>
Tom Tromey <tom@tromey.com>
* utils.c (fputs_maybe_filtered): Call 'stream->puts' instead
of 'fputc_unfiltered'.
(putchar_unfiltered): Call 'fputc_unfiltered'.
(fputc_unfiltered): Call 'fputs_unfiltered'.
The motivation behind this commit is to make it easier to bundle the
Python *.py library files with GDB when statically linking GDB against
libpython. The Python files will be manually added into the GDB
installation tree, and GDB should be able to find them at run-time.
The installation tree will look like this:
.
|-- bin/
|-- include/
|-- lib/
| `-- python3.8/
`-- share/
The benefit here is that the entire installation tree can be bundled
into a single archive and copied to another machine with a different
version of Python installed, and GDB will still work, including its
Python support.
In use the new configure options would be used something like this,
first build and install a static Python library:
mkdir python
cd python
# Clone or download Python into a src/ directory.
mkdir build
export PYTHON_INSTALL_PATH=$PWD/install
cd build
../src/configure --disable-shared --prefix=$PYTHON_INSTALL_PATH
make
make install
Now build and install GDB:
mkdir binutils-gdb
cd binutils-gdb
# Clone or download GDB into a src/ directory.
mkdir build
export GDB_INSTALL_DIR=$PWD/install
cd build
../src/configure \
--prefix=$GDB_INSTALL_DIR \
--with-python=$PYTHON_INSTALL_PATH/bin/python3 \
--with-python-libdir=$GDB_INSTALL_DIR/lib
make all-gdb
make install-gdb
Finally, copy the Python libraries into the GDB install:
cp -r $PYTHON_INSTALL_DIR/lib/python3.8/ $GDB_INSTALL_DIR/lib
After this the Python src, build, and install directories are no
longer needed and can be deleted.
If the new --with-python-libdir option is not used then the existing
behaviour is left unchanged, GDB will look for the Python libraries in
the lib/ directory within the python path. The concatenation of the
python prefix and the string 'lib/' is now done at configure time,
rather than at run time in GDB as it was previous, however, this was
never something that the user had dynamic control over, so there's no
loss of functionality.
gdb/ChangeLog:
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Add --with-python-libdir option.
* main.c: Use WITH_PYTHON_LIBDIR.
This patch simplifies compute_and_set_names in a couple of ways.
First, it changes one spot to use obstack_strndup, which is
equivalent, but more concise.
Second, the function ends with two calls to symbol_set_demangled_name.
This can be simplified to a single call.
gdb/ChangeLog
2020-02-19 Tom Tromey <tom@tromey.com>
* symtab.c (general_symbol_info::compute_and_set_names): Use
obstack_strndup. Simplify call to symbol_set_demangled_name.
This is a simple cleanup. These functions used to use the objfile's
obstack for allocation in the hash tables, but they don't anymore.
Remove the unnecessary objfile parameters, which in turn allows removing
some local variables.
gdb/ChangeLog:
* dwarf2/read.c (allocate_signatured_type_table,
allocate_dwo_unit_table, allocate_type_unit_groups_table,
allocate_dwo_file_hash_table, allocate_dwp_loaded_cutus_table):
Remove objfile parameter, update all callers.
A build where CORE_ADDR is not the same as bfd_vma pointed out that
mips_pc_is_mips is declared using bfd_vma as the parameter type, but
defined using CORE_ADDR. This patch fixes the declaration.
gdb/ChangeLog
2020-02-19 Tom Tromey <tromey@adacore.com>
* mips-tdep.h (mips_pc_is_mips): Parameter type is CORE_ADDR.
I happened across a spot that was still using obstack_alloc and
strcpy, rather than obstack_strdup. This patch makes the obvious fix.
gdb/ChangeLog
2020-02-19 Tom Tromey <tromey@adacore.com>
* ada-lang.c (cache_symbol): Use obstack_strdup.
GCC's config/ChangeLog since the last time this merge was done
(in the binutils-gdb commit 0b4d000cc4) is included at the
end of this commit message.
It is worth noting that the binutils-gdb commit 301a9420d9
added the file config/debuginfod.m4 which is not present in GCC's
config/ directory. This file is preserved, unmodified, after this
commit.
In order to regenerate all of the configure files, I configured with
--enable-maintainer-mode, and built the 'all' target. I then did the
same thing on a source tree without this patch, and only committed
those files that changed when this patch was added.
GCC's config/ChangeLog entries:
2020-02-12 Sandra Loosemore <sandra@codesourcery.com>
PR libstdc++/79193
PR libstdc++/88999
* no-executables.m4: Use a non-empty program to test for linker
support.
2020-02-01 Andrew Burgess <andrew.burgess@embecosm.com>
* lib-link.m4 (AC_LIB_LINKFLAGS_BODY): Update shell syntax.
2020-01-27 Andrew Burgess <andrew.burgess@embecosm.com>
* lib-link.m4 (AC_LIB_LINKFLAGS_BODY): Add new
--with-libXXX-type=... option. Use this to guide the selection of
either a shared library or a static library.
2020-01-24 Maciej W. Rozycki <macro@wdc.com>
* toolexeclibdir.m4: New file.
2019-09-10 Christophe Lyon <christophe.lyon@st.com>
* futex.m4: Handle *-uclinux*.
* tls.m4 (GCC_CHECK_TLS): Likewise.
2019-09-06 Florian Weimer <fweimer@redhat.com>
* futex.m4 (GCC_LINUX_FUTEX): Include <unistd.h> for the syscall
function.
2019-07-08 Richard Sandiford <richard.sandiford@arm.com>
* bootstrap-Og.mk: New file.
2019-06-25 Kwok Cheung Yeung <kcy@codesourcery.com>
Andrew Stubbs <ams@codesourcery.com>
* gthr.m4 (GCC_AC_THREAD_HEADER): Add case for gcn.
2019-05-30 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
* ax_count_cpus.m4: New file.
2019-05-02 Richard Biener <rguenther@suse.de>
PR bootstrap/85574
* bootstrap-lto.mk (extra-compare): Set to gcc/lto1$(exeext).
2019-04-16 Martin Liska <mliska@suse.cz>
* bootstrap-lto-lean.mk: Filter out -flto in STAGEtrain_CFLAGS.
2019-04-09 Martin Liska <mliska@suse.cz>
* bootstrap-lto-lean.mk: New file.
2019-03-02 Johannes Pfau <johannespfau@gmail.com>
* mh-mingw: Also set __USE_MINGW_ACCESS flag for C++ code.
2018-10-31 Joseph Myers <joseph@codesourcery.com>
PR bootstrap/82856
* math.m4, tls.m4: Use AC_LANG_SOURCE.
Merge from binutils-gdb:
2018-06-19 Simon Marchi <simon.marchi@ericsson.com>
* override.m4 (_GCC_AUTOCONF_VERSION): Bump from 2.64 to 2.69.
config/ChangeLog:
* ax_count_cpus.m4: New file, backported from GCC.
* bootstrap-Og.mk: New file, backported from GCC.
* bootstrap-lto-lean.mk: New file, backported from GCC.
* bootstrap-lto.mk: Changes backported from GCC.
* futex.m4: Changes backported from GCC.
* gthr.m4: Changes backported from GCC.
* lib-link.m4: Changes backported from GCC.
* mh-mingw: Changes backported from GCC.
* no-executables.m4: Changes backported from GCC.
* tls.m4: Changes backported from GCC.
* toolexeclibdir.m4: New file, backported from GCC.
binutils/ChangeLog:
* configure: Regenerate.
gdb/ChangeLog:
* configure: Regenerate.
gdbserver/ChangeLog:
* configure: Regenerate.
gdbsupport/ChangeLog:
* configure: Regenerate.
intl/ChangeLog:
* configure: Regenerate.
libiberty/ChangeLog:
* configure: Regenerate.
zlib/ChangeLog.bin-gdb:
* configure: Regenerate.
I noticed that do_start_initialization, in python.c, checks the result
of xmalloc. However, xmalloc cannot fail, so this check is useless.
This patch also changes the code to use XNEWVEC.
gdb/ChangeLog
2020-02-19 Tom Tromey <tromey@adacore.com>
* python/python.c (do_start_initialization): Use XNEWVEC. Remove
NULL check.
Implement RISC-V/Linux support for both RV64 and RV32 systems, including
XML target description handling based on features determined, GPR and
FPR regset support including dynamic sizing of the latter, and software
breakpoint handling. Define two NT_FPREGSET regsets of a different size
matching the FPR sizes supported for generic `gdbserver' code to pick
from according to what the OS supplies.
Also handle a glibc bug where ELF_NFPREG is defined in terms of NFPREG,
however NFPREG is nowhere defined.
2020-02-19 Maciej W. Rozycki <macro@wdc.com>
Andrew Burgess <andrew.burgess@embecosm.com>
gdb/
* NEWS: Mention RISC-V GNU/Linux GDBserver support.
gdbserver/
* linux-riscv-low.cc: New file.
* Makefile.in (SFILES): Add linux-riscv-low.cc, arch/riscv.c,
and nat/riscv-linux-tdesc.c.
* configure.srv <riscv*-*-linux*> (srv_tgtobj)
(srv_linux_regsets, srv_linux_usrregs, srv_linux_thread_db):
Define.
In preparation for adding the RISC-V gdbserver, this commit
restructures the API for looking up target descriptions.
The current API is riscv_create_target_description, which creates a
target description from a riscv_gdbarch_features, but also caches the
created target descriptions so that for a given features object we
always get back the same target description object. This is important
for GDB due to the way gdbarch objects are reused.
As the same target description is always returned to GDB, and can be
returned multiple times, it is returned as a const, however, the
current cache actually stores a non-const target description. This is
improved in this patch so that the cache holds a const target
description.
For gdbsever, this caching of the target descriptions is not needed,
the gdbserver looks up one target description to describe the target
it is actually running on and that is it. Further the gdbserver
actually needs to modify the target description that is looked up, so
for the gdbsever, returning a const target description is not
acceptable.
This commit aims to address this by creating two parallel target
description APIs, on is the old riscv_create_target_description,
however, this no longer performs any caching, and just creates a new
target description, and returns it as non-const.
The second API is riscv_lookup_target_description, this one performs
the caching, and calls riscv_create_target_description to create a
target description when needed.
In order to make sure the correct API is used in the correct place I
have guarded the code using the GDBSERVER define. For GDB the
riscv_create_target_description is static, and not generally usable
throughout GDB, only the lookup API is global. In gdbserver, the
lookup functions, and the cache are not defined or created at all,
only the riscv_create_target_description API is available.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* arch/riscv.c (struct riscv_gdbarch_features_hasher): Only define
if GDBSERVER is not defined.
(riscv_tdesc_cache): Likewise, also store const target_desc.
(STATIC_IN_GDB): Define.
(riscv_create_target_description): Update declaration with
STATIC_IN_GDB.
(riscv_lookup_target_description): New function, only define if
GDBSERVER is not defined.
* arch/riscv.h (riscv_create_target_description): Declare only
when GDBSERVER is defined.
(riscv_lookup_target_description): New declaration when GDBSERVER
is not defined.
* nat/riscv-linux-tdesc.c (riscv_linux_read_description): Rename to...
(riscv_linux_read_features): ...this, and return
riscv_gdbarch_features instead of target_desc.
* nat/riscv-linux-tdesc.h: Include 'arch/riscv.h'.
(riscv_linux_read_description): Rename to...
(riscv_linux_read_features): ...this.
* riscv-linux-nat.c (riscv_linux_nat_target::read_description):
Update to use riscv_gdbarch_features and
riscv_lookup_target_description.
* riscv-tdep.c (riscv_find_default_target_description): Use
riscv_lookup_target_description instead of
riscv_create_target_description.
If a flag enum has value 0 and the enumeration type does not have an
enumerator with value 0, we currently print:
$1 = (unknown: 0x0)
I don't like the display of "unknown" here, since for flags, 0 is a
an expected value. It just means that no flags are set. This patch
makes it so that we print it as a simple 0 in this situation:
$1 = 0
If there is an enumerator with value 0, it is still printed using that
enumerator, for example (from the test):
$1 = FE_NONE
gdb/ChangeLog:
* valprint.c (generic_val_print_enum_1): When printing a flag
enum with value 0 and there is no enumerator with value 0, print
just "0" instead of "(unknown: 0x0)".
gdb/testsuite/ChangeLog:
* gdb.base/printcmds.exp (test_print_enums): Update expected
output.
When we print the "unknown" part of a flag enum, it is printed in
decimal. I think it would be more useful if it was printed in hex, as
it helps to determine which bits are set more than a decimal value.
gdb/ChangeLog:
* valprint.c (generic_val_print_enum_1): Print unknown part of
flag enum in hex.
gdb/testsuite/ChangeLog:
* gdb.base/printcmds.exp (test_print_enums): Expect hex values
for "unknown".
I have come across some uses cases where it would be desirable to treat
an enum that has duplicate values as a "flag enum". For example, this
one here [1]:
enum membarrier_cmd {
MEMBARRIER_CMD_QUERY = 0,
MEMBARRIER_CMD_GLOBAL = (1 << 0),
MEMBARRIER_CMD_GLOBAL_EXPEDITED = (1 << 1),
MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED = (1 << 2),
MEMBARRIER_CMD_PRIVATE_EXPEDITED = (1 << 3),
MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED = (1 << 4),
MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE = (1 << 5),
MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_SYNC_CORE = (1 << 6),
/* Alias for header backward compatibility. */
MEMBARRIER_CMD_SHARED = MEMBARRIER_CMD_GLOBAL,
};
The last enumerator is kept for backwards compatibility. Without this
patch, this enumeration wouldn't be considered a flag enum, because two
enumerators collide. With this patch, it would be considered a flag
enum, and the value 3 would be printed as:
MEMBARRIER_CMD_GLOBAL | MEMBARRIER_CMD_GLOBAL_EXPEDITED
Although if people prefer, we could display both MEMBARRIER_CMD_GLOBAL
and MEMBARRIER_CMD_SHARED in the result. It wouldn't be wrong, and
could perhaps be useful in case a bit may have multiple meanings
(depending on some other bit value).
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/membarrier.h?id=0bf999f9c5e74c7ecf9dafb527146601e5c848b9#n125
gdb/ChangeLog:
* dwarf2/read.c (update_enumeration_type_from_children): Allow
flag enums to contain duplicate enumerators.
* valprint.c (generic_val_print_enum_1): Update comment.
gdb/testsuite/ChangeLog:
* gdb.base/printcmds.c (enum flag_enum): Add FE_TWO_LEGACY
enumerator.
GDB has this feature where if an enum looks like it is meant to
represent binary flags, it will present the values of that type as a
bitwise OR of the flags that are set in the value.
The original motivation for this patch is to fix this behavior:
enum hello { AAA = 0x1, BBB = 0xf0 };
(gdb) p (enum hello) 0x11
$1 = (AAA | BBB)
This is wrong because the bits set in BBB (0xf0) are not all set in the
value 0x11, but GDB presents it as if they all were.
I think that enumerations with enumerators that have more than one bit
set should simply not qualify as "flag enum", as far as this
heuristic is concerned. I'm not sure what it means to have flags of
more than one bit. So this is what this patch implements.
I have added an assert in generic_val_print_enum_1 to make sure the flag
enum types respect that, in case they are used by other debug info
readers, in the future.
I've enhanced the gdb.base/printcmds.exp test to cover this case. I've
also added tests for printing flag enums with value 0, both when the
enumeration has and doesn't have an enumerator for value 0.
gdb/ChangeLog:
* dwarf2/read.c: Include "count-one-bits.h".
(update_enumeration_type_from_children): If an enumerator has
multiple bits set, don't treat the enumeration as a "flag enum".
* valprint.c (generic_val_print_enum_1): Assert that enumerators
of flag enums have 0 or 1 bit set.
gdb/testsuite/ChangeLog:
* gdb.base/printcmds.c (enum flag_enum): Prefix enumerators with
FE_, add FE_NONE.
(three): Update.
(enum flag_enum_without_zero): New enum.
(flag_enum_without_zero): New variable.
(enum not_flag_enum): New enum.
(three_not_flag): New variable.
* gdb.base/printcmds.exp (test_artificial_arrays): Update.
(test_print_enums): Add more tests for printing flag enums.
To help with readability, add the type displaced_step_closure_up, an
alias for std::unique_ptr<displaced_step_closure>, and use it throughout
the code base.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_displaced_step_copy_insn): Use
displaced_step_closure_up.
* aarch64-tdep.h (aarch64_displaced_step_copy_insn): Likewise.
(struct displaced_step_closure_up):
* amd64-tdep.c (amd64_displaced_step_copy_insn): Likewise.
* amd64-tdep.h (amd64_displaced_step_copy_insn): Likewise.
* arm-linux-tdep.c (arm_linux_displaced_step_copy_insn):
Likewise.
* gdbarch.sh (displaced_step_copy_insn): Likewise.
* gdbarch.c, gdbarch.h: Re-generate.
* i386-linux-tdep.c (i386_linux_displaced_step_copy_insn): Use
displaced_step_closure_up.
* i386-tdep.c (i386_displaced_step_copy_insn): Likewise.
* i386-tdep.h (i386_displaced_step_copy_insn): Likewise.
* infrun.h (displaced_step_closure_up): New type alias.
(struct displaced_step_inferior_state) <step_closure>: Change
type to displaced_step_closure_up.
* rs6000-tdep.c (ppc_displaced_step_copy_insn): Use
displaced_step_closure_up.
* s390-tdep.c (s390_displaced_step_copy_insn): Likewise.
While looking at the output of "maint info bfd" with multiple
inferiors, I noticed that there were duplicate entries for
.gnu_debugdata.
There is no reason to re-create this BFD each time it is needed. This
patch arranges to share the data.
gdb/ChangeLog
2020-02-14 Tom Tromey <tom@tromey.com>
* minidebug.c (gnu_debug_key): New global.
(find_separate_debug_file_in_section): Use it.
Change-Id: If139f89f0f07db33f399afdbcfbf5aaeffe4de46
This callback dynamically allocates a specialized displaced_step_closure, and
gives the ownership of the object to its caller. So I think it would make
sense for the callback to return an std::unique_ptr, this is what this patch
implements.
gdb/ChangeLog:
* gdbarch.sh (displaced_step_copy_insn): Change return type to an
std::unique_ptr.
* gdbarch.c: Re-generate.
* gdbarch.h: Re-generate.
* infrun.c (displaced_step_prepare_throw): Adjust to std::unique_ptr
change.
* aarch64-tdep.c (aarch64_displaced_step_copy_insn): Change return
type to std::unique_ptr.
* aarch64-tdep.h (aarch64_displaced_step_copy_insn): Likewise.
* amd64-tdep.c (amd64_displaced_step_copy_insn): Likewise.
* amd64-tdep.h (amd64_displaced_step_copy_insn): Likewise.
* arm-linux-tdep.c (arm_linux_displaced_step_copy_insn): Likewise.
* i386-linux-tdep.c (i386_linux_displaced_step_copy_insn): Likewise.
* i386-tdep.c (i386_displaced_step_copy_insn): Likewise.
* i386-tdep.h (i386_displaced_step_copy_insn): Likewise.
* rs6000-tdep.c (ppc_displaced_step_copy_insn): Likewise.
* s390-tdep.c (s390_displaced_step_copy_insn): Likewise.
displaced_step_inferior_state::reset and displaced_step_clear appear to
have the same goal, but they don't do the same thing.
displaced_step_inferior_state::reset clears more things than
displaced_step_clear, but it misses free'ing the closure, which
displaced_step_clear does.
This patch replaces displaced_step_clear's implementation with just a call to
displaced_step_inferior_state::reset. It then changes
displaced_step_inferior_state::step_closure to be a unique_ptr, to indicate the
fact that displaced_step_inferior_state owns the closure (and so that it is
automatically freed when the field is reset).
The test gdb.base/step-over-syscall.exp caught a problem when doing this, which
I consider to be a latent bug which my cleanup exposes. In
handle_inferior_event, in the TARGET_WAITKIND_FORKED case, if we displaced-step
over a fork syscall, we make sure to restore the memory that we used as a
displaced-stepping buffer in the child. We do so using the
displaced_step_inferior_state of the parent. However, we do it after calling
displaced_step_fixup for the parent, which clears the information in the
parent's displaced_step_inferior_state. It worked fine before, because
displaced_step_clear didn't completely clear the displaced_step_inferior_state
structure, so the required information (in this case the gdbarch) was
still available after clearing.
I fixed it by making GDB restore the child's memory before calling the
displaced_step_fixup on the parent. This way, the data in the
displaced_step_inferior_state structure is still valid when we use it for the
child. This is the error you would get in
gdb.base/step-over-syscall.exp without this fix:
/home/smarchi/src/binutils-gdb/gdb/gdbarch.c:3911: internal-error: ULONGEST gdbarch_max_insn_length(gdbarch*): Assertion `gdbarch != NULL' failed.
gdb/ChangeLog:
* infrun.c (get_displaced_step_closure_by_addr): Adjust to
std::unique_ptr.
(displaced_step_clear): Rename to...
(displaced_step_reset): ... this. Just call displaced->reset ().
(displaced_step_clear_cleanup): Rename to...
(displaced_step_reset_cleanup): ... this.
(displaced_step_prepare_throw): Adjust to std::unique_ptr.
(displaced_step_fixup): Likewise.
(resume_1): Likewise.
(handle_inferior_event): Restore child's memory before calling
displaced_step_fixup on the parent.
* infrun.h (displaced_step_inferior_state) <reset>: Adjust
to std::unique_ptr.
<step_closure>: Change type to std::unique_ptr.
For a fix I intend to submit, I would need a function that counts the
number of set bits in a word. There is __builtin_popcount that is
supported by gcc and clang, but there is also a gnulib module that wraps
that and provides a fallback for other compilers, so I think it would be
good to use it.
I also noticed that there is a bitcount function in arch/arm.c, so I
thought that as a first step I would replace that one with the gnulib
count-one-bits module. This is what this patch does.
The gnulib module provides multiple functions, with various parameter
length (unsigned int, unsigned long int, unsigned long long int), I
chose the one that made sense for each call site based on the argument
type.
gnulib/ChangeLog:
* update-gnulib.sh (IMPORTED_GNULIB_MODULES): Import
count-one-bits module.
* configure: Re-generate.
* aclocal.m4: Re-generate.
* Makefile.in: Re-generate.
* import/count-one-bits.c: New file.
* import/count-one-bits.h: New file.
* import/Makefile.am: Re-generate.
* import/Makefile.in: Re-generate.
* import/m4/gnulib-cache.m4: Re-generate.
* import/m4/gnulib-comp.m4: Re-generate.
* import/m4/count-one-bits.m4: New file.
gdb/ChangeLog:
* arm-tdep.c: Include count-one-bits.h.
(cleanup_block_store_pc): Use count_one_bits.
(cleanup_block_load_pc): Use count_one_bits.
(arm_copy_block_xfer): Use count_one_bits.
(thumb2_copy_block_xfer): Use count_one_bits.
(thumb_copy_pop_pc_16bit): Use count_one_bits.
* arch/arm-get-next-pcs.c: Include count-one-bits.h.
(thumb_get_next_pcs_raw): Use count_one_bits.
(arm_get_next_pcs_raw): Use count_one_bits_l.
* arch/arm.c (bitcount): Remove.
* arch/arm.h (bitcount): Remove.
call_site_find_chain returns a pointer that the caller must
deallocate. It seemed better here to return a unique_xmalloc_ptr
instead.
gdb/ChangeLog
2020-02-14 Tom Tromey <tromey@adacore.com>
* dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first):
Update.
* dwarf2/loc.h (call_site_find_chain): Return unique_xmalloc_ptr.
* dwarf2/loc.c (call_site_find_chain_1): Return
unique_xmalloc_ptr.
(call_site_find_chain): Likewise.
I see for some program at gdb startup:
...
Samples: 102K of event 'cycles:pu', Event count (approx.): 91710925103
Overhead Command Shared Object Symbol
15.21% gdb gdb [.]
lnp_state_machine::handle_special
...
where the divisions are the places we stall. The following
micro-optimizes things but it smells like m_line_header->line_range
is constant, likewise probably m_line_header->maximum_ops_per_instruction
so eventually the divisions could be avoided completely with some
lookup table.
Well. Micro-optimizing with this patch improves things
(don't expect [load] CSE over the gdbarch_adjust_dwarf2_line call).
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-02-14 Richard Biener <rguenther@suse.de>
* dwarf2/read.c (lnp_state_machine::handle_special_opcode): Apply CSE
on expression with division operators.
This removes some dead code from event-loop.c.
This patch is from my old series to merge the gdb and gdbserver event
loops; but since it is just removing dead code, it seemed simple to
commit it separately.
gdb/ChangeLog
2020-02-12 Tom Tromey <tom@tromey.com>
* event-loop.c (event_data, gdb_event, event_handler_func):
Remove.
Now that comp_unit and the remaining frame data are all independent of
the objfile, it can all be stored on the BFD and shared across
inferiors.
As with other code doing this same thing, care must be taken to not
share the data when the objfile requires relocations. So, two keys
are used: one for the BFD and one for the objfile, and
gdb_bfd_requires_relocations is used to differentiate between the two
cases.
gdb/ChangeLog
2020-02-12 Tom Tromey <tom@tromey.com>
* dwarf2/frame.c (dwarf2_frame_bfd_data): New global.
(dwarf2_frame_objfile_data): Add comment.
(find_comp_unit, set_comp_unit): New functions.
(dwarf2_frame_find_fde): Use find_comp_unit.
(dwarf2_build_frame_info): Use set_comp_unit.
This removes the objfile backlink from comp_unit. The only remaining
uses involved fetching the text offset from the objfile. However,
this is already conveniently computed at all the sites that call
execute_cfa_program, and so it can simply be passed in.
gdb/ChangeLog
2020-02-12 Tom Tromey <tom@tromey.com>
* dwarf2/frame.c (struct comp_unit) <objfile>: Remove.
(comp_unit): Don't initialize objfile.
(execute_cfa_program): Add text_offset parameter.
(execute_cfa_program_test, dwarf2_fetch_cfa_info)
(dwarf2_frame_cache): Update.
(dwarf2_build_frame_info): Don't set "objfile" member.
The DWARF frame comp_unit object still has a backlink to the objfile.
In order to be truly objfile-independent, this must be removed.
This patch removes one such use, by passing the gdbarch to
decode_frame_entry directly.
gdb/ChangeLog
2020-02-12 Tom Tromey <tom@tromey.com>
* dwarf2/frame.c (decode_frame_entry_1): Add gdbarch parameter.
(decode_frame_entry): Likewise.
(dwarf2_build_frame_info): Update.
This adds an auto_obstack to the DWARF frame comp_unit object, and
then changes the remaining code here to use the comp_unit obstack
rather than the objfile obstack.
At this point, all the storage for frame data is self-contained --
that is, it is independent of the objfile.
gdb/ChangeLog
2020-02-12 Tom Tromey <tom@tromey.com>
* dwarf2/frame.c (struct comp_unit) <obstack>: New member.
(decode_frame_entry_1): Use the comp_unit obstack.
This changes the DWARF frame code to store the comp_unit on the
objfile, rather than storing the FDE table. It also changes the
comp_unit to be heap-allocated using "new".
This change makes it simpler for a later patch to add a field to the
comp_unit, and to have deallaction work properly. This in turn is
important for making the frame data be independent of the objfile.
gdb/ChangeLog
2020-02-12 Tom Tromey <tom@tromey.com>
* dwarf2/frame.c (struct comp_unit): Add initializers and
constructor.
(dwarf2_frame_objfile_data): Store a comp_unit.
(dwarf2_frame_find_fde): Update.
(dwarf2_build_frame_info): Use "new".
This removes struct dwarf2_fde_table, replacing it with a typedef of
std::vector. This simplifies the code somewhat.
gdb/ChangeLog
2020-02-12 Tom Tromey <tom@tromey.com>
* dwarf2/frame.c (struct dwarf2_fde_table): Remove.
(dwarf2_fde_table): Typedef for std::vector.
(dwarf2_frame_objfile_data): Remove the deleter. Now static.
(dwarf2_frame_find_fde, add_fde, decode_frame_entry_1)
(decode_frame_entry): Update.
(dwarf2_build_frame_info): Use "new".
I am keeping the (int) casts because a future patch will change the type
to bool.
gdb/ChangeLog:
2020-02-12 Christian Biesinger <cbiesinger@google.com>
* arm-tdep.c (arm_dump_tdep): Print more fields of tdep.
The type dwarf_expr_baton is unused and can be removed.
gdb/ChangeLog
2020-02-12 Tom Tromey <tom@tromey.com>
* dwarf2/loc.c (struct dwarf_expr_baton): Remove.
Change-Id: Id8342da31398b9b4b08f31be7c3d612e9590bbbf
This updates a comment in psymtab.h to reflect the current reality.
gdb/ChangeLog
2020-02-11 Tom Tromey <tom@tromey.com>
* psymtab.h: Update comment.
Change-Id: I438bb5929c3ebd1a4c6e9a902490f2ef63014ab3
Add DISABLE_COPY_AND_ASSIGN to struct auto_obstack, to prevent copying
it. Copying an auto_obstack would be a bug.
2020-02-11 Tom Tromey <tom@tromey.com>
* gdb_obstack.h (struct auto_obstack): Use
DISABLE_COPY_AND_ASSIGN.
Change-Id: Ic9e5ab20acfcfa61c241fed4d99bbb1caefba3cd
dwarf2/frame.h forward-declares struct objfile, but there's no need
for this.
gdb/ChangeLog
2020-02-11 Tom Tromey <tom@tromey.com>
* dwarf2/frame.h (struct objfile): Don't forward declare.
Change-Id: I4d54d46ac9422eeb64dc5f0b934792e77a875aa5
The non-deprecated equivalent is implementing the gdbarch function
iterate_over_regset_sections, this patch does that.
Tested by generating a core file on cris under qemu and comparing
the output of "info registers".
This also fixes this warning when loading cris core files:
warning: Unexpected size of section `.reg/164' in core file.
gdb/ChangeLog:
2020-02-11 Christian Biesinger <cbiesinger@google.com>
* cris-tdep.c (cris_supply_gregset): Change signature to match
what struct regset expects.
(cris_regset): New struct.
(fetch_core_registers): Remove.
(cris_iterate_over_regset_sections): New function.
(_initialize_cris_tdep): Don't call deprecated_add_core_fns.
(cris_gdbarch_init): Call set_gdbarch_iterate_over_regset_sections.
Change-Id: Ieef895b5a2fdc797d1a913cd1c0c07563edfe8e7
These are for the obsolete FPA architecture.
gdb/ChangeLog:
2020-02-11 Christian Biesinger <cbiesinger@google.com>
* arch/arm.h (enum gdb_regnum): Add comment for the FP0..7
registers.
Change-Id: I6920616318ee637493d4ca12b91fa2ebcd103d76
In my previous commit, I did a last minute modification of warning.m4,
but forgot to re-generate the configure scripts, this commit fixes that.
gdb/ChangeLog:
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure: Re-generate.
Commit 85f0dd3ce ("[gdb] Fix -Wstrict-null-sentinel warnings") fixed
some violations of -Wstrict-null-sentinel. If we want to enforce this
warning, I think we should enable it in our warning.m4 file.
gdbsupport/ChangeLog:
* warning.m4: Add -Wstrict-null-sentinel.
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdb/ChangeLog:
* configure: Re-generate.
This file is used by gdbsupport, gdbserver and gdb, so I think it
belongs in gdbsupport. Move it there and update the references the
various acinclude.m4 files.
gdbsupport/ChangeLog:
* warning.m4: Move here, from gdb/warning.m4.
* acinclude.m4: Update warning.m4 path.
* Makefile.in: Re-generate.
gdbserver/ChangeLog:
* acinclude.m4: Update warning.m4 path.
gdb/ChangeLog:
* acinclude: Update warning.m4 path.
* warning.m4: Move to gdbsupport.
When passed in CXXFLAGS, -Wstrict-null-sentinel triggers twice in a
gdb/gdbserver build.
Fix the two occurrences.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-02-10 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (process_psymtab_comp_unit_reader): Cast concat NULL
sentinel to char *.
gdbsupport/ChangeLog:
2020-02-10 Tom de Vries <tdevries@suse.de>
* environ.c (gdb_environ::set): Cast concat NULL sentinel to char *.
Say we're debugging a test-case with CUs with name "<artificial>", meaning
not originating from a single file compilation, and use the verbose setting:
...
$ gdb -iex "set verbose on" -batch cc1
Reading symbols from cc1...
Reading in symbols for <artificial>... \
and /tmp/trunk/gcc/attribs.c... \
...
and /tmp/trunk/gcc/tree-ssa-reassoc.c... \
done.
...
From the "/tmp/trunk/gcc/attribs.c" message, it's clear which CU is loaded. But
that's not the case for the "<artificial>" message.
The message uses the filename field of struct partial_symtab, which is
documented like this:
...
/* Name of the source file which this partial_symtab defines,
or if the psymtab is anonymous then a descriptive name for
debugging purposes, or "". It must not be NULL. */
...
So, fix this by setting the filename field to a more descriptive name than
"<artificial>", by appending the CU offset.
This way, we print instead:
...
$ gdb -iex "set verbose on" -batch cc1
Reading symbols from cc1...
Reading in symbols for <artificial>@0x41146d9 \
and /tmp/trunk/gcc/attribs.c... \
... \
and /tmp/trunk/gcc/tree-ssa-reassoc.c... \
done.
...
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-02-09 Tom de Vries <tdevries@suse.de>
* dwarf2read.c (process_psymtab_comp_unit_reader): Append CU offset to
filename if it matches "<artificial>".
cutu_reader has a "keep" parameter, which is used to decide what to do
with a new CU when the reader is destroyed. Most code does not try to
preserve the CU, so this patch removes this parameter and instead adds
a new method that users can call to preserve the CU on the chain.
gdb/ChangeLog
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (class cutu_reader) <cutu_reader,
init_tu_and_read_dwo_dies>: Remove "keep" parameter.
<keep>: Declare method.
<m_keep>: Remove member.
<~cutu_reader>: Remove.
(cutu_reader::init_tu_and_read_dwo_dies): Update.
(cutu_reader::cutu_reader): Update.
(cutu_reader::keep): Rename from ~cutu_reader.
(process_psymtab_comp_unit, build_type_psymtabs_1)
(process_skeletonless_type_unit, load_partial_comp_unit)
(load_full_comp_unit, dwarf2_read_addr_index)
(read_signatured_type): Update.
Change-Id: I859b1c64313569d76d46317c14e9b077ebc3a27b
This changes the "want_partial_unit" parameters to have type bool, and
also removes the parameter from process_psymtab_comp_unit_reader.
This latter change seemed like an improvement, because it avoids a
pointless function call in the case where we are not planning to read
a partial unit.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (process_psymtab_comp_unit_reader): Remove
"want_partial_unit" parameter.
(process_psymtab_comp_unit): Change want_partial_unit to bool.
Inline check for DW_TAG_partial_unit.
(dwarf2_build_psymtabs_hard, scan_partial_symbols): Update.
Change-Id: I99e647f0c4faa3346e90a6e7bacc82af57eccff1
This moves read_n_bytes and read_direct_string to be with the the
low-level value-reading code.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (read_n_bytes, read_direct_string): Move to
read.c.
* dwarf2/leb.h (read_n_bytes, read_direct_string): Move from
read.c.
Change-Id: Id07bfa13d93c0ac1f47a385749a8f01f4755b818
This changes read_address to be a method on comp_unit_head.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (read_address): Move to comp-unit.c.
(dwarf2_rnglists_process, dwarf2_ranges_process)
(read_attribute_value, dwarf_decode_lines_1)
(var_decode_location, decode_locdesc): Update.
* dwarf2/comp-unit.c (comp_unit_head::read_address): Move from
read.c. Remove "cu" parameter.
* dwarf2/comp-unit.h (struct comp_unit_head) <read_address>: New
method.
Change-Id: Ibd6c7235f2e4d5fd88c272cfd2c3d3328618cc56
This changes one of the read_offset overloads to be a method on
comp_unit_head.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (read_attribute_value, read_indirect_string)
(read_indirect_line_string): Update.
* dwarf2/comp-unit.c (read_offset): Remove.
(read_comp_unit_head): Update.
* dwarf2/comp-unit.h (struct comp_unit_head) <read_offset>: New
method.
(read_offset): Don't declare.
Change-Id: Ia595702a5748337b7c031352bc437956baab9990
This creates the new files dwarf2/comp-unit.[ch], moving
comp_unit_head and helpers to those files. A couple of functions are
turned into methods, because it was convenient to do so now.
2020-02-08 Tom Tromey <tom@tromey.com>
* Makefile.in (COMMON_SFILES): Add dwarf2/comp-unit.c.
* dwarf2/read.c (struct comp_unit_head): Move to
dwarf2/comp-unit.h.
(enum class rcuh_kind): Move to comp-unit.h.
(get_cu_length, offset_in_cu_p): Now methods on comp_unit_head.
(read_comp_unit_head, error_check_comp_unit_head)
(read_and_check_comp_unit_head): Move to comp-unit.c.
(read_offset, dwarf_unit_type_name): Likewise.
(create_debug_type_hash_table, read_cutu_die_from_dwo)
(cutu_reader::cutu_reader, read_call_site_scope)
(find_partial_die, follow_die_offset): Update.
* dwarf2/comp-unit.h: New file, from dwarf2read.c.
Change-Id: Id961b9674c0081ed061083c8152c38b27b27388a
This moves read_offset_1 to leb.c, as it is a low-level data-reading
function. It is also renamed to remove the "_1", because gdb can use
overloading now, and this is clearer.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (read_offset_1): Move to leb.c.
(read_abbrev_offset, read_offset, dwarf_decode_line_header)
(dwarf_decode_macro_bytes): Update.
* dwarf2/leb.c (read_offset): Rename; move from read.c.
* dwarf2/leb.h (read_offset): Declare.
Change-Id: I048140598acfa76eade2cc529ab7933d4b9ca0b3
This changes dwarf2_section_size to be a method on
dwarf2_section_info.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf2_section_size): Remove.
(error_check_comp_unit_head, dwarf2_symbol_mark_computed):
Update.
* dwarf2/section.h (struct dwarf2_section_info) <get_size>: New method.
Change-Id: I12928fee5c84350ce98883e329357b86888d639b
There are two implementations of read_initial_length in gdb. This
merges them and moves the resulting function to leb.c.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (read_initial_length): Move to leb.c.
* dwarf2/leb.h (read_initial_length): Declare.
* dwarf2/leb.c (read_initial_length): Move from read.c. Add
handle_nonstd parameter.
* dwarf2/frame.c (read_initial_length): Remove.
(decode_frame_entry_1): Update.
Change-Id: I34d37bad0f8a584bfa781432cba25e05e1bd5750
This moves dwarf2_per_cu_data::imported_symtabs earlier, near where
the other data members are located.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct dwarf2_per_cu_data) <imported_symtabs>:
Move earlier.
Change-Id: I314ddaa6f67c53a848e513b3f6d42913bd957833
This moves the line_header class to a pair of new files, making
dwarf2/read.c somewhat smaller.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (dwarf_line_debug): Declare.
* Makefile.in (COMMON_SFILES): Add dwarf2/line-header.c.
* dwarf2/read.c: Move line_header code to new files.
(dwarf_line_debug): No longer static.
* dwarf2/line-header.c: New file.
* dwarf2/line-header.h: New file.
Change-Id: I8d9d8a2398b4e888e20cc5dd68d041c28b5a06e3
This changes the two new line_table methods to return
unique_xmalloc_ptr. This removes a bit of manual memory management.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (struct line_header) <file_full_name,
file_file_name>: Return unique_xmalloc_ptr.
(line_header::file_file_name): Update.
(line_header::file_full_name): Update.
(dw2_get_file_names_reader): Update.
(macro_start_file): Update.
Change-Id: I9442dba43882fb26097d0770a291eea2b03913a4
This changes file_full_name and file_file_name methods to be methods
on line_header. This seems more clear to me.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (struct line_header) <file_full_name,
file_file_name>: Declare methods.
(dw2_get_file_names_reader): Update.
(file_file_name): Now a method.
(file_full_name): Likewise.
(macro_start_file): Update.
Change-Id: I50d3e91665a9637c732e1e8d8e4263764c766d9c
dwarf_always_disassemble is only used in dwarf2/loc.c, so move the
definition and the command infrastructure to that file.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf_always_disassemble)
(show_dwarf_always_disassemble): Move to loc.c.
(_initialize_dwarf2_read): Move "always-disassemble" registration
to loc.c.
* dwarf2/read.h (dwarf_always_disassemble): Don't declare.
* dwarf2/loc.c (dwarf_always_disassemble): Move from read.c. Now
static.
(show_dwarf_always_disassemble): Move from read.c.
(_initialize_dwarf2loc): Move always-disassemble from read.c.
Change-Id: I33fb88112e98e583c3f4919d20e4d100f2ea0124
This changes dwarf2_per_objfile::quick_file_names_table to be an
htab_up. This just removes a bit of manual management.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (~dwarf2_per_objfile): Update.
(create_quick_file_names_table): Return htab_up.
(dw2_get_file_names_reader, dw2_forget_cached_source_info):
Update.
* dwarf2/read.h (struct dwarf2_per_objfile)
<quick_file_names_table>: Now htab_up.
Change-Id: I4ff2fce8b8af27f4bfe01a11b97a889edfd23151
abbrev_table::read increments cur_abbrev->num_attrs in the inner loop,
but there's no need to do this, as the information is already stored
in the temporary vector.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/abbrev.c (abbrev_table::read): Simplify.
Change-Id: I765f12850ffa1c6066e884bb22c94468d1abdba4
This changes abbrev_table to use an htab_up rather than an ad hoc,
bucket-based hash table.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/abbrev.c (abbrev_table): Move constructor from header.
Rewrite.
(abbrev_table::add_abbrev, abbrev_table::lookup_abbrev): Rewrite.
* dwarf2/abbrev.h (struct abbrev_info) <next>: Remove.
(abbrev_table::abbrev_table): No longer inline.
(ABBREV_HASH_SIZE): Remove.
(abbrev_table::m_abbrevs): Now an htab_up.
Change-Id: Icbaa8e49501f9c43218d6a81a7e8c4d3a77d65dc
This cleans up the DWARF abbrev_table API a bit, primarily by making
various methods and members private.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (read_cutu_die_from_dwo): Update.
(cutu_reader): Update.
(build_type_psymtabs_1): Update.
* dwarf2/abbrev.c (abbrev_table::read): Rename.
(abbrev_table::alloc_abbrev): Update.
* dwarf2/abbrev.h (abbrev_table_up): Move earlier.
(abbrev_table::read): New static method, renamed from
abbrev_table_read_table.
(abbrev_table::alloc_abbrev)
(abbrev_table::add_abbrev): Now private.
(abbrev_table::abbrev_table): Now private.
(abbrev_table::m_abbrev_obstack): Now private. Rename.
Change-Id: I320dca83b799f672909ae66f73b7aca266adbaf9
This changes dwarf2_per_objfile::die_type_hash to be an htab_up,
moving its contents off the objfile obstack.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (set_die_type, get_die_type_at_offset): Update.
* dwarf2/read.h (struct dwarf2_per_objfile) <die_type_hash>: Now
htab_up.
Change-Id: Ic651f99ebf71bf7ad2dc2880192adacf7b60964a
This changes dwp_file to use htab_up for the loaded_cus and loaded_tus
members. This lets us avoid allocating the contents of these hash
tables on the objfile obstack.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (struct dwp_file) <loaded_cus, loaded_tus>: Now
htab_up.
(lookup_dwo_unit_in_dwp): Update.
(allocate_dwp_loaded_cutus_table): Return htab_up. Don't allocate
on obstack.
Change-Id: Id61209bf5c6c6faa0c067195af31fbcf26813a3a
This changes allocate_dwo_file_hash_table so that it does not use the
objfile obstack to store the contents of the hash table.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (allocate_dwo_file_hash_table): Don't allocate on
obstack.
Change-Id: Ic20a618acc7277e56aa18580c68f75c793bef97b
This changes dwarf2_per_objfile::line_header_hash to be an htab_up,
and changes it to use heap allocation.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (~dwarf2_per_objfile): Don't delete
line_header_hash.
(handle_DW_AT_stmt_list): Update. Don't allocate on obstack.
* dwarf2/read.h (struct dwarf2_per_objfile) <line_header_hash>:
Change type to htab_up.
Change-Id: Icb148a270838c0f96f38fc4a28b5b77d067927b6
This changes dwarf2_per_objfile::type_unit_groups to be an htab_up,
again allowing us to move the memory used by the hash table from the
objfile obstack to the heap.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (allocate_type_unit_groups_table): Return
htab_up. Don't allocate on obstack.
(get_type_unit_group, dwarf2_build_psymtabs_hard): Update.
* dwarf2/read.h (struct dwarf2_per_objfile) <type_unit_groups>:
Change type to htab_up.
Change-Id: Ia045df0ff3ec30aac813da5a9a2314a607ef7ec8
This changes dwarf2_per_objfile::signatured_types to be an htab_up.
This in turn lets us change it not to use the objfile obstack for
allocation; obstack allocation for hash tables is a bad practice
because it leads to excess memory use if the table is ever resized.
gdb/ChangeLog
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct dwarf2_per_objfile) <signatured_types>:
Change type to htab_up.
* dwarf2/read.c (create_signatured_type_table_from_index)
(create_signatured_type_table_from_debug_names)
(create_all_type_units, add_type_unit)
(lookup_dwo_signatured_type, lookup_signatured_type)
(process_skeletonless_type_unit): Update.
(create_debug_type_hash_table, create_debug_types_hash_table):
Change type of types_htab.
(allocate_signatured_type_table, allocate_dwo_unit_table): Return
htab_up. Don't allocate on obstack.
(create_cus_hash_table): Change type of cus_htab parameter.
(struct dwo_file) <cus, tus>: Now htab_up.
(lookup_dwo_signatured_type, lookup_dwo_cutu)
(process_dwo_file_for_skeletonless_type_units, lookup_dwo_cutu)
(queue_and_load_all_dwo_tus): Update.
* dwarf2/index-write.c (write_gdbindex): Update.
(write_debug_names): Update.
Change-Id: I290a209b96945fb5f415c82723b62830e9c4b467
This removes some queue-related globals from the DWARF reader, in
favor of a new member on dwarf2_per_objfile. Globals must be avoided
in this code, because they prevent multi-threading the reader.
gdb/ChangeLog
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct dwarf2_queue_item): Move from
dwarf2/read.c. Remove "next" member. Add constructor ntad
destructor.
(struct dwarf2_per_objfile) <queue>: New member.
* dwarf2/read.c (struct dwarf2_queue_item): Move to
dwarf2/read.h.
(dwarf2_queue, dwarf2_queue_tail): Remove.
(class dwarf2_queue_guard): Add parameter to constructor. Use
DISABLE_COPY_AND_ASSIGN.
<m_per_objfile>: New member.
<~dwarf2_queue_guard>: Rewrite.
(dw2_do_instantiate_symtab, queue_comp_unit, process_queue):
Update.
(~dwarf2_queue_item): New.
Change-Id: Ied1f6ff3691352a66c4709b0b2cba0588f49f79a
Many functions take a "has_children" parameter (either as an in- or
out-parameter). However, it seems to me that it makes more sense to
have "has_children" be an attribute of a DIE. Making this change
allows this parameter to be eliminated in many places.
gdb/ChangeLog
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (struct die_info) <has_children>: New member.
(dw2_get_file_names_reader): Remove has_children.
(dw2_get_file_names): Update.
(read_cutu_die_from_dwo): Remove has_children.
(cutu_reader::init_tu_and_read_dwo_dies)
(cutu_reader::cutu_reader): Update.
(process_psymtab_comp_unit_reader, build_type_psymtabs_reader):
Remove has_children.
(build_type_psymtabs_1, process_skeletonless_type_unit)
(load_partial_comp_unit, load_full_comp_unit): Update.
(create_dwo_cu_reader): Remove has_children.
(create_cus_hash_table, read_die_and_children): Update.
(read_full_die_1,read_full_die): Remove has_children.
(read_signatured_type): Update.
(class cutu_reader) <has_children>: Remove.
Change-Id: I0d3d51ae9379554a66032648d51124bba07f87b4
die_reader_specs::comp_dir is assigned but never read; this patch
removes it.
gdb/ChangeLog
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2read.c (struct die_reader_specs) <comp_dir>: Remove.
(init_cu_die_reader, read_cutu_die_from_dwo): Update.
Change-Id: I9818a2593197a6972cddec23cd2f3dd0ce28f580
There's no need to forward-declare struct die_info in dwarf2read.h.
gdb/ChangeLog
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2read.h (struct die_info): Don't declare.
Change-Id: I0b8dbf99558b9547d418cfd8ef387a21f7dfa660
die_info_ptr is not used and so can be removed.
gdb/ChangeLog
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2read.h (die_info_ptr): Remove typedef.
Change-Id: Ibd0a5ad55876dc96a35b658adc36348f01e48884
This changes attr_form_is_block to be a method. This is done
separately because, unlike the other attribute functions,
attr_form_is_block had special handling for the case where the
argument was NULL. This required auditing each call site; in most
cases, NULL was already ruled out, but in a few spots, an additional
check was needed.
gdb/ChangeLog
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2read.c (read_call_site_scope)
(handle_data_member_location, dwarf2_add_member_fn)
(mark_common_block_symbol_computed, read_common_block)
(attr_to_dynamic_prop, partial_die_info::read)
(var_decode_location, dwarf2_fetch_die_loc_sect_off)
(dwarf2_symbol_mark_computed, set_die_type): Update.
* dwarf2/attribute.h (struct attribute) <form_is_block>: Declare
method.
(attr_form_is_block): Don't declare.
* dwarf2/attribute.c (attribute::form_is_block): Now a method.
Change-Id: Idfb290c61d738301ab991666f43e0b9cf577b2ae
This moves the attribute-related code out of dwarf2read.c and into the
new files dwarf2/attribute.[ch].
gdb/ChangeLog
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2read.c (struct attribute, DW_STRING)
(DW_STRING_IS_CANONICAL, DW_UNSND, DW_BLOCK, DW_SND, DW_ADDR)
(DW_SIGNATURE, struct dwarf_block, attr_value_as_address)
(attr_form_is_block, attr_form_is_section_offset)
(attr_form_is_constant, attr_form_is_ref): Move.
* dwarf2/attribute.h: New file.
* dwarf2/attribute.c: New file, from dwarf2read.c.
* Makefile.in (COMMON_SFILES): Add dwarf2/attribute.c.
Change-Id: I1ea4c146256a1b9e38b66f1c605d782a14eeded7
This moves the abbrev table code out of dwarf2read.c and into new
files dwarf2/abbrev.[ch].
gdb/ChangeLog
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2read.c (abbrev_table_up, struct abbrev_info)
(struct attr_abbrev, ABBREV_HASH_SIZE, struct abbrev_table):
Move.
(read_cutu_die_from_dwo, build_type_psymtabs_1): Update.
(abbrev_table::alloc_abbrev, abbrev_table::add_abbrev)
(abbrev_table::lookup_abbrev, abbrev_table_read_table): Move to
abbrev.c.
* dwarf2/abbrev.h: New file.
* dwarf2/abbrev.c: New file, from dwarf2read.c.
* Makefile.in (COMMON_SFILES): Add dwarf2/abbrev.c.
Change-Id: I87911bc5297de4407587ca849fef8e8d19136c30
This moves some section-handling code from dwarf2read.c into new
files, dwarf2/section.[ch].
gdb/ChangeLog
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2read.h (struct dwarf2_section_info, dwarf2_read_section):
Move to dwarf2/section.h.
* dwarf2read.c (get_containing_section, get_section_bfd_owner)
(get_section_bfd_section, get_section_name)
(get_section_file_name, get_section_id, get_section_flags)
(dwarf2_section_empty_p, dwarf2_read_section): Moe to
dwarf2/section.c.
* dwarf2/section.h: New file.
* dwarf2/section.c: New file, from dwarf2read.c.
* Makefile.in (COMMON_SFILES): Add dwarf2/section.c.
Change-Id: I9f8498094cf99d9521e9481622ce8adbd453daf4
This moves some scalar-unpacking code into a couple of new files,
dwarf2/leb.h and dwarf2/leb.c.
gdb/ChangeLog
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2read.h (read_unsigned_leb128): Don't declare.
* dwarf2read.c (read_1_byte, read_1_signed_byte, read_2_bytes)
(read_2_signed_bytes, read_3_bytes, read_4_bytes)
(read_4_signed_bytes, read_8_bytes): Move to dwarf2/leb.h.
(read_unsigned_leb128, read_signed_leb128): Move to dwarf2/leb.c.
* dwarf2/leb.h: New file, from dwarf2read.c.
* dwarf2/leb.c: New file, from dwarf2read.c.
* dwarf2-frame.c (read_1_byte, read_4_bytes, read_8_bytes):
Remove.
* Makefile.in (CONFIG_SRC_SUBDIR): Add dwarf2.
(COMMON_SFILES): Add dwarf2/leb.c.
Change-Id: Idd19647686c8f959d226a95fdfca4db47c6e96d0
This patch redefines fputs_unfiltered in utils.c, with new behavior to
forward parameters to fputs_maybe_filtered. This makes
fputs_unfiltered identical to fputs_filtered, except filtering is
disabled.
Some callers of fputs_unfiltered have been updated to use ui_file_puts
where they were using other ui_file_* functions anyway for IO.
This fixes the problem I saw with \032\032post-prompt annotation being
flushed to stdout in the wrong order.
2020-02-05 Iain Buclaw <ibuclaw@gdcproject.org>
PR gdb/25190:
* gdb/remote-sim.c (gdb_os_write_stderr): Update.
* gdb/remote.c (remote_console_output): Update.
* gdb/ui-file.c (fputs_unfiltered): Rename to...
(ui_file_puts): ...this.
* gdb/ui-file.h (ui_file_puts): Add declaration.
* gdb/utils.c (emit_style_escape): Update.
(flush_wrap_buffer): Update.
(fputs_maybe_filtered): Update.
(fputs_unfiltered): Add function.
Change-Id: I17ed5078f71208344f2f8ab634a6518b1af6e213
Commit a0c1ffedc regressed certain cases coming from Eclipse.
See PR breakpoints/24915.
gdb/ChangeLog
2020-02-07 Tom Tromey <tromey@adacore.com>
PR breakpoints/24915:
* source.c (find_and_open_source): Do not check basenames_may_differ.
gdb/testsuite/ChangeLog
2020-02-07 Tom Tromey <tromey@adacore.com>
PR breakpoints/24915:
* gdb.base/annotate-symlink.exp: Use setup_xfail.
Change-Id: Iadbf42f35eb40c95ad32b2108ae25d8f199998bd
This patch moves gdbserver to the top level.
This patch is as close to a pure move as possible -- gdbserver still
builds its own variant of gnulib and gdbsupport. Changing this will
be done in a separate patch.
[v2] Note that, per Simon's review comment, this patch changes the
tree so that gdbserver is not built for or1k or score. This makes
sense, because there is apparently not actually a gdbserver port here.
[v3] This version of the patch also splits out some configury into a
new file, gdbserver/configure.host, so that the top-level configure
script can simply rely on it in order to decide whether gdbserver
should be built.
[v4] This version adds documentation and removes some unnecessary
top-level dependencies.
[v5] Update docs to mention "make all-gdbserver" and change how
top-level configure decides whether to build gdbserver, switching to a
single, shared script.
Tested by the buildbot.
ChangeLog
2020-02-07 Tom Tromey <tom@tromey.com>
Pedro Alves <palves@redhat.com>
* src-release.sh (GDB_SUPPORT_DIRS): Add gdbserver.
* gdbserver: New directory, moved from gdb/gdbserver.
* configure.ac (host_tools): Add gdbserver.
Only build gdbserver on certain systems.
* Makefile.in, configure: Rebuild.
* Makefile.def (host_modules, dependencies): Add gdbserver.
* MAINTAINERS: Add gdbserver.
gdb/ChangeLog
2020-02-07 Tom Tromey <tom@tromey.com>
* README: Update gdbserver documentation.
* gdbserver: Move to top level.
* configure.tgt (build_gdbserver): Remove.
* configure.ac: Remove --enable-gdbserver.
* configure: Rebuild.
* Makefile.in (distclean): Don't mention gdbserver.
Change-Id: I826b7565b54604711dc7a11edea0499cd51ff39e
The source_cache::ensure method may throw an exception through
the invocation of source_cache::get_plain_source_lines. This
happens when the source file is not found. The expected behaviour
of "ensure" is only returning "true" or "false" according to the
documentation in the header file.
So far, if gdb is in source layout and a file is missing, you see
some outputs like below:
,---------------------------------------------.
| test.c file is loaded in the source window. |
| |
| int main() |
| ... |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| /path/to/crt0.S: No such file or directory. |
| (gdb) p/x $pc |
| $1 = 0x124 |
| (gdb) n |
| /path/to/crt0.S: No such file or directory. |
| (gdb) p/x $pc |
| $2 = 0x128 |
| (gdb) [pressing arrow-down key] |
| (gdb) terminate called after throwing an |
| instance of 'gdb_exception_error' |
`---------------------------------------------'
Other issues have been encountered as well [1].
The patch from Pedro [2] which is about preventing exceptions
from crossing the "readline" mitigates the situation by not
causing gdb crash, but still there are lots of errors printed:
,---------------------------------------------.
| test.c file is loaded in the source window. |
| |
| int main() |
| ... |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-down key] |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-down key] |
| /path/to/crt0.S: No such file or directory. |
| (gdb) [pressing arrow-up key] |
| /path/to/crt0.S: No such file or directory. |
`---------------------------------------------'
With the changes of this patch, the behavior is like:
,---------------------------------------------.
| initially, source window is empty because |
| crt0.S is not found and according to the |
| program counter that is the piece of code |
| being executed. |
| |
| later, when we break at main (see commands |
| below), this window will be filled with the |
| the contents of test.c file. |
|---------------------------------------------|
| Remote debugging using :1234 |
| __start () at /path/to/crt0.S:141 |
| (gdb) p/x $pc |
| $1 = 0x124 |
| (gdb) n |
| (gdb) p/x $pc |
| $2 = 0x128 |
| (gdb) b main |
| Breakpoint 1 at 0x334: file test.c, line 8. |
| (gdb) cont |
| Continuing. |
| Breakpoint 1, main () at hello.c:8 |
| (gdb) n |
| (gdb) |
`---------------------------------------------'
There is no crash and the error message is completely
gone. Maybe it is good practice that the error is
shown inside the source window.
I tested this change against gdb.base/list-missing-source.exp
and there was no regression.
[1]
It has also been observed in the past that the register
values are not transferred from qemu's gdb stub, see:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/226
[2]
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=2f267673f0fdee9287e6d404ecd4f2d29da0d2f2
gdb/ChangeLog:
* source-cache.c (source_cache::ensure): Surround
get_plain_source_lines with a try/catch.
(source_cache::get_line_charpos): Get rid of try/catch
and only check for the return value of "ensure".
* tui/tui-source.c (tui_source_window::set_contents):
Simplify "nlines" calculation.
gdb/testsuite/ChangeLog:
* gdb.tui/tui-missing-src.exp: Add the "missing source
file" test for the TUI.
This was a typo introduced in f6ac5f3d63.
Found by looking through NetBSD's GDB patches:
https://github.com/NetBSD/pkgsrc-wip/blob/master/gdb-netbsd/patches/patch-gdb_sparc-nat.h
This patch can't be tested on Linux because Linux does not use the
sparc_target template.
gdb/ChangeLog:
2020-02-05 Christian Biesinger <cbiesinger@google.com>
* sparc-nat.h (struct sparc_target) <xfer_partial>: Fix base class
function call.
Change-Id: I4fa88cbdc365efe89b84cc0619b60db38718d9ce
Makes the comment match the macro name in the #define/#ifdef.
gdb/ChangeLog:
2020-02-05 Christian Biesinger <cbiesinger@google.com>
* ppc-nbsd-tdep.h: Fix macro name in #endif comment.
Change-Id: If7b2e49e65495b8eb9ed7b6c9a11277579a93a05
In preparation for RISC-V/Linux `gdbserver' support factor out parts of
native target description determination code that can be shared between
the programs.
gdb/
* nat/riscv-linux-tdesc.h: New file.
* nat/riscv-linux-tdesc.c: New file, taking code from...
* riscv-linux-nat.c (riscv_linux_nat_target::read_description):
... here.
* configure.nat <linux> <riscv*>: Add nat/riscv-linux-tdesc.o to
NATDEPFILES.
We assign the simulator inferior a fake ptid. If this ptid is ever
set to null_ptid then we are going to run into problems - the
simulator ptid is what we return from gdbsim_target::wait, and this in
turn is used to look up the inferior data with a call to
find_inferior_pid, which asserts the pid is not 0 (which it is in
null_pid).
This commit adds an assert that the simulator's fake pid is not
null_ptid. There should be no user visible changes after this commit.
gdb/ChangeLog:
* remote-sim.c (sim_inferior_data::sim_inferior_data): Assert that
we don't set the fake simulator ptid to the null_ptid.
Change-Id: I6e08effe70e70855aea13c9caf4fd6913d5af56d
In the function f77_print_array_1, the variable 'i' which holds the
index is of datatype 'int', while bounds are of datatype LONGEST. Due to
size of int being smaller than LONGEST, the variable 'i' stores
incorrect values for high indexes (higher than max limit of int). Due
to this issue in sources, two abnormal behaviors are seen while printing
arrays with high indexes (please check array-bounds-high.f90) For high
indexes with negative sign, gdb prints empty array even if the array has
elements.
(gdb) p arr
$1 = ()
For high indexes with positive sign, gdb crashes. We have now changed
the datatype of 'i' to LONGEST which is same as datatype of bounds.
gdb/ChangeLog:
* f-valprint.c (f77_print_array_1): Changed datatype of index
variable to LONGEST from int to enable it to contain bound
values correctly.
gdb/testsuite/ChangeLog:
* gdb.fortran/array-bounds-high.exp: New file.
* gdb.fortran/array-bounds-high.f90: New file.
Change-Id: Ie2dce9380a249e634e2684b9c90f225e104369b7
Fix RISC-V native Linux support to handle a 64-bit FPU (FLEN == 64) with
both RV32 and RV64 systems, which is a part of the current Linux ABI for
hard-float systems, rather than assuming that (FLEN == XLEN) in target
description determination and that (FLEN == 64) in register access.
We can do better however and not rely on any particular value of FLEN
and probe for it dynamically, by observing that the PTRACE_GETREGSET
ptrace(2) call will only accept an exact regset size, and that will
reflect FLEN. Therefore iterate over the call in target description
determination with a geometrically increasing regset size until a match
is marked by a successful ptrace(2) call completion or we run beyond the
maximum size we can support.
Update register accessors accordingly, using FLEN determined to size the
buffer used for NT_PRSTATUS requests and then to exchange data with the
regcache.
Also handle a glibc bug where ELF_NFPREG is defined in terms of NFPREG,
however NFPREG is nowhere defined.
gdb/
* riscv-linux-nat.c [!NFPREG] (NFPREG): New macro.
(supply_fpregset_regnum, fill_fpregset): Handle regset buffer
offsets according to FLEN determined.
(riscv_linux_nat_target::read_description): Determine FLEN
dynamically.
(riscv_linux_nat_target::fetch_registers): Size regset buffer
according to FLEN determined.
(riscv_linux_nat_target::store_registers): Likewise.
When the command "info registers" (same as "info registers general"),
is issued, _all_ the registers from a tdesc XML are printed. This
includes the registers with empty register groups (set as "") which
are supposed to be only printed by "info registers all" (or "info
all-registers").
This bug got introduced after all the overhauls that the
tdesc_register_in_reggroup_p() went through. You can see that the
logic of tdesc_register_in_reggroup_p() did NOT remain the same after
all those changes:
git difftool c9c895b9666..HEAD -- gdb/target-descriptions.c
With the current implementation, when the reg->group is an empty
string, this function returns -1, while in the working revision
(c9c895b966), it returned 0. This patch makes sure that the 0 is
returned again.
The old implementation of tdesc_register_in_reggroup_p() returned
-1 when "reggroup" was set to "all_reggroups" at line 4 below:
1 tdesc_register_reggroup_p (...)
2 {
3 ...
4 ret = tdesc_register_in_reggroup_p (gdbarch, regno, reggroup);
5 if (ret != -1)
6 return ret;
7
8 return default_register_reggroup_p (gdbarch, regno, reggroup);
9 }
As a result, the execution continued at line 8 and the
default_register_reggroup_p(..., reggroup=all_reggroups) would
return 1. However, with the current implementation of
tdesc_register_in_reggroup_p() that allows checking against any
arbitrary group name, it returns 0 when comparing the "reg->group"
against the string "all" which is the group name for "all_reggroups".
I have added a special check to cover this case and
"info all-registers" works as expected.
gdb/ChangeLog:
* target-descriptions.c (tdesc_register_in_reggroup_p): Return 0
when reg->group is empty and reggroup is not.
Change-Id: I9eaf9d7fb36410ed5684ae652fe4756b1b2e61a3
ravenscar-thread.c needed a change to adapt to multi-target:
ravenscar_thread_target::mourn_inferior called the mourn_inferior
method on the target beneat -- but when the target beneath was the
remote target, this resulted in the ravenscar target being deleted.
Switching the order of the calls to unpush_target and the beneath's
mourn_inferior fixes this problem.
gdb/ChangeLog
2020-01-31 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c (ravenscar_thread_target::mourn_inferior):
Call beneath target's mourn_inferior after unpushing.
Change-Id: Ia80380515c403adc40505a6b3420c9cb35754370
In TUI mode, if the disassembly output for the program is less than
one screen long, then currently if the user scrolls down until on the
last assembly instruction is displayed and then tries to scroll up
using Page-Up, the display doesn't update - they are stuck viewing the
last line.
If the user tries to scroll up using the Up-Arrow, then the display
scrolls normally.
What is happening is on the Page-Up we ask GDB to scroll backward the
same number of lines as the height of the TUI ASM window. The back
scanner, which looks for a good place to start disassembling, fails to
find a starting address which will provide the requested number of new
lines before we get back to the original starting address (which is
not surprising, our whole program contains less than a screen height
of instructions), as a result the back scanner gives up and returns
the original starting address.
When we scroll with Up-Arrow we only ask the back scanner to find 1
new instruction, which it manages to do, so this scroll works.
The solution here is, when we fail to find enough instructions, to
return the lowest address we did manage to find. This will ensure we
jump to the lowest possible address in the disassembly output.
gdb/ChangeLog:
PR tui/9765
* tui/tui-disasm.c (tui_find_disassembly_address): If we don't
have enough lines to fill the screen, still return the lowest
address we found.
gdb/testsuite/ChangeLog:
PR tui/9765
* gdb.tui/tui-layout-asm-short-prog.S: New file.
* gdb.tui/tui-layout-asm-short-prog.exp: New file.
Change-Id: I6a6a7972c68a0559e9717fd8d82870b669a40af3
GDB has some commands ('+', '-', '<', and '>') for scrolling the SRC
and ASM TUI windows from the CMD window, however the help text for
these commands lists the arguments in the wrong order.
This commit updates the help text to match how GDB actually works, and
also extends the text to describe what the arguments mean, and what
the defaults are.
There should be no change in GDBs functionality after this commit.
gdb/ChangeLog:
* tui/tui-win.c (_initialize_tui_win): Update help text for '+',
'-', '<', and '>' commands.
Change-Id: Ib2624891de1f4ba983838822206304e4c3ed982e
Kamil Rytarowski
Luis Machado
Andrew Burgess
Tom de Vries
Tom Tromey
Anton Kolesov
Tom Tromey
Simon Marchi
Christian Biesinger
Kevin Buettner
Simon Marchi
Hannes Domani
John Baldwin
Tankut Baris Aktemur
Sergio Durigan Junior
Jon Turney
Aaron Merey
Jérémie Galarneau
Joel Brobecker
Ali Tamur via gdb-patches
Nelson Chu
Doug Evans
Maciej W. Rozycki
Bernd Edlinger
Richard Biener
Alok Kumar Sharma
Iain Buclaw
Shahab Vahedi