| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When running test-case gdb.threads/omp-par-scope.exp, I get this XPASS:
...
XPASS: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: \
outer stop: get valueof "num"
...
for test:
...
set thread_num [get_valueof "" "num" "unknown"]
...
The intention of the test is to get the value of local variable num, which
has been set to:
...
int num = omp_get_thread_num ();
...
but the actually printed value is 'num':
...
(gdb) print num^M
$76 = num^M
...
This is due to the fact that num is missing in the locals, so instead we find
the enum member 'num' of enum expression_operator in glibc/intl/plural-exp.h.
Fix this by getting the value using a new proc get_local_valueof, which uses
the "info locals" commands to get the value.
Tested on x86_64-linux, with gcc 7.5.0 (where the test xfails) and gcc
10.0.1 (where the test passes).
|
|
I stumbled on this snippet in nat/gdb_ptrace.h:
/* Some systems, in particular DEC OSF/1, Digital Unix, Compaq Tru64
or whatever it's called these days, don't provide a prototype for
ptrace. Provide one to silence compiler warnings. */
#ifndef HAVE_DECL_PTRACE
extern PTRACE_TYPE_RET ptrace();
#endif
I believe this is unnecessary today and should be removed. First, the
comment only mentions OSes we don't support (and to be honest, I had
never even heard of).
But most importantly, in C++, a declaration with empty parenthesis
declares a function that accepts no arguments, unlike in C. So if this
declaration was really used, GDB wouldn't build, since all ptrace call
sites pass some arguments. Since we haven't heard anything about this
causing some build failures since we have transitioned to C++, I
conclude that it's not used.
This patch removes it as well as the corresponding configure check.
gdb/ChangeLog:
* ptrace.m4: Don't check for ptrace declaration.
* config.in: Re-generate.
* configure: Re-generate.
* nat/gdb_ptrace.h: Don't declare ptrace if HAVE_DECL_PTRACE is
not defined.
gdbserver/ChangeLog:
* config.in: Re-generate.
* configure: Re-generate.
gdbsupport/ChangeLog:
* config.in: Re-generate.
* configure: Re-generate.
|
|
Linux returns long from ptrace(2) and BSDs int.
gdb/ChangeLog:
* amd64-bsd-nat.c (gdb_ptrace): Change return type from `int' to
`PTRACE_TYPE_RET'.
* i386-bsd-nat.c (gdb_ptrace): Likewise.
* sparc-nat.c (gdb_ptrace): Likewise.
* x86-bsd-nat.c (gdb_ptrace): Likewise.
|
|
The "restrict" patch added some asserts to c-exp.y, but one spot was
copy-pasted and referred to the wrong table. This was pointed out by
-fsanitize=address. This patch fixes the bug.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* c-exp.y (lex_one_token): Fix assert.
|
|
I configured with -fsanitize=address and built gdb. linux-tdep.c and
ada-tasks.c failed to build due to some stringop-truncation errors,
e.g.:
In function ‘char* strncpy(char*, const char*, size_t)’,
inlined from ‘int linux_fill_prpsinfo(elf_internal_linux_prpsinfo*)’ at ../../binutils-gdb/gdb/linux-tdep.c:1742:11,
inlined from ‘char* linux_make_corefile_notes(gdbarch*, bfd*, int*)’ at ../../binutils-gdb/gdb/linux-tdep.c:1878:27:
/usr/include/bits/string_fortified.h:106:34: error: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ specified bound 81 equals destination size [-Werror=stringop-truncation]
This patch fixes the problem by using "sizeof - 1" in the call to
strndup, as recommended in the GCC manual. This doesn't make a
difference here because the next line, in all cases, sets the final
element to '\0' anyway.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* ada-tasks.c (read_atcb): Use smaller length in strncpy call.
* linux-tdep.c (linux_fill_prpsinfo): Use smaller length in
strncpy call.
|
|
Andrew Burgess pointed out on irc that "maint info line-table" doesn't
properly align the table headers. This patch fixes the problem by
switching the table to use ui-out.
This required a small tweak to one test case, as ui-out will pad a
field using spaces, even at the end of a line.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* symmisc.c (maintenance_print_one_line_table): Use ui_out.
gdb/testsuite/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* gdb.dwarf2/dw2-ranges-base.exp: Update regular expressions.
|
|
The removal of val_print caused a regression in the Ada code. In one
scenario, a variant type would not be properly printed, because the
address of a component was lost. This patch fixes the bug by changing
this API to be value-based. This is cleaner and fixes the bug as a
side effect.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* ada-valprint.c (print_variant_part): Remove parameters; switch
to value-based API.
(print_field_values): Likewise.
(ada_val_print_struct_union): Likewise.
(ada_value_print_1): Update.
gdb/testsuite/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* gdb.ada/sub_variant/subv.adb: New file.
* gdb.ada/sub_variant.exp: New file.
|
|
gdb/ChangeLog:
* ppc-nbsd-nat.c (ppc_nbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* ppc-nbsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
|
|
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* hppa-nbsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* (store_registers): Likewise.
|
|
When running test-cases gdb.threads/step-over-lands-on-breakpoint.exp and
gdb.threads/step-over-trips-on-watchpoint.exp with target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects, we run into timeouts
due not being able to set a breakpoint and then trying to continue to that
breakpoint.
In total, we run into 186 timeouts, which roughly corresponds to half an hour:
...
$ grep "FAIL.*(timeout)" gdb.sum \
| awk '{print $2}' \
| sort \
| uniq -c
66 gdb.threads/step-over-lands-on-breakpoint.exp:
120 gdb.threads/step-over-trips-on-watchpoint.exp:
...
Fix this by bailing out if the first break fails.
Tested on x86_64-linux, both with native and with target board mentioned above.
gdb/testsuite/ChangeLog:
2020-03-20 Tom de Vries <tdevries@suse.de>
* gdb.threads/step-over-lands-on-breakpoint.exp (do_test): Bail out if
first break fails.
* gdb.threads/step-over-trips-on-watchpoint.exp: (do_test): Same.
|
|
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 24ed6739b699f329c2c45aedee5f8c7d2f54e493
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.
|
|
This commit adds a test that builds a mixed language stack, the stack
contains frames of Fortran, C, and C++. The test prints the backtrace
and explores the stack printing arguments of different types in frames
of different languages.
The core of the test is repeated with GDB's language set to auto,
fortran, c, and c++ in turn to ensure that GDB is happy to print
frames and frame arguments when the language is set to a value that
doesn't match the frame language.
This test currently passes, and there are no known bugs in this area.
The aim of this commit is simply to increase test coverage, as I don't
believe this functionality is currently tested.
gdb/testsuite/ChangeLog:
* gdb.fortran/mixed-lang-stack.c: New file.
* gdb.fortran/mixed-lang-stack.cpp: New file.
* gdb.fortran/mixed-lang-stack.exp: New file.
* gdb.fortran/mixed-lang-stack.f90: New file.
|
|
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
|
|
When running test-case gdb.opt/inline-locals.exp, I get:
...
Running src/gdb/testsuite/gdb.opt/inline-locals.exp ...
KPASS: gdb.opt/inline-locals.exp: info locals above bar 2 (PRMS gdb/xyz)
KPASS: gdb.opt/inline-locals.exp: info locals above bar 3 (PRMS gdb/xyz)
...
I've opened PR25695 - 'abstract and concrete variable listed both with "info
locals"' to refer to in the PRMS field, and this patch adds that reference.
Furthermore, I noticed that while I see KPASSes, given the problem description
the tests should actually be KFAILs. This patch also fixes that.
Tested on x86_64-linux. With gcc 7.5.0, I get 2 KFAILs. With clang 5.0.2,
the tests pass.
gdb/testsuite/ChangeLog:
2020-03-19 Tom de Vries <tdevries@suse.de>
* gdb.opt/inline-locals.exp: Add kfail PR number. Make kfail matching
more precise.
|
|
Add a test-case that tests whether we can set a breakpoint on an inlined
inline function in CU for which the partial symtab has not yet been expanded.
Tested on x86_64-linux, with gcc 4.8.5, gcc-7.5.0, gcc-10.0.1, and clang
5.0.2.
gdb/testsuite/ChangeLog:
2020-03-18 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/break-inline-psymtab-2.c: New test.
* gdb.dwarf2/break-inline-psymtab.c: New test.
* gdb.dwarf2/break-inline-psymtab.exp: New file.
|
|
Fix build issues on NetBSD where the reg symbol exists in public headers.
regformats/regdef.h:22:8: error: redefinition struct
struct reg
^~~
/usr/include/amd64/reg.h:51:8: note: previous definition struct
struct reg {
^~~
gdb/ChangeLog:
* regformats/regdef.h: Put reg in gdb namespace.
gdbserver/ChangeLog:
* regcache.cc (find_register_by_number): Update.
* tdesc.cc (init_target_desc): Likewise.
* tdesc.h (target_desc::reg_defs): Likewise.
|
|
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.
|
|
This avoids clashes with macro read in the NetBSD headers.
gdb/ChangeLog:
* user-regs.c (user_reg::read): Rename to...
(user_reg::xread): ...this.
* (append_user_reg): Rename argument `read' to `xread'.
* (user_reg_add_builtin): Likewise.
* (user_reg_add): Likewise.
* (value_of_user_reg): Likewise.
|
|
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.
|
|
CXX amd64-bsd-nat.o
amd64-bsd-nat.c:42:1: error: no previous declaration void amd64bsd_fetch_inferior_registers(regcache*, [-Werror=missing-declarations]
amd64bsd_fetch_inferior_registers (struct regcache *regcache, int regnum)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
amd64-bsd-nat.c:118:1: error: no previous declaration void amd64bsd_store_inferior_registers(regcache*, [-Werror=missing-declarations]
amd64bsd_store_inferior_registers (struct regcache *regcache, int regnum)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Detected on NetBSD/amd64 9.99.49.
gdb/ChangeLog:
* amd64-bsd-nat.c: Include amd64-bsd-nat.h".
|
|
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.
|
|
When running test-case gdb.linespec/cpcompletion.exp with target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects, we run into lots of
timeouts, in particular with this pattern:
...
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
cmd complete "b template2_"
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
tab complete "b template2_st" (timeout)
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
cmd complete "b template2_st"
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
tab complete "b template2_str" (timeout)
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
cmd complete "b template2_str"
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
tab complete "b template2_stru" (timeout)
...
Fix this by detecting timeouts in test_complete_prefix_range_re and giving up
after 3 consecutive timeouts.
This reduces testing time from ~39m to ~9m.
Tested on x86_64-linux.
|
|
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.
|
|
Test-case gdb.base/gdb-caching-proc.exp tests whether procs declared using
gdb_caching_proc give the same results when called more than once.
While this tests consistency of the procs in the context of that test-case, it
doesn't test consistency across the call sites.
Add a local variable cache_verify to proc gdb_do_cache, that can be set to 1
to verify gdb_caching_proc consistency across the call sites.
Likewise, add a local variable cache_verify_proc to set to the name of the
gdb_caching_proc to verify. This can f.i. be used when changing an existing
proc into a gdb_caching_proc.
Tested on x86_64-linux, with cache_verify set to both 0 and 1.
gdb/testsuite/ChangeLog:
2020-03-16 Tom de Vries <tdevries@suse.de>
* lib/cache.exp (gdb_do_cache): Add and handle local variables
cache_verify and cache_verify_proc.
|
|
Since commit a2fedca99c "Implement 'set/show exec-file-mismatch'.", I see the
following regression on openSUSE Leap 15.1:
...
FAIL: gdb.server/solib-list.exp: non-stop 0: target remote \
(got interactive prompt)
FAIL: gdb.server/solib-list.exp: non-stop 1: target remote \
(got interactive prompt)
...
The first FAIL in more detail:
...
(gdb) PASS: gdb.server/solib-list.exp: non-stop 0: file binfile
target remote localhost:2346
Remote debugging using localhost:2346
warning: Mismatch between current exec-file /data/gdb_versions/devel/build/\
gdb/testsuite/outputs/gdb.server/solib-list/solib-list
and automatically determined exec-file /lib64/ld-2.26.so
exec-file-mismatch handling is currently "ask"
Load new symbol table from "/lib64/ld-2.26.so"? (y or n) n
warning: loading /lib64/ld-2.26.so Not confirmed.
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
warning: File transfers from remote targets can be slow. \
Use "set sysroot" to access files locally instead.
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...
Reading /lib64/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target...
Reading /lib64/.debug/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote \
target...
Reading /data/gdb_versions/devel/install/lib64/debug//lib64/\
ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target...
Reading /data/gdb_versions/devel/install/lib64/debug/lib64/\
/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target...
Reading target:/data/gdb_versions/devel/install/lib64/debug/lib64/\
/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target...
(No debugging symbols found in target:/lib64/ld-linux-x86-64.so.2)
0x00007ffff7dd7ea0 in ?? ()
(gdb) FAIL: gdb.server/solib-list.exp: non-stop 0: target remote (got \
interactive prompt)
...
The commit introduces the "Load new symbol table from" question, and
gdb_test_multiple defaults to answering "no" and reporting the
"got interactive prompt" FAIL.
This FAIL is not seen on f.i. debian 10.2. The difference originates from the
fact that the solib-list executable has debug-info in the openSUSE case, while
it doesn't in the debian case.
We can prevent the failure on openSUSE by stripping the executable from
debug-info:
...
+ exec strip --strip-debug ${binfile}
...
The difference in behaviour is a bug or improvement opportunity in the
exec-file-mismatch, filed as PR25475.
This patch fixes the FAIL by handling the question in the test-case.
Tested on x86_64-linux.
Tested on x86_64-linux with the gdbserver part of the patch introducing the
test-case reverted to ensure that this still FAILs.
gdb/testsuite/ChangeLog:
2020-03-15 Tom de Vries <tdevries@suse.de>
* gdb.server/solib-list.exp: Handle
'Load new symbol table from "/lib64/ld-2.26.so"? (y or n)'.
|
|
When running test-case gdb.base/maint.exp with check-read1, I run into:
...
FAIL: gdb.base/maint.exp: (timeout) maint print objfiles
...
The FAIL happens because command output contains long lines like this:
...
file1 at $hex, file2 at $hex, ..., $file$n at $hex,
...
F.i., such a line for libc.so.debug contains 82000 chars.
Fix this this by reading long lines bit by bit.
Also, replace the testing of the command output formulated using a gdb_send
combined with gdb_expect-in-a-loop, with a regular gdb_test_multiple with
exp_continue.
Tested on x86_64-linux, with make targets check and check-read1.
gdb/testsuite/ChangeLog:
2020-03-15 Tom de Vries <tdevries@suse.de>
* gdb.base/maint.exp: Use exp_continue in long lines for "maint print
objfiles".
|
|
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.
|
|
When running test-case gdb.mi/mi-fortran-modules.exp with check-read1, I run
into:
...
FAIL: gdb.mi/mi-fortran-modules.exp: -symbol-info-module-functions (timeout)
FAIL: gdb.mi/mi-fortran-modules.exp: -symbol-info-module-functions \
--name _all (unexpected output)
FAIL: gdb.mi/mi-fortran-modules.exp: -symbol-info-module-functions \
--module mod[123] (unexpected output)
FAIL: gdb.mi/mi-fortran-modules.exp: -symbol-info-module-variables \
(unexpected output)
...
Fix this by using exp_continue.
Tested on x86_64, using make target check and check-read1.
gdb/testsuite/ChangeLog:
2020-03-14 Tom de Vries <tdevries@suse.de>
* gdb.mi/mi-fortran-modules.exp: Use exp_continue.
|
|
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.
|
|
* m68k-bsd-nat.c (m68kbsd_supply_gregset): Change type of regs to
gdb_byte *.
* m68k-bsd-nat.c (m68kbsd_supply_fpregset): Likewise.
* m68k-bsd-nat.c (m68kbsd_collect_gregset): Likewise.
* m68k-bsd-nat.c (m68kbsd_supply_pcb): Cast &tmp to gdb_byte *.
|
|
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.
|
