Leszek Swirski [Thu, 26 Oct 2017 23:19:33 +0000 (19:19 -0400)]
Fix dwarf2_string_attr for -gsplit-dwarf
The dwarf2_string_attr did not allow DW_FORM_GNU_str_index as a form for
string types. This manifested as null strings in the namespace_name
lookup (replaced with "(anonymous namespace)") when debugging
Fission-compiled code.
* features/Makefile (i386-avx-mpx-avx512-pku.dat): Add backslash
at the end of the line.
* regformats/i386/amd64-avx-mpx-avx512-pku-linux.dat: Regenerate.
* regformats/i386/amd64-avx-mpx-avx512-pku.dat: Regenerate.
Simon Marchi [Tue, 5 Sep 2017 15:40:44 +0000 (17:40 +0200)]
Test different follow-exec-mode settings in gdb.multi/multi-arch-exec.exp
Using follow-exec-mode "new" takes a different code path than "same", so
it's interesting to test this path in combination with a change in
architecture of the inferior. This test fails if you remove the
previous patch.
gdb/testsuite/ChangeLog:
* gdb.multi/multi-arch-exec.exp: Test with different
"follow-exec-mode" settings.
(do_test): New procedure.
Simon Marchi [Tue, 5 Sep 2017 15:30:27 +0000 (17:30 +0200)]
Add thread after updating gdbarch when exec'ing
As mentioned in the previous patch, we should avoid doing register reads
after a process does an exec and before we've updated that inferior's
gdbarch. Otherwise, we may interpret the registers using the wrong
architecture. When a process does an exec with "follow-exec-mode new",
a new inferior is added by follow_exec. The gdbarch of that new
inferior is at first set to some default value, probably specific to the
gdb build (I get "i386" here), which may not be the right one. It is
updated later by the call to target_find_description. Before that
point, if we try to read the inferior's registers, we may not interpret
them correctly. This has been exposed by a failure in
gdb.base/foll-exec-mode.exp after the previous patch, with:
Remote 'g' packet reply is too long (expected 312 bytes, got 816 bytes)
The call to "add_thread" done just after adding the inferior is
problematic, because it ends up reading the registers (because the ptid
is re-used, we end up doing a switch_to_thread to it, which tries to
update stop_pc). The registers returned by gdbserver are the x86-64
ones, while we try to interpret them using the "i386" gdbarch.
Postponing the call to add_thread to until the target
description/gdbarch has been updated seems to fix the issue.
As to why this issue was uncovered by the previous patch: what I think
happened before that patch is that since we were updating stop_pc before
switching to the new inferior, we were filling the regcache associated
to the ptid (this worked fine as long as the architectures of the
previous and new process images were the same). The call to
switch_to_thread then worked, because the register read hit the
regcache. Now, it triggers a register read, while the gdbarch is not
set correctly, leading to the "reply is too long" error. If this is
right, it sounds wrong that we delete and re-add a thread with the same
ptid, and are able to access the registers from the deleted thread.
When we delete a thread, should we clear the regcache associated to that
ptid, so that the new thread starts with a fresh/empty regcache?
gdb/ChangeLog:
* infrun.c (follow_exec): Call add_thread after
target_find_description.
Simon Marchi [Tue, 5 Sep 2017 14:45:10 +0000 (16:45 +0200)]
Read stop_pc after updating the gdbarch when exec'ing
When an inferior execs and changes architecture (e.g. 64 bits to 32
bits), the gdbarch associated to the inferior is updated by the
follow_exec call in handle_inferior_event_1. We should avoid doing any
register read before that point, because the registers sent by the
remote side will be those of the new architecture, but we would
interpret them using the old architecture. We do just that by setting
stop_pc during this window, which obviously requires reading the
registers. This results in gdb.multi/multi-arch-exec.exp failing, GDB
outputting the following error:
Truncated register 50 in remote 'g' packet
This patch fixes that by postponing the setting of stop_pc to after
we've updated the inferior gdbarch.
This bug was hiding another problem, and as such introduces some
failures in gdb.base/foll-exec-mode.exp. The following patch takes care
of that.
gdb/ChangeLog:
* infrun.c (handle_inferior_event_1): When exec'ing, read
stop_pc after follow_exec.
Simon Marchi [Tue, 5 Sep 2017 14:43:07 +0000 (16:43 +0200)]
Improve "'g' reply is is to long" error message
... by adding the expected size, and the received size. I found this
useful when debugging gdbarch/remote issues, since it gives a hint of
what gdb expects and what the remote sent.
John Baldwin [Tue, 5 Sep 2017 02:53:50 +0000 (19:53 -0700)]
Define an error function in the PPC simulator library.
Previously this used the error function from GDB directly when linked
against GDB instead of the error method in the host callbacks
structure. This was exposed via a link error when GDB was converted
to C++. The error function invokes the error callback similar to
sim_io_error.
Note that there are also error functions in sim/ppc/main.c and
sim/ppc/misc.c. The ppc libsim.a expects each consumer to provide
several symbols used by the library including "error". sim-calls.c
provides these symbols when the library is linked into gdb. The dgen,
igen, tmp-filter, tmp-ld-decode, tmp-ld-cache, and tmp-ld-insn programs
use the functions from misc.c. psim uses the functions from main.c.
Jan Kratochvil [Fri, 1 Sep 2017 04:13:40 +0000 (06:13 +0200)]
PR gdb/22046: Fix T-stopped detach regression on old Linux kernels
On <=RHEL6 hosts Fedora/RHEL GDB started to 'kill -STOP' all processes it
detached. Even those not originally T-stopped. This is a Fedora-specific
patch which is based on upstream GDB's PROC_STATE_STOPPED state.
I believe (I did not verify) this patch did regress it:
commit d617208bb06bd461b52ce041d89f7127e3044762
Author: Pedro Alves <palves@redhat.com>
Date: Mon Jul 25 12:42:17 2016 +0100
linux-procfs: Introduce enum proc_state
As originally there was strstr() but now there is strcmp() and so the missing
trailing '\n' no longer matches.
made command name lookup case sensitive. However, define_command, used
when creating a user-defined command, converts the command name to
lowercase, assuming that the command name lookup works in a case
insensitive way. This causes user-defined commands with capital letters
in their name to only be callable with a lowercase version:
(gdb) define Foo
Type commands for definition of "Foo".
End with a line saying just "end".
>print 1
>end
(gdb) Foo
Undefined command: "Foo". Try "help".
(gdb) foo
$1 = 1
This patch removes that conversion to lowercase, so that the user can
call the command with the same name they provided.
gdb/ChangeLog:
* cli/cli-script.c (define_command): Don't convert command name
to lower case.
gdb/testsuite/ChangeLog:
* gdb.base/commands.exp (user_defined_command_case_sensitivity):
New proc, call it from toplevel.
Fix a commit cd6c3b4ffc4e ("New gdbarch methods breakpoint_kind_from_pc
and sw_breakpoint_from_kind") regression and restore the use of
`->placed_address' rather than `->reqstd_address' as the location for a
memory breakpoint to be inserted at. Previously
`gdbarch_breakpoint_from_pc' was used that made that adjustment in
`default_memory_insert_breakpoint' from the preinitialized value,
however with the said commit that call is gone, so the passed
`->placed_address' has to be used for the initialization.
The regression manifests itself as the inability to debug any MIPS/Linux
compressed ISA dynamic executable as GDB corrupts the dynamic loader
with one of its implicit breakpoints, causing the program to crash, as
seen for example with the `mips-linux-gnu' target, o32 ABI, MIPS16 code,
and the gdb.base/advance.exp test case:
(gdb) continue
Continuing.
Program received signal SIGBUS, Bus error.
_dl_debug_initialize (ldbase=0, ns=0) at dl-debug.c:51
51 r = &_r_debug;
(gdb) FAIL: gdb.base/advance.exp: Can't run to main
gdb/
PR breakpoints/21886
* mem-break.c (default_memory_insert_breakpoint): Use
`->placed_address' rather than `->reqstd_address' for the
breakpoint location.
projects / thirdparty / binutils-gdb.git / log
