gdb/ChangeLog:
* MAINTAINERS (Write After Approval): Add "Carl Love".
gdb/testsuite/ChangeLog:
* gdb.arch/powerpc-power.s: Add new Power9 instruction tests
and sync up the test with tests in gas/testsuite/gas/ppc.
* gdb.arch/powerpc-power.exp: Likewise.
The GDB testsuite reports 5 test failures on Power 7 instructions.
Additionally the ppc test is missing the new Power 9 instructions as
well as a large number of older instructions. Additionally, some
instruction names have changed or been deleted. This patch
fixes the test failures and completely updates the test to make it
consistent with the supported Power 9 instructions listed in:
gas/testsuite/gas/ppc/power7.d
gas/testsuite/gas/ppc/power8.d
gas/testsuite/gas/ppc/power9.d
gas/testsuite/gas/ppc/altivec.d
gas/testsuite/gas/ppc/altivec2.d
gas/testsuite/gas/ppc/altivec3.d
gas/testsuite/gas/ppc/vsx.d
gas/testsuite/gas/ppc/vsx2.d
gas/testsuite/gas/ppc/vsx3.d
-----------------------------------------------------
gdb/testsuite/ChangeLog
2016-08-18 Carl Love <cel@us.ibm.com>
* gdb.arch/powerpc-power.s: Add new Power9 instruction tests
and sync up the test with tests in gas/testsuite/gas/ppc.
* gdb.arch/powerpc-power.exp: Likewise.
The patch fixes the record support of Hardware Transactional Memory
instructions on Power. It also solves a large number of unexpected failures
from gdb.reverse testcases sigall-precsave.exp and sigall-reverse.exp that
occur on distros which glibc uses HTM instructions.
gdb/ChangeLog
2016-08-18 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
* rs6000-tdep.c (ppc_process_record_op31): Handle HTM instructions.
This error message should not contain the word symbol:
(gdb) remove-inferiors 1
Warning: Can not remove current symbol inferior 1.
gdb/ChangeLog:
* inferior.c (remove_inferior_command): Fix error message.
gdb/testsuite/ChangeLog:
* gdb.multi/remove-inferiors.exp (test_remove_inferiors): Fix
expected error message.
I noticed that the remove-inferiors command was not tested, and as I am
doing some changes related to the user selection, I want to make sure I
don't break it. For example, I want to make sure it's not possible to
remove the current inferior.
gdb/testsuite/ChangeLog:
* gdb.multi/remove-inferiors.exp: New file.
* gdb.multi/remove-inferiors.c: New file.
GLIBC BZ#20311 introduced a change to install proc_service.h so that gdb
didn't have to use the version it embeds in gdb_proc_service.h. The
embedded version is guarded by HAVE_PROC_SERVICE_H and
gdb_proc_service.h has a number other of includes and definitions, all
of which are uncondional except for an include for gregset.h. This is
only included if HAVE_PROC_SERIVCE_H is not defined.
This causes a build failure when cross compiling gdb with the latest
glibc because type definitions in gregset are used independently of
HAVE_PROC_SERIVCE_H. In particular, they are used in gdb_proc_service.h
when PRFPREGSET_T_BROKEN is set.
The error messages on the failure are
----
binutils-gdb/gdb/gdb_proc_service.h:173:9: error: ‘gdb_fpregset_t’ does
not name a type; did you mean ‘elf_fpregset_t’?
typedef gdb_fpregset_t gdb_prfpregset_t;
^~~~~~~~~~~~~~
elf_fpregset_t
binutils-gdb/gdb/gdb_proc_service.h:173:9: error: ‘gdb_fpregset_t’ does
not name a type; did you mean ‘elf_fpregset_t’?
typedef gdb_fpregset_t gdb_prfpregset_t;
^~~~~~~~~~~~~~
elf_fpregset_t
binutils-gdb/gdb/proc-service.c:218:15: error: ‘gdb_prfpregset_t’ does
not name a type; did you mean ‘gdb_fpregset_t’?
const gdb_prfpregset_t *fpregset)
^~~~~~~~~~~~~~~~
gdb_fpregset_t
----
This patch moves the include for gregset.h to before the code guarded by
HAVE_PROC_SERIVCE_H, so that it is always included. This is enough to
fix the build.
2016-08-15 Matthew Wahab <matthew.wahab@arm.com>
PR gdb/20457
* gdb_proc_service.h: Add an include of gregset.h
[!HAVE_PROC_SERVICE_H]: Remove the include of gregset.h.
I build GDB with -fsanitize=address, and see the error in tests,
(gdb) PASS: gdb.linespec/ls-errs.exp: lang=C++: break 3 foo
break -line 3 foo^M
=================================================================^M
==4401==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000047487 at pc 0x819d8e bp 0x7fff4e4e6bb0 sp 0x7fff4e4e6ba8^M
READ of size 1 at 0x603000047487 thread T0^[[1m^[[0m^M
#0 0x819d8d in explicit_location_lex_one /home/yao/SourceCode/gnu/gdb/git/gdb/location.c:502^M
#1 0x81a185 in string_to_explicit_location(char const**, language_defn const*, int) /home/yao/SourceCode/gnu/gdb/git/gdb/location.c:556^M
#2 0x81ac10 in string_to_event_location(char**, language_defn const*) /home/yao/SourceCode/gnu/gdb/git/gdb/location.c:687^
the code in question is:
> /* Special case: C++ operator,. */
> if (language->la_language == language_cplus
> && strncmp (*inp, "operator", 8) <--- [1]
> && (*inp)[9] == ',')
> (*inp) += 9;
> ++(*inp);
The error is caused by the access to (*inp)[9] if 9 is out of its bounds.
However [1] looks odd to me, because if strncmp returns true (non-zero),
the following check "(*inp)[9] == ','" makes no sense any more. I
suspect it was a typo in the code we meant to "strncmp () == 0". Another
problem in the code above is that if *inp is "operator,", we first
increment *inp by 9, and then increment it by one again, which is wrong
to me. We should only increment *inp by 8 to skip "operator", and go
back to the loop header to decide where we stop.
gdb:
2016-08-15 Yao Qi <yao.qi@linaro.org>
* location.c (explicit_location_lex_one): Compare the return
value of strncmp with zero. Don't check (*inp)[9]. Increment
*inp by 8.
I see the following warning when running signals-state-child.exp.
gdb/testsuite/gdb.base/signals-state-child.c:77:4: warning: too many arguments for format [-Wformat-extra-args]
fprintf (out, "sigaction={sa_handler=", i);
^
this patch is to remove the argument from fprintf.
gdb/testsuite:
2016-08-12 Yao Qi <yao.qi@linaro.org>
* gdb.base/signals-state-child.c (main): Remove "i" from fprintf's
argument list.
Fixes, on NIOS GNU/Linux:
In file included from
/scratch/mbilal/nois-lite/src/gdb-trunk/gdb/gdbserver/../nat/linux-ptrace.c:26:0:
/scratch/mbilal/nois-lite/src/gdb-trunk/gdb/gdbserver/../gregset.h:27:23:
error: unknown type name 'gregset_t'
#define GDB_GREGSET_T gregset_t
^
Fix this by including sys/procfs.h directly. We shouldn't really be
including a gdb-only header in a gdb/nat/ file, anyway. Whoops.
gdb/ChangeLog:
2016-08-11 Pedro Alves <palves@redhat.com>
PR gdb/20413
* nat/linux-ptrace.c: Include <sys/procfs.h> instead of
"gregset.h".
Right after a fork is detected, we detach breakpoints from the child
(detach_breakpoints), which calls into target_remove_breakpoint with
inferior_ptid pointing at the child process, but leaves the breakpoint
marked inserted (in the parent).
The problem is that record-full.c always deletes all knowledge of the
breakpoint. Then when we later really delete the breakpoint from the
parent, we fail the assertion, since the breakpoint is unexpectedly
not found in the record-full.c breakpoint table.
The fix is simply to not forget about the breakpoint if we're
detaching it from a fork child.
gdb/ChangeLog:
2016-08-10 Pedro Alves <palves@redhat.com>
PR gdb/19187
* record-full.c (record_full_remove_breakpoint): Don't remove the
breakpoint from the record_full_breakpoints VEC if we're detaching
the breakpoint from a fork child.
gdb/testsuite/ChangeLog:
2016-08-10 Pedro Alves <palves@redhat.com>
PR gdb/19187
* gdb.reverse/waitpid-reverse.exp: Add comment and remove
setup_kfails.
Makes the code more obvious.
gdb/ChangeLog:
2016-08-10 Pedro Alves <palves@redhat.com>
PR gdb/19187
* breakpoint.c (insertion_state_t): Delete.
(enum remove_bp_reason): New.
(detach_breakpoints, remove_breakpoint_1, remove_breakpoint):
Adjust to use enum remove_bp_reason instead of insertion_state_t.
All callers pass mark_uninserted, so there's no need for the 'is'
parameter.
gdb/ChangeLog:
2016-08-10 Pedro Alves <palves@redhat.com>
PR gdb/19187
* breakpoint.c (remove_breakpoint): Remove 'is' parameter and
always pass mark_uninserted to remove_breakpoint_1.
(insert_breakpoint_locations, remove_breakpoints)
(remove_breakpoints_pid, update_global_location_list): Update
callers.
This is done by catching an exception number 0x406d1388 (it has no
documented name, though MSDN dubs it "MS_VC_EXCEPTION" in one code
example), which is thrown by the program. The exception record
contains an ID of a thread and a name to give it.
This requires rolling back some changes in handle_exception(), which
now again returns more than two distinct values. The new
HANDLE_EXCEPTION_IGNORED value means that gdb should just continue,
without returning the thread ID up the stack (which would result in
further handling of the exception, which is not what we want).
gdb/ChangeLog:
2016-08-10 Руслан Ижбулатов <lrn1986@gmail.com>
Pedro Alves <palves@redhat.com>
* windows-nat.c (MS_VC_EXCEPTION): New define.
(handle_exception_result): New enum.
(windows_delete_thread): Free the thread's name.
(handle_exception): Handle MS_VC_EXCEPTION.
(get_windows_debug_event): Handle HANDLE_EXCEPTION_IGNORED.
(windows_thread_name): New function.
(windows_target): Install it as to_thread_name method.
* NEWS: Mention the thread naming support on MS-Windows.
The ARI complains about this new file:
common/signals-state-save-restore.c:46: warning: gettext: All messages should be marked up with _.
common/signals-state-save-restore.c:59: warning: gettext: All messages should be marked up with _.
common/signals-state-save-restore.c:87: warning: gettext: All messages should be marked up with _.
common/signals-state-save-restore.c:92: warning: gettext: All messages should be marked up with _.
Since these are untranslatable strings, use () instead of _().
gdb/ChangeLog:
2016-08-10 Pedro Alves <palves@redhat.com>
* common/signals-state-save-restore.c
(save_original_signals_state, restore_original_signals_state):
Wrap perror_with_name arguments with '()'.
When executing commands on a secondary UI running the MI interpreter,
some commands that should be synchronous are not. MI incorrectly
continues processing input right after the synchronous command is
sent, before the target stops.
The problem happens when we emit MI async events (=library-loaded,
etc.), and we go about restoring the previous terminal state, we end
up calling target_terminal_ours, which incorrectly always installs the
current UI's input_fd in the event loop... That is, code like this:
old_chain = make_cleanup_restore_target_terminal ();
target_terminal_ours_for_output ();
fprintf_unfiltered (mi->event_channel, "library-loaded");
...
do_cleanups (old_chain);
The fix is to move the add_file_handler/delete_file_handler calls out
of target_terminal_$foo, making these completely no-ops unless called
with the main UI as current UI.
gdb/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR gdb/20418
* event-top.c (ui_register_input_event_handler)
(ui_unregister_input_event_handler): New functions.
(async_enable_stdin): Register input in the event loop.
(async_disable_stdin): Unregister input from the event loop.
(gdb_setup_readline): Register input in the event loop.
* infrun.c (check_curr_ui_sync_execution_done): Register input in
the event loop.
* target.c (target_terminal_inferior): Don't unregister input from
the event loop.
(target_terminal_ours): Don't register input in the event loop.
* target.h (target_terminal_inferior)
(target_terminal_ours_for_output, target_terminal_ours): Update
comments.
* top.h (ui_register_input_event_handler)
(ui_unregister_input_event_handler): New declarations.
* utils.c (ui_unregister_input_event_handler_cleanup)
(prepare_to_handle_input): New functions.
(defaulted_query, prompt_for_continue): Use
prepare_to_handle_input.
gdb/testsuite/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@ericsson.com>
PR gdb/20418
* gdb.mi/new-ui-mi-sync.c, gdb.mi/new-ui-mi-sync.exp: New files.
* lib/mi-support.exp (mi_expect_interrupt): Remove anchors.
gdb 7.11 introduced an MI regression: a failing MI sync execution
command misses printing the MI prompt, and then all subsequent command
miss it too:
$ gdb-7.11.1 -i=mi
[...]
p 1
&"p 1\n"
~"$1 = 1"
~"\n"
^done
(gdb) <<< prompted ok
-exec-continue
^error,msg="The program is not being run." <<< missing prompt after this
print 1
&"print 1\n"
~"$2 = 1"
~"\n"
^done <<< missing prompt after this
gdb 7.10.1 behaved correctly, even with "set mi-async on":
-exec-continue
^error,msg="The program is not being run."
(gdb) <<< prompted ok
etc.
Bisecting points at:
commit 0b333c5e7d
Author: Pedro Alves <palves@redhat.com>
Date: Wed Sep 9 18:23:23 2015 +0100
Merge async and sync code paths some more
[...]
The problem is that when an exception is thrown, we leave the prompt
state set to PROMPT_BLOCKED, and then mi_execute_command_input_handler
doesn't print the prompt. It used to work because before that patch,
we happened to skip disabling stdin if the current target didn't do
async (which it never does before execution).
I was surprised to find that this bug isn't caught by the testsuite,
so I made a thorough test that tests all combinations of pairs of:
- a failing synchronous execution command
- a failing non-execution command
- a non-failing command
gdb/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR mi/20431
* mi/mi-main.c (mi_execute_command): Enable input and set prompt
state to PROMPT_NEEDED.
gdb/testsuite/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR mi/20431
* gdb.mi/mi-cmd-error.exp: New file.
gdb's (or gdbserver's) own signal handling should not interfere with
the signal dispositions their spawned children inherit. However, it
currently does. For example, some paths in gdb cause SIGPIPE to be
set to SIG_IGN, and as consequence, the child starts with SIGPIPE to
set to SIG_IGN too, even though gdb was started with SIGPIPE set to
SIG_DFL.
This is because the exec family of functions does not reset the signal
disposition of signals that are set to SIG_IGN:
http://pubs.opengroup.org/onlinepubs/7908799/xsh/execve.html
Signals set to the default action (SIG_DFL) in the calling process
image are set to the default action in the new process
image. Signals set to be ignored (SIG_IGN) by the calling process
image are set to be ignored by the new process image. Signals set to
be caught by the calling process image are set to the default action
in the new process image (see <signal.h>).
And neither does it reset signal masks or flags.
In order to be transparent, when spawning new child processes to debug
(with "run", etc.), reset signal actions and mask back to what was
originally inherited from gdb/gdbserver's parent, just before execing
the target program to debug.
gdb/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR gdb/18653
* Makefile.in (SFILES): Add
common/signals-state-save-restore.c.
(HFILES_NO_SRCDIR): Add common/signals-state-save-restore.h.
(COMMON_OBS): Add signals-state-save-restore.o.
(signals-state-save-restore.o): New rule.
* configure: Regenerate.
* fork-child.c: Include "signals-state-save-restore.h".
(fork_inferior): Call restore_original_signals_state.
* main.c: Include "signals-state-save-restore.h".
(captured_main): Call save_original_signals_state.
* common/common.m4: Add sigaction to AC_CHECK_FUNCS checks.
* common/signals-state-save-restore.c: New file.
* common/signals-state-save-restore.h: New file.
gdb/gdbserver/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR gdb/18653
* Makefile.in (OBS): Add signals-state-save-restore.o.
(signals-state-save-restore.o): New rule.
* config.in: Regenerate.
* configure: Regenerate.
* linux-low.c: Include "signals-state-save-restore.h".
(linux_create_inferior): Call
restore_original_signals_state.
* server.c: Include "dispositions-save-restore.h".
(captured_main): Call save_original_signals_state.
gdb/testsuite/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR gdb/18653
* gdb.base/signals-state-child.c: New file.
* gdb.base/signals-state-child.exp: New file.
* gdb.gdb/selftest.exp (do_steps_and_nexts): Add new pattern.
With something like:
struct A { int bitfield:4; } var;
If 'var' ends up wholly-optimized out, printing 'var.bitfield' crashes
gdb here:
(top-gdb) bt
#0 0x000000000058b89f in extract_unsigned_integer (addr=0x2 <error: Cannot access memory at address 0x2>, len=2, byte_order=BFD_ENDIAN_LITTLE)
at /home/pedro/gdb/mygit/src/gdb/findvar.c:109
#1 0x00000000005a187a in unpack_bits_as_long (field_type=0x16cff70, valaddr=0x0, bitpos=16, bitsize=12) at /home/pedro/gdb/mygit/src/gdb/value.c:3347
#2 0x00000000005a1b9d in unpack_value_bitfield (dest_val=0x1b5d9d0, bitpos=16, bitsize=12, valaddr=0x0, embedded_offset=0, val=0x1b5d8d0)
at /home/pedro/gdb/mygit/src/gdb/value.c:3441
#3 0x00000000005a2a5f in value_fetch_lazy (val=0x1b5d9d0) at /home/pedro/gdb/mygit/src/gdb/value.c:3958
#4 0x00000000005a10a7 in value_primitive_field (arg1=0x1b5d8d0, offset=0, fieldno=0, arg_type=0x16d04c0) at /home/pedro/gdb/mygit/src/gdb/value.c:3161
#5 0x00000000005b01e5 in do_search_struct_field (name=0x1727c60 "bitfield", arg1=0x1b5d8d0, offset=0, type=0x16d04c0, looking_for_baseclass=0, result_ptr=0x7fffffffcaf8,
[...]
unpack_value_bitfield is already optimized-out/unavailable -aware:
(...) VALADDR points to the contents of VAL. If the VAL's contents
required to extract the bitfield from are unavailable/optimized
out, DEST_VAL is correspondingly marked unavailable/optimized out.
however, it is not considering the case of the value having no
contents buffer at all, as can happen through
allocate_optimized_out_value.
gdb/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
* value.c (unpack_value_bitfield): Skip unpacking if the parent
has no contents buffer to begin with.
gdb/testsuite/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
* gdb.dwarf2/bitfield-parent-optimized-out.exp: New file.
I regenerated all target description .c files from scratch, and got
this spurious diff.
It's a simple mid-air collision - these files were clearly generated
before commit 73b4f516a0 ("maint_print_c_tdesc_cmd: Use type for
TYPE_CODE_FLAGS instead of field_type."), which did the global
s/field_type/type/, and pushed to master afterwards.
gdb/features/ChangeLog:
2016-08-08 Pedro Alves <palves@redhat.com>
* features/i386/amd64-avx-mpx-linux.c: Regenerate.
* features/i386/amd64-avx-mpx.c: Regenerate.
* features/i386/i386-avx-mpx-linux.c: Regenerate.
* features/i386/i386-avx-mpx.c: Regenerate.
We build by default with a C++ compiler, but "configure --help" still
says "--enable-build-with-cxx", which hints that it is by default
disabled. Update the --help text.
gdb/ChangeLog:
2016-08-05 Pedro Alves <palves@redhat.com>
* build-with-cxx.m4: Change help string to be in terms of
--disable-build-with-cxx.
* configure: Regenerate.
gdb/gdbserver/ChangeLog:
2016-08-05 Pedro Alves <palves@redhat.com>
* configure: Regenerate.
I find the following test fail when I test native aarch64 gdb with
arm program,
(gdb) PASS: gdb.base/attach-pie-noexec.exp: attach
set architecture arm^M
warning: Selected architecture arm is not compatible with reported target architecture aarch64^M
Architecture `arm' not recognized.^M
The target architecture is set automatically (currently aarch64)^M
(gdb) FAIL: gdb.base/attach-pie-noexec.exp: set architecture arm
GDB thinks the target is aarch64, but it isn't. Nowadays, we are
using some entries AT_PHENT and AT_HWCAP in auxv to determine whether
the process is a 32-bit arm one or 64-bit aarch64 one, and get the
right gdbarch. However, in the process of parsing auxv (in
inf_ptrace_auxv_parse), the size of int and data pointer of
target_gdbarch is used. If debug program exists (in most of cases),
target_gdbarch is already set according to the debug program, which
is arm in my case. Then, GDB can parse auxv successfully. However,
in gdb.base/attach-pie-noexec.exp, the debug program is removed,
target_gdbarch is aarch64 when GDB parse auxv, so GDB can't parse
it successfully.
Instead of using auxv, we check the return value of ptrace NT_ARM_VFP.
If the program is an arm process, NT_ARM_VFP is OK, otherwise, error
is returned.
Additionally, we only return tdesc_arm_with_neon for arm process,
because neon is mandatory on ARMv8.
gdb:
2016-08-04 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (tdesc_arm_with_vfpv3): Remove the
declaration.
(aarch64_linux_read_description): Remove code on getting
auxv and select target description on it. Select target
description by the result of NT_ARM_VFP ptrace request.
When I run process-dies-while-detaching.exp with GDBserver, I see many
warnings printed by GDBserver,
ptrace(regsets_fetch_inferior_registers) PID=26183: No such process
ptrace(regsets_fetch_inferior_registers) PID=26183: No such process
ptrace(regsets_fetch_inferior_registers) PID=26184: No such process
ptrace(regsets_fetch_inferior_registers) PID=26184: No such process
regsets_fetch_inferior_registers is called when GDBserver resumes each
lwp.
#2 0x0000000000428260 in regsets_fetch_inferior_registers (regsets_info=0x4690d0 <aarch64_regsets_info>, regcache=0x31832020)
at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/linux-low.c:5412
#3 0x00000000004070e8 in get_thread_regcache (thread=0x31832940, fetch=fetch@entry=1) at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/regcache.c:58
#4 0x0000000000429c40 in linux_resume_one_lwp_throw (info=<optimized out>, signal=0, step=0, lwp=0x31832830)
at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/linux-low.c:4463
#5 linux_resume_one_lwp (lwp=0x31832830, step=<optimized out>, signal=<optimized out>, info=<optimized out>)
at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/linux-low.c:4573
The is the case that threads are disappeared when GDB/GDBserver resumes
them. We check errno for ESRCH, and don't print error messages, like
what we are doing in regsets_store_inferior_registers.
gdb/gdbserver:
2016-08-04 Yao Qi <yao.qi@linaro.org>
* linux-low.c (regsets_fetch_inferior_registers): Check
errno is ESRCH or not.
PR python/18565 notes that calling frame filters don't work properly for
inlined functions. This happens because Frame.function on an inline
frame will yield the wrong result. This patch changes this code to use
find_frame_funname instead, which handles inline frames properly.
Built and regtested on x86-64 Fedora 24.
2016-08-03 Tom Tromey <tom@tromey.com>
PR python/18565:
* python/py-frame.c (frapy_function): Use find_frame_funname.
2016-08-03 Tom Tromey <tom@tromey.com>
PR python/18565:
* gdb.python/py-frame-inline.exp: Add Frame.function test.
The PR 18565 thread pointed out that, if cp_remove_params can throw
(we aren't quite sure), then find_frame_funname could leak some
memory. This patch avoids any potential issue by rearranging some
code in find_frame_funname.
Built and regtested on x86-64 Fedora 24.
2016-08-03 Tom Tromey <tom@tromey.com>
* stack.c (find_frame_funname): Avoid any possible leak in case
cp_remove_params can throw.
An earlier patch added three new breakpoint-related events to the
Python API. However, at that time, I forgot to update NEWS. This
patch supplies the missing entry.
2016-08-03 Tom Tromey <tom@tromey.com>
* NEWS: Mention new Python breakpoint events.
A while ago, Pedro announced that I would be the Rust maintainer for
gdb. However, I neglected to update the MAINTAINERS file until now.
2016-08-02 Tom Tromey <tom@tromey.com>
* MAINTAINERS (Core): Add self as Rust maintainer.
As a result of this commit,
9b4c5f878f
(Remove support for thread events without PTRACE_EVENT_CLONE in GDBServer.)
the last usage of td_ta_event_addr td_ta_set_event and
td_ta_event_getmsg were removed. They are no longer used. This patch
is to remove them.
gdb/gdbserver:
2016-08-02 Yao Qi <yao.qi@linaro.org>
* thread-db.c (struct thread_db) <td_ta_event_getmsg_p>: Remove.
<td_ta_set_event_p, td_ta_event_addr_p>: Remove.
(thread_db_load_search): Update.
(try_thread_db_load_1): Don't look for td_ta_event_addr,
td_ta_set_event and td_ta_event_getmsg.
Now that the GDB 7.12 branch has been created, we can
bump the version number.
gdb/ChangeLog:
GDB 7.12 branch created (41bfcd638a):
* version.in: Bump version to 7.12.50.DATE-git.
"single-process" and "multi-process" are used in the test message of
process-dies-while-detaching.exp, but they are misplaced due to
set mode [expr {$multi_process ? "single-process" : "multi-process"}]
This patch is to swap them.
gdb/testsuite:
2016-08-01 Yao Qi <yao.qi@linaro.org>
* gdb.threads/process-dies-while-detaching.exp (do_test): Set
variable mode to "multi-process" if $multi_process is 1, otherwise
set it to "single-process".
There are some gdb.cp/ tests fails if the program is compiled for arm
32-bit but GDB/GDBserver is aarch64 64-bit program, because target triplet
doesn't match "arm*-*-*". Instead, we can use is_aarch32_target.
gdb/testsuite:
2016-08-01 Yao Qi <yao.qi@linaro.org>
* gdb.cp/anon-struct.exp: Check is_aarch32_target.
* gdb.cp/cpexprs.exp: Likewise.
* gdb.cp/m-static.exp: Likewise.
The major reason this header was needed, bfd_default_set_arch_mach,
has now moved to bfd.h.
gdb/
* amd64-darwin-tdep.c: Don't include libbfd.h.
* i386-darwin-tdep.c: Likewise.
* rs6000-nat.c: Likewise.
* rs6000-tdep.c: Likewise.
sim/aarch64/
* memory.c: Don't include libbfd.h.
sim/rl78/
* load.c: Don't include libbfd.h.
(rl78_load): Don't use private iovec seek or read.
sim/rx/
* load.c: Don't include libbfd.h.
(rx_load): Don't use private iovec seek or read.
Debugging an x32 process with an x32 gdbserver always results in:
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0xf7de9600 in _dl_debug_state () from target:/libx32/ld-linux-x32.so.2
(gdb)
Looking at the remote debug logs reveals the problem, here:
Packet received: T05swbreak:;06:a0d4ffff00000000;07:b8d3ffff00000000;10:0096def701000000;thread:p7d7a.7d7a;core:1;
^^^^^^^^^^^^^^^^
The underlined value is the expedited value of RIP (in little endian).
But notice that 01 in 0x01f7de9600, while gdb says the program stopped
at 0xf7de9600. 0x01ffffffff is over 32 bits, which indicates that
something wen't wrong somewhere in gdbserver.
The problem turns out to be in gdbserver's x86_get_pc / x86_set_pc
routines, where "unsigned long" is used assuming that it can fit a
64-bit value, while unsigned long is actually 32-bit on x32. The
result is that collect_register_by_name / supply_register_by_name end
up reading/writing random bytes off the stack.
Fix this by using explicit uint64_t instead of unsigned long.
For consistency, use uint32_t instead of unsigned int in the 32-bit
paths.
gdb/gdbserver/ChangeLog:
2016-07-26 Pedro Alves <palves@redhat.com>
PR server/20414
* linux-x86-low.c (x86_get_pc, x86_set_pc): Use uint64_t instead
of unsigned long for 64-bit registers and use uint32_t instead of
unsigned int for 32-bit registers.
PR python/20190 arose from an exception I noticed when trying to use
the Python unwinder for Spider Monkey in Firefox.
The problem is that the unwinder wants to examine the value of a
thread-local variable. However, sympy_value rejects this because
symbol_read_needs_frame returns true for a TLS variable.
This problem arose once before, though in a different context:
https://sourceware.org/bugzilla/show_bug.cgi?id=11803
At the time Pedro and Daniel pointed out a simpler way to fix that bug
(see links in 20190 if you are interested); but for this new bug I
couldn't think of a similar fix and ended up implementing Daniel's
other suggestion:
https://sourceware.org/ml/gdb-patches/2010-07/msg00393.html
That is, this patch makes it possible to detect whether a symbol needs
a specific frame, or whether it just needs the inferior to have
registers.
Built and regtested on x86-64 Fedora 24.
2016-07-26 Tom Tromey <tom@tromey.com>
* symtab.c (register_symbol_computed_impl): Update.
PR python/20190:
* value.h (symbol_read_needs): Declare.
(symbol_read_needs_frame): Add comment.
* symtab.h (struct symbol_computed_ops) <read_variable>: Update
comment.
<get_symbol_read_needs>: Rename. Change return type.
* findvar.c (symbol_read_needs): New function.
(symbol_read_needs_frame): Rewrite.
(default_read_var_value): Use symbol_read_needs.
* dwarf2loc.c (struct symbol_needs_baton): Rename.
<needs>: Renamed from needs_frame. Changed type.
(needs_frame_read_addr_from_reg, symbol_needs_get_reg_value)
(symbol_needs_read_mem, symbol_needs_frame_base)
(symbol_needs_frame_cfa, symbol_needs_tls_address)
(symbol_needs_dwarf_call): Rename.
(needs_dwarf_reg_entry_value): Update.
(symbol_needs_ctx_funcs, dwarf2_loc_desc_get_symbol_read_needs):
Rename and update.
(locexpr_get_symbol_read_needs, loclist_symbol_needs): Likewise.
(dwarf2_locexpr_funcs, dwarf2_loclist_funcs): Update.
* defs.h (enum symbol_needs_kind): New.
2016-07-26 Tom Tromey <tom@tromey.com>
PR python/20190:
* gdb.threads/tls.exp (check_thread_local): Add python symbol
test.
An x32 gdb always issues this warning:
(gdb) start
Temporary breakpoint 1 at 0x4043e9: file foo.c, line 25.
Starting program: a.out
warning: linux_ptrace_test_ret_to_nx: Cannot PTRACE_PEEKUSER: Input/output error
Temporary breakpoint 1, main (argc=1, argv=0xffffd544) at foo.c:25
25 {
(gdb)
As described in Linux commit 55283e253771 (x32: Add ptrace for x32):
[...] PTRACE_PEEKUSR and PTRACE_POKEUSR are only allowed to access
segment and debug registers. [...]
The fix is to use PTRACE_GETREGS instead.
gdb/ChangeLog:
2016-07-26 Pedro Alves <palves@redhat.com>
* nat/linux-ptrace.c: Include "gregset.h".
(linux_ptrace_test_ret_to_nx): Use PTRACE_GETREGS instead of
PTRACE_PEEKUSER.
Building an x32 gdb trips on a static assertion:
In file included from .../src/gdb/common/common-defs.h:71:0,
from .../src/gdb/nat/amd64-linux-siginfo.c:21:
.../src/gdb/common/gdb_assert.h:26:66: error: size of array ‘never_defined_just_used_for_checking’ is negative
extern int never_defined_just_used_for_checking[(expr) ? 1 : -1]
^
.../src/gdb/nat/amd64-linux-siginfo.c:113:1: note: in expansion of macro ‘gdb_static_assert’
gdb_static_assert (sizeof (nat_siginfo_t) == sizeof (siginfo_t));
^
The problem is that the way nat_siginfo_t is defined, it can only
match the host's siginfo_t object when gdb is built as a 64-bit
program.
Several bits of nat_siginfo_t are off:
- nat_siginfo_t's _pad field's definition is:
int _pad[((128 / sizeof (int)) - 4)];
while /usr/include/bits/siginfo.h has:
# define __SI_MAX_SIZE 128
# if __WORDSIZE == 64
# define __SI_PAD_SIZE ((__SI_MAX_SIZE / sizeof (int)) - 4)
# else
# define __SI_PAD_SIZE ((__SI_MAX_SIZE / sizeof (int)) - 3)
# endif
and __WORDSIZE == 32 for x32. This is what causes the size of
nat_siginfo_t to be wrong and the assertion to fail.
- the nat_clock_t type is incorrect for 64-bit. We have this:
/* For native 64-bit, clock_t in _sigchld is 64bit aligned at 4 bytes. */
typedef long __attribute__ ((__aligned__ (4))) nat_clock_t;
however, /usr/include/bits/siginfo.h has:
# if defined __x86_64__ && __WORDSIZE == 32
/* si_utime and si_stime must be 4 byte aligned for x32 to match the
kernel. We align siginfo_t to 8 bytes so that si_utime and si_stime
are actually aligned to 8 bytes since their offsets are multiple of
8 bytes. */
typedef __clock_t __attribute__ ((__aligned__ (4))) __sigchld_clock_t;
# define __SI_ALIGNMENT __attribute__ ((__aligned__ (8)))
# else
typedef __clock_t __sigchld_clock_t;
# define __SI_ALIGNMENT
# endif
So we're currently forcing 4-byte alignment on clock_t, when it
should only be so for x32, not 64-bit.
The fix:
- Leaves nat_siginfo_t strictly for the 64-bit ABI.
- Adds a new typedef for the siginfo type that ptrace uses
(ptrace_siginfo_t). An x32 gdb always gets/sets an x32 siginfo_t
type with PTRACE_GETSIGINFO/PTRACE_SETSIGINFO.
- Uses this new ptrace_siginfo_t type instead of nat_siginfo_t as the
intermediate conversion type.
gdb/ChangeLog:
2016-07-26 Pedro Alves <palves@redhat.com>
* amd64-linux-nat.c (amd64_linux_siginfo_fixup): Rename 'native'
parameter to 'ptrace'.
* nat/amd64-linux-siginfo.c (GDB_SI_SIZE): New define.
(nat_uptr_t): New an unsigned long.
(nat_clock_t): Remove attribute __aligned__.
(struct nat_timeval): Delete.
(nat_siginfo_t): Remove attribute __aligned__.
(ptrace_siginfo_t): Define.
(compat_siginfo_from_siginfo, siginfo_from_compat_siginfo)
(compat_x32_siginfo_from_siginfo)
(siginfo_from_compat_x32_siginfo): Make 'from' parameter const.
Convert through a ptrace_siginfo_t instead of a nat_siginfo_t.
Remove casts.
(amd64_linux_siginfo_fixup_common): Rename 'native' parameter to
'ptrace'. Remove static assertions.
(top level): New static assertions.
gdb/gdbserver/ChangeLog:
2016-07-26 Pedro Alves <palves@redhat.com>
* linux-x86-low.c (x86_siginfo_fixup): Rename 'native' parameter
to 'ptrace'.
Some btrace tests use assembly source files. They use the target triplet to
distinguish between x86_64 and ia32 ISA. This does not work for -m32 tests
without setting the target triplet to i686-?-?.
Instead use is_amd64_regs_target to distinguish between x86_64 and ia32 ISA.
See also https://sourceware.org/ml/gdb-patches/2016-07/msg00256.html.
testsuite/
* gdb.btrace/record_goto.exp: Use is_amd64_regs_target for selecting
assembly source files.
* gdb.btrace/stepi.exp: Use is_amd64_regs_target for selecting
assembly source files.
* gdb.btrace/tailcall.exp: Use is_amd64_regs_target for selecting
assembly source files.
* gdb.btrace/tailcall-only.exp: Use is_amd64_regs_target for selecting
assembly source files.
When a bad interpreter name is passed to new-ui, such as:
(gdb) new-ui bloop /dev/pts/10
A partially created UI is left in the UI list, with interp set to NULL.
Trying to do anything that will print on this UI (such as "start") will
cause a segmentation fault.
Changes in v2:
- Use with_test_prefix to namespace test procedures
- Give an explicit stable test name
- Add a "bad terminal path" test
- Remove useless runto_main
- Add missing intro comments
I did not factor out the pty spawn, as there is some magic involved I
don't quite understand. But it wouldn't bring that much anyway.
gdb/ChangeLog:
* top.h (make_delete_ui_cleanup): New declaration.
* top.c (delete_ui_cleanup): New function.
(make_delete_ui_cleanup): New function.
(new_ui_command): Create restore_ui cleanup earlier, create a
delete_ui cleanup and discard it on success.
gdb/testsuite/ChangeLog:
* gdb.base/new-ui.exp (do_test_invalid_args): New
procedure.
Since Linux 2.6.33, /proc/PID/status shows "t (tracing stop)", with
lowercase 't'. Because GDB is only expecting "T (tracing stop)", GDB
can incorrectly suppress errors in check_ptrace_stopped_lwp_gone:
1578 if (!check_ptrace_stopped_lwp_gone (lp))
1579 throw_exception (ex);
Ref: https://sourceware.org/ml/gdb-patches/2016-06/msg00072.html
2016-07-25 Pedro Alves <palves@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
* nat/linux-procfs.c (parse_proc_status_state): Handle lowercase
't'.
Parse the process's /proc/PID/status state into an enum instead of the
current scheme of passing state strings around.
gdb/ChangeLog:
2016-07-25 Pedro Alves <palves@redhat.com>
* nat/linux-procfs.c (enum proc_state): New enum.
(parse_proc_status_state): New function.
(linux_proc_pid_get_state): Replace output string buffer parameter
with an output proc_state parameter. Use parse_proc_status_state.
(linux_proc_pid_is_gone): Adjust to use proc_state values.
(linux_proc_pid_has_state): Change type of 'state' parameter; now
an enum proc_state. Adjust to linux_proc_pid_get_state interface
change.
(linux_proc_pid_is_stopped)
(linux_proc_pid_is_trace_stopped_nowarn)
(linux_proc_pid_is_zombie_maybe_warn): Adjust to
linux_proc_pid_get_state interface change.
This patch allows gdbserver to continue recording after disconnect. On
reconnect, the recorded data is accessible to gdb as if no disconnect happened.
A possible application for this feature is remotely examine bugs that occur
at irregular intervals, where maintaining a gdb connection is inconvenient.
This also fixes the issue mentioned here:
https://sourceware.org/ml/gdb-patches/2015-11/msg00424.html
Signed-off-by: Tim Wiederhake <tim.wiederhake@intel.com>
gdb/ChangeLog:
* NEWS: Resume btrace on reconnect.
* record-btrace.c: Added record-btrace.h include.
(record_btrace_open): Split into this and ...
(record_btrace_push_target): ... this.
(record_btrace_disconnect): New function.
(init_record_btrace_ops): Use record_btrace_disconnect.
* record-btrace.h: New file.
* remote.c: Added record-btrace.h include.
(remote_start_remote): Check recording status.
(remote_btrace_maybe_reopen): New function.
gdb/doc/ChangeLog:
* gdb.texinfo: Resume btrace on reconnect.
gdb/testsuite/ChangeLog:
* gdb.btrace/reconnect.c: New file.
* gdb.btrace/reconnect.exp: New file.
Change-Id: I95e8b0ab8a89e58591aba0e63818cee82fd211bc
Implement support to add catchpoints for a group of related syscalls
using the syntax:
(gdb) catch syscall group:<group>
or
(gdb) catch syscall g:<group>
Several groups are predefined in the xml files for all architectures
supported by GDB over Linux. They are based on the groups defined by
strace.
gdb/
* xml-syscall.c (get_syscalls_by_group): New.
(get_syscall_group_names): New.
(struct syscall_group_desc): New structure to store group data.
(struct syscalls_info): Include field to store the group list.
(sysinfo_free_syscall_group_desc): New.
(free_syscalls_info): Free group list.
(syscall_group_create_syscall_group_desc): New.
(syscall_group_add_syscall): New.
(syscall_create_syscall_desc): Add syscall to its groups.
(syscall_start_syscall): Load group attribute.
(syscall_group_get_group_by_name): New.
(xml_list_syscalls_by_group): New.
(xml_list_of_groups): New.
* xml-syscall.h (get_syscalls_by_group): Export function
to retrieve a list of syscalls filtered by the group name.
(get_syscall_group_names): Export function to retrieve the list
of syscall groups.
* break-catch-syscall.c (catch_syscall_split_args): Verify if
argument is a syscall group and expand it to a list of syscalls
when creating catchpoints.
(catch_syscall_completer): Add word completion for system call
groups.
* configure.ac: Include dependency for xsltproc when building
in maintainer-mode.
* break-catch-syscall.c (_initialize_breakpoint): Update catch
syscall command documentation.
* NEWS: Include section about catching groups of syscalls.
* configure: Regenerate.
* data-directory/Makefile.in: Generate syscall xml when building
in maintainer mode.
* syscalls/gdb-syscalls.dtd: Include group attribute to the
syscall element.
* syscalls/apply-defaults.xsl: New.
* syscalls/linux-defaults.xml.in: New.
* syscalls/aarch64-linux.xml: Rename to aarch64-linux.xml.in.
* syscalls/amd64-linux.xml: Rename to amd64-linux.xml.in.
* syscalls/arm-linux.xml: Rename to arm-linux.xml.in.
* syscalls/bfin-linux.xml: Rename to bfin-linux.xml.in.
* syscalls/i386-linux.xml: Rename to i386-linux.xml.in.
* syscalls/mips-n32-linux.xml: Rename to mips-n32-linux.xml.in.
* syscalls/mips-n64-linux.xml: Rename to mips-n64-linux.xml.in.
* syscalls/mips-o32-linux.xml: Rename to mips-o32-linux.xml.in.
* syscalls/ppc-linux.xml: Rename to ppc-linux.xml.in.
* syscalls/ppc64-linux.xml: Rename to ppc64-linux.xml.in.
* syscalls/s390-linux.xml: Rename to s390-linux.xml.in.
* syscalls/s390x-linux.xml: Rename to s390x-linux.xml.in.
* syscalls/sparc-linux.xml: Rename to sparc-linux.xml.in.
* syscalls/sparc64-linux.xml: Rename to sparc64-linux.xml.in.
* syscalls/aarch64-linux.xml: Regenerate.
* syscalls/amd64-linux.xml: Regenerate.
* syscalls/arm-linux.xml: Regenerate.
* syscalls/i386-linux.xml: Regenerate.
* syscalls/mips-n32-linux.xml: Regenerate.
* syscalls/mips-n64-linux.xml: Regenerate.
* syscalls/mips-o32-linux.xml: Regenerate.
* syscalls/ppc-linux.xml: Regenerate.
* syscalls/ppc64-linux.xml: Regenerate.
* syscalls/s390-linux.xml: Regenerate.
* syscalls/s390x-linux.xml: Regenerate.
* syscalls/sparc-linux.xml: Regenerate.
* syscalls/sparc64-linux.xml: Regenerate.
gdb/testsuite/
* gdb.base/catch-syscall.exp (do_syscall_tests): Add call
to test_catch_syscall_group.
(test_catch_syscall_group): New.
gdb/doc/
* gdb.texinfo (Set Catchpoints): Add 'group' argument to catch
syscall.
The problem here is ARMv8.1 (and ARMv8.2) define a
different debug version than ARMv8 (7 and 8 respectively).
This fixes hw watchpoints and breakpoints by checking
for those debug versions too.
Committed as obvious after a test on aarch64-linux-gnu
(on a ThunderX machine which has ARMv8.1 support enabled).
ChangeLog:
* nat/aarch64-linux-hw-point.c
(aarch64_linux_get_debug_reg_capacity): Handle
ARMv8.1 and ARMv8.2 debug versions.
* nat/aarch64-linux-hw-point.h
(AARCH64_DEBUG_ARCH_V8_1): New define.
(AARCH64_DEBUG_ARCH_V8_2): New define.
Signed-off-by: Andrew Pinski <apinski@cavium.com>
Carl E. Love
Carl Love
Edjunior Barbosa Machado
Simon Marchi
Matthew Wahab
Yao Qi
Pedro Alves
Руслан Ижбулатов
Tom Tromey
Joel Brobecker
Alan Modra
Markus Metzger
Tim Wiederhake
Gabriel Krisman Bertazi
Andrew Pinski