In readline 6.3, the semantics of SIGWINCH handling has changed.
When a SIGWINCH signal is raised, readline's rl_sigwinch_handler() now
does not immediately call rl_resize_terminal(). Instead it sets a flag
that is checked by RL_CHECK_SIGNALS() at a point where readline has
control, and calls rl_resize_terminal() if said flag is set.
This change is item (c) in https://cnswww.cns.cwru.edu/php/chet/readline/CHANGES
c. Fixed a bug that caused readline to try and run code to modify its idea
of the screen size in a signal handler context upon receiving a SIGWINCH.
This change in behavior is important to us because TUI's
tui_sigwinch_handler() relies on the assumption that by the time it's
called, readline will have updated its knowledge of the terminal
dimensions via rl_resize_terminal(). Since this assumption no longer
holds true, TUI's SIGWINCH handling does not work correctly with
readline 6.3.
To fix this issue this patch makes TUI explicitly call
rl_resize_terminal() in tui_async_resize_screen() at the point where
current terminal dimensions are needed. (We could call it in
tui_sigwinch_handler too, but since readline avoids doing it, we are
probably safer off avoiding to call it in signal handler context as
well.) After this change, SIGWINCH handling continues to work properly
with both readline 6.2 and 6.3.
Since we no longer need it, we could now explicitly disable readline's
SIGWINCH handler by setting rl_catch_sigwinch to zero early on in the
program startup but I can't seem to find a good spot to place this
assignment (the first call to rl_initialize() occurs in
tui_initialize_readline() so the assignment should occur before then),
and the handler is harmless anyway.
gdb/ChangeLog:
* tui/tui-win.c (tui_async_resize_screen): Call
rl_resize_terminal().
Using the 'catch-signal' test from the testsuite, on x86_64 Cygwin:
$ ./gdb testsuite/outputs/gdb.base/catch-signal/catch-signal.exe
[...]
(gdb) catch signal
Catchpoint 1 (standard signals)
(gdb) r
[...]
Catchpoint 1 (signal SIGHUP), main () at
../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
(gdb) c
Continuing.
main () at ../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
Failed to resume program execution (ContinueDebugEvent failed, error 87)
(gdb)
This error occurs because when handle_output_debug_string processes a Cygwin
signal message, it re-writes current_event.dwThreadId to reflect the thread that
the signal will be delivered to, which can be different to the thread reporting
the signal.
Altering current_event.dwThreadId() will cause ContinueDebugEvent() to be
applied to the wrong thread and fail.
So, rather than re-writing the thread id in current_event, use the thread
id by returning it.
With this patch applied this test now yields the expected result:
$ ./gdb testsuite/outputs/gdb.base/catch-signal/catch-signal.exe
[...]
(gdb) catch signal
Catchpoint 1 (standard signals)
(gdb) r
[...]
Catchpoint 1 (signal SIGHUP), main () at
../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
(gdb) c
Continuing.
Catchpoint 1 (signal SIGHUP), main () at
../../../gdb/testsuite/gdb.base/catch-signal.c:42
42 raise (SIGHUP); /* third HUP */
(gdb)
gdb/ChangeLog:
2015-04-22 Jon Turney <jon.turney@dronecode.org.uk>
* windows-nat.c (handle_output_debug_string): Don't change
current_event.dwThreadId.
(get_windows_debug_event): Use thread_id, rather than relying on
current_event.dwThreadId being changed.
Using the 'catch-signal' test from the testsuite, on x86_64 Cygwin:
$ ./gdb testsuite/outputs/gdb.base/catch-signal/catch-signal.exe
[...]
(gdb) catch signal
Catchpoint 1 (standard signals)
(gdb) r
[...]
Catchpoint 1 (signal SIGHUP), main () at
../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
(gdb) c
Continuing.
[hangs]
This is due to a defect in the way Cygwin signals are handled: When
handle_output_debug_string processes a Cygwin signal message, it re-writes
current_event.dwThreadId to reflect the thread that the signal will be delivered
to.
Subsequently, the call to ContinueDebugEvent will fail, because we're trying to
resume the wrong thread. GDB is then stuck waiting forever for another event
that will never come.
This patch doesn't fix the problem, it just adds appropriate error handling.
Using error() seems appropriate here, if ContinueDebugEvent() fails, the
inferior is in an unknown state and we will probably not be debugging it
anymore.
With this patch applied, resuming the execution of the program now yields:
$ ./gdb testsuite/outputs/gdb.base/catch-signal/catch-signal.exe
[...]
(gdb) catch signal
Catchpoint 1 (standard signals)
(gdb) r
[...]
Catchpoint 1 (signal SIGHUP), main () at
../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
(gdb) c
Continuing.
main () at ../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
Failed to resume program execution (ContinueDebugEvent failed, error 87)
(gdb)
gdb/ChangeLog:
2015-04-22 Jon Turney <jon.turney@dronecode.org.uk>
* windows-nat.c (windows_continue): Report an error if
ContinueDebugEvent() fails.
Problem reported as PR pascal/17815
Part 1/3: Remember the case pattern that allowed finding a field of this.
File gdb/p-exp.y modified
This is the fix in the pascal parser (p-exp.y),
to avoid the error that GDB does find normal variables
case insensitively, but not fields of this,
inside a class or object method.
Part 2/3: Add "class" option for pascal compiler
File gdb/testsuite/lib/pascal.exp
This part of the patch series is unchanged.
It adds class option to pascal compiler
which adds the required command line option to
accept pascal class types.
Part 3/3:
New file: gdb/testsuite/gdb.pascal/case-insensitive-symbols.exp
New file: gdb/testsuite/gdb.pascal/case-insensitive-symbols.pas
Here is an updated version of this test, using Pedro's suggestions.
Test to check that PR 17815 is fixed.
This patch extends the rl78 prologue analyzer so that it can recognize
this kind of prologue:
0x119f <main>: movw ax, sp
0x11a1 <main+2>: subw ax, #0x1fa6
0x11a4 <main+5>: movw sp, ax
The test case for gdb.base/miscexprs.exp is now compiled to generate
that sequence instead of a much longer and more inefficient sequence.
gdb/ChangeLog:
* rl78-tdep.c (RL78_SP_ADDR): Define.
(opc_reg_to_gdb_regnum): New static function.
(rl78_analyze_prologue): Recognize instructions forming slightly
more interesting prologues.
This commit fixes three gdb.base/attach.exp failures when using
extended remote targets. The failures occurred because GDB now
locates and loads files when attaching on remote targets if the
remote target supports qXfer:exec-file:read; the filenames were
shown but with "target:" prefixes which the test has been updated
to handle.
gdb/testsuite/ChangeLog:
* gdb.base/attach.exp: Fix three extended remote failures.
Code in update_dprintf_command_list performed a duplicated memory
allocation which caused an obvious memory leak. This removes the
duplication.
gdb/
2015-04-19 Gabriel Krisman Bertazi <gabriel@krisman.be>
* breakpoint.c (update_dprintf_command_list): Remove duplicated
xmalloc.
gdb/
* reply_mig_hack.awk: Don't bother to declare an intermediate
function pointer variable.
... allowing us to simplify the parsing a little bit. And, instead of
"warning: initialization from incompatible pointer type", we now get "warning:
function called through a non-compatible type". Oh well.
gdb/ChangeLog:
* solib-svr4.c (svr4_exec_displacement): Rename outer "displacement"
to "exec_displacement" to avoid confusion with inner use of the name.
xtensa_usrregs_info refers to undefined variables xtensa_num_regs and
xtensa_regmap. Drop xtensa_usrregs_info and replace pointer to usrregs
in regs_info with NULL since all registers are read/set through regsets.
2015-04-17 Max Filippov <jcmvbkbc@gmail.com>
gdb/gdbserver/
* linux-xtensa-low.c (xtensa_usrregs_info): Remove.
(regs_info): Replace usrregs pointer with NULL.
This patch is to cherry-pick part of Pedro's patch here
https://sourceware.org/ml/gdb-patches/2015-04/msg00527.html in which
zero is returned if the HW point isn't supported.
In arm-linux native gdb testing on a board doesn't support HW breakpoint,
without this patch, the output in gdb.base/breakpoint-in-ro-region.exp is like:
(gdb) hbreak *0x83bc^M
Hardware breakpoints used exceeds limit.^M
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: probe hbreak support (support)
with this patch, the output becomes:
(gdb) hbreak *0x83bc^M
No hardware breakpoint support in the target.^M
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: probe hbreak support (no support)
As a result, the following fails are fixed.
-FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: step in ro region (cannot insert hw break)
-FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: thread advanced
-FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw on: step in ro region (cannot insert hw break)
-FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw on: thread advanced
gdb:
2015-04-17 Pedro Alves <palves@redhat.com>
* arm-linux-nat.c (arm_linux_can_use_hw_breakpoint): Return zero
if HW point of TYPE isn't supported.
The return value of target_can_use_hardware_watchpoint isn't well
documented, so this patch is to update the comments to reflect the
fact. This patch also removes a trailing ";" which is picked up
from Pedro's patch https://sourceware.org/ml/gdb-patches/2015-04/msg00527.html
gdb:
2015-04-17 Yao Qi <yao.qi@linaro.org>
Pedro Alves <palves@redhat.com>
* target.h (target_can_use_hardware_watchpoint): Update comments.
Remove trailing ";".
This commit modifies remote_add_inferior to take an extra argument
try_open_exec. If this is nonzero, remote_add_inferior will attempt
to open this inferior's executable as the main executable if no main
executable is open already. Callers are updated appropriately.
With this commit, remote debugging can now be initiated using only a
"target remote" or "target extended-remote" command; no "set sysroot"
or "file" commands are required, e.g.
bash$ gdb -q
(gdb) target remote | gdbserver - /bin/sh
Remote debugging using | gdbserver - /bin/sh
Process /bin/sh created; pid = 32166
stdin/stdout redirected
Remote debugging using stdio
Reading symbols from target:/bin/bash...
One testcase required updating as a result of this commit. The test
checked that GDB's "info files" command does not crash if no main
executable is open, and relied on GDB's inability to access the main
executable over the remote protocol. The test was updated to inhibit
this new behavior.
gdb/ChangeLog:
* remote.c (remote_add_inferior): New argument try_open_exec.
If nonzero, attempt to open the inferior's executable file as
the main executable if no main executable is open already.
All callers updated.
* NEWS: Mention that GDB now supports automatic location and
retrieval of executable + files from remote targets.
gdb/doc/ChangeLog:
* gdb.texinfo (Connecting to a Remote Target): Mention that
GDB can access program files from remote targets that support
qXfer:exec-file:read and Host I/O packets.
gdb/testsuite/ChangeLog:
* gdb.server/server-exec-info.exp: Inhibit GDB from accessing
the main executable over the remote protocol.
This commit adds a new packet "qXfer:exec-file:read" to the remote
protocol that can be used to obtain the pathname of the file that
was executed to create a process on the remote system. Support for
this packet is added to GDB and remote_ops.to_pid_to_exec_file is
implemented using it.
gdb/ChangeLog:
* target.h (TARGET_OBJECT_EXEC_FILE): New enum value.
* remote.c (PACKET_qXfer_exec_file): Likewise.
(remote_protocol_features): Register the
"qXfer:exec-file:read" feature.
(remote_xfer_partial): Handle TARGET_OBJECT_EXEC_FILE.
(remote_pid_to_exec_file): New function.
(init_remote_ops): Initialize to_pid_to_exec_file.
(_initialize_remote): Register new "set/show remote
pid-to-exec-file-packet" command.
* NEWS: Announce new qXfer:exec-file:read packet.
gdb/doc/ChangeLog:
* gdb.texinfo (Remote Configuration): Document the "set/show
remote pid-to-exec-file-packet" command.
(General Query Packets): Document the qXfer:exec-file:read
qSupported features. Document the qXfer:exec-file:read packet.
This commit introduces a new function linux_proc_pid_to_exec_file
that shared Linux code can use to discover the filename of the
executable that was run to create a process on the system.
gdb/ChangeLog:
* nat/linux-procfs.h (linux_proc_pid_to_exec_file):
New declaration.
* nat/linux-procfs.c (linux_proc_pid_to_exec_file):
New function, factored out from...
* linux-nat.c (linux_child_pid_to_exec_file): ...here.
This commit updates exec_file_locate_attach to use exec_file_find
to compute the full pathname of the main executable in some cases.
The net effect of this is that the main executable's path will be
prefixed with gdb_sysroot in the same way that shared library paths
currently are.
gdb/ChangeLog:
* exec.c (solist.h): New include.
(exec_file_locate_attach): Prefix absolute executable
paths with gdb_sysroot if set.
* NEWS: Mention that executable paths may be prepended
with sysroot.
gdb/doc/ChangeLog:
* gdb.texinfo (set sysroot): Document that "set sysroot" also
applies to executable paths if supplied to GDB as absolute.
This commit adds a new function, exec_file_find, which computes the
full pathname of the main executable in much the same way solib_find
does for pathnames of shared libraries. The bulk of the existing
solib_find was moved into a new static function solib_find_1, with
exec_file_find and solib_find being small wrappers for solib_find_1.
gdb/ChangeLog:
* solist.h (exec_file_find): New declaration.
* solib.c (solib_find_1): New function, factored out from...
(solib_find): ...here.
(exec_file_find): New function.
This commit adds a new function, exec_file_locate_attach, which works
like exec_file_attach except that, instead of a filename argument, it
takes an integer process ID and attempts to determine the executable
filename from that.
gdb/ChangeLog:
* gdbcore.h (exec_file_locate_attach): New declaration.
* exec.c (exec_file_locate_attach): New function, factored
out from...
* infcmd.c (attach_command_post_wait): ...here.
Fixes:
-FAIL: gdb.trace/mi-tracepoint-changed.exp: reconnect: break-info 1
+PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: tracepoint created
+PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: tracepoint on marker is installed
+PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: break-info 1
-FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created
-FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created
+PASS: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created
+PASS: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created
These tests do something like this:
#0 - start gdb/gdbserver normally
#1 - setup some things in the debug session
#2 - disconnect from gdbserver
#3 - restart gdb
#4 - reconnect to gdbserver
The problem is that the native-extended-gdbserver board always spawns
a new gdbserver instance in #3 (and has gdb connect to that). So when
the test gets to #4, it connects to that new instance instead of the
old one:
(gdb) spawn ../gdbserver/gdbserver --multi :2354
Listening on port 2354
target extended-remote localhost:2354
Remote debugging using localhost:2354
...
spawn ../gdbserver/gdbserver --multi :2355
Listening on port 2355
47-target-select extended-remote localhost:2355
=tsv-created,name="trace_timestamp",initial="0"\n
47^connected
(gdb)
...
47-target-select extended-remote localhost:2355
47^connected
(gdb)
FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created
FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created
testsuite/ChangeLog:
2015-04-16 Pedro Alves <palves@redhat.com>
* boards/native-extended-gdbserver.exp (mi_gdb_start): Don't start
a new gdbserver if gdbserver_reconnect_p is set.
Commit 6423214f (testsuite: Don't use expect_background to reap
gdbserver) broke a couple tests that set gdbserver_reconnect_p and
restart gdb before reconnecting, because a gdb_exit (e.g., through
clean_restart) exits gdbserver unconditionally.
Fixes, with --target_board=native-gdbserver:
-FAIL: gdb.trace/mi-tracepoint-changed.exp: reconnect: break-info 1
+PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: tracepoint created
+PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: tracepoint on marker is installed
+PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: break-info 1
-FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created
-FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created
+PASS: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created
+PASS: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created
gdb/testsuite/
2015-04-16 Pedro Alves <palves@redhat.com>
* lib/gdbserver-support.exp (gdb_exit): If gdbserver_reconnect_p
is set, don't exit gdbserver.
Hi,
When I run gdb.threads/non-stop-fair-events.exp on arm-linux target,
I see the following message in the debugging log,
displaced: breakpoint is gone: Thread 22518, step(1)^M
Sending packet: $vCont;s:p57f3.57f6#9d...
^^^^^^^^^
GDB sends vCont;s by mistake, and GDBserver fails on assert. GDB
doesn't consider software single step in infrun.c:displaced_step_fixup,
/* Go back to what we were trying to do. */
step = currently_stepping (tp);
if (debug_displaced)
fprintf_unfiltered (gdb_stdlog,
"displaced: breakpoint is gone: %s, step(%d)\n",
target_pid_to_str (tp->ptid), step);
target_resume (ptid, step, GDB_SIGNAL_0);
The patch is to let GDB consider software single step here. It fixes
fails in gdb.threads/non-stop-fair-events.exp on arm.
gdb:
2015-04-16 Yao Qi <yao.qi@linaro.org>
* infrun.c (maybe_software_singlestep): Declare.
(displaced_step_fixup): Call maybe_software_singlestep.
The test case s390-vregs.exp yields compile errors on 31-bit targets
as well as when using a GCC that defaults to an older "-march=". This
patch fixes these issues.
gdb/testsuite/ChangeLog:
* gdb.arch/s390-vregs.S (change_vrs): Replace exrl by an
appropriate .insn, such that an older assembler can be used.
* gdb.arch/s390-vregs.exp: Add the compile flag -mzarch, to enable
the z/Architecture instruction set on 31-bit targets as well.
On s390x targets some of the Go test cases fail because the first
breakpoint happens to be at the same spot as the breakpoint at
main.main. When such a test case tries to continue to the first
breakpoint, the program runs until the end instead, and the test fails
like this:
FAIL: gdb.go/handcall.exp: Going to first breakpoint (the program exited)
This patch removes all the handling related to the first breakpoint in
those cases. After applying the patch, the tests run successfully on
s390x.
gdb/testsuite/ChangeLog:
* gdb.go/handcall.exp: Remove all logic related to the first
breakpoint and rely on go_runto_main instead.
* gdb.go/strings.exp: Likewise.
* gdb.go/unsafe.exp: Likewise.
* gdb.go/hello.exp: Likewise. Also rename the remaining
breakpoint marker to "breakpoint 1".
* gdb.go/handcall.go: Remove comment "set breakpoint 1 here".
* gdb.go/strings.go: Likewise.
* gdb.go/unsafe.go: Likewise.
* gdb.go/hello.go: Likewise. Also remove the second occurrence of
"set breakpoint 2 here" and rename the remaining breakpoint marker
to "breakpoint 1".
"info fun foo" can be a pain when it's not interruptable,
especially if you're not exactly sure of what you're looking for
and provide something that matches too much.
gdb/ChangeLog:
* dwarf2read.c (dw2_expand_symtabs_matching): Add some QUIT calls.
Some missing parentheses and one itertools.imap (Py2) vs map (Py3) issue.
gdb/ChangeLog:
* python/lib/gdb/command/unwinders.py: Add parentheses.
gdb/testsuite/ChangeLog:
* gdb.python/py-framefilter.py (ErrorFilter.filter): Use map function
if itertools.imap is not present.
* gdb.python/py-objfile.exp: Add parentheses.
* gdb.python/py-type.exp: Same.
* gdb.python/py-unwind-maint.py: Same.
When I "set debug displaced 1" to fix fail in
gdb.base/disp-step-syscall.exp, the debug message is wrong. This
patch is to fix it.
gdb:
2015-04-15 Yao Qi <yao.qi@linaro.org>
* arm-linux-tdep.c (arm_linux_copy_svc): Update debug message.
Hi,
I see this fail on arm-linux target,
FAIL: gdb.base/disp-step-syscall.exp: fork: single step over fork final pc
which is caused by the PC isn't expected after displaced stepping the
svc instruction. The code is:
=> 0xb6ead9a4 <__libc_do_syscall+4>: svc 0
0xb6ead9a6 <__libc_do_syscall+6>: pop {r7, pc}
0xb6ead9a8: nop.w^M
0xb6ead9ac: nop.w
after single step svc instruction, pc should be 0xb6ead9a6, but the
actual value of pc is 0xb6ead9a8. The problem is illustrated by
turning on debug message of displaced stepping,
stepi^M
displaced: stepping Thread 12031 now^M
displaced: saved 0x8574: 02 bc 6a 46 04 b4 01 b4 df f8 10 c0 4d f8 04 cd 03 48 04 4b ff f7 d2 ef ff f7 e8 ef 0d 87 00 00 ^M
displaced: process thumb insn df00 at b6ead9a4^M
displaced: copying svc insn df00^M
displaced: read r7 value 00000078^M
displaced: sigreturn/rt_sigreturn SVC call not in signal trampoline frame^M
displaced: writing insn df00 at 00008574^M
displaced: copy 0xb6ead9a4->0x8574: displaced: check mode of b6ead9a4 instead of 00008574^M
displaced: displaced pc to 0x8574^M
displaced: run 0x8574: 00 df 01 de ^M
displaced: restored Thread 12031 0x8574^M
displaced: PC is apparently 00008576 after SVC step (within scratch space)^M
displaced: writing pc b6ead9a8 <----- WRONG ADDRESS
GDB writes the wrong address back to pc because GDB thinks the
instruction size is 4, which isn't true for thumb instruction.
This patch is to replace 4 with dsc->insn_size.
gdb:
2015-04-15 Yao Qi <yao.qi@linaro.org>
* arm-linux-tdep.c (arm_linux_cleanup_svc): Use
dsc->insn_size instead of 4.
I see many fails in gdb.dwarf2/dynarr-ptr.exp on arm-linux target,
started from this
print foo.three_ptr.all^M
Cannot access memory at address 0x107c8^M
(gdb) FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr.all
print foo.three_ptr.all(1)^M
Cannot access memory at address 0x107c8
It turns out that ":$ptr_size" is used incorrectly.
array_ptr_label: DW_TAG_pointer_type {
{DW_AT_byte_size :$ptr_size }
^^^^^^^^^^
{DW_AT_type :$array_label}
}
Since the FORM isn't given, and it starts with the ":", it is regarded
as a label reference by dwarf assembler. The generated asm file on
x86_64 is
.uleb128 6 /* Abbrev (DW_TAG_pointer_type) */
.4byte 8 - .Lcu1_begin <----- WRONG
.4byte .Llabel2 - .Lcu1_begin
Looks .Lcu1_begin is 0 on x86_64 and that is why this test passes on
x86_64. On arm, .Lcu1_begin is an address somewhere, and the value
of DW_AT_byte_size is a very large number, so memory read request
of such large length failed.
This patch is to remove ":" and set the form explicitly. The generated
asm file on x86_64 becomes
.uleb128 6 /* Abbrev (DW_TAG_pointer_type) */
.byte 8
.4byte .Llabel2 - .Lcu1_begin
gdb/testsuite:
2015-04-15 Yao Qi <yao.qi@linaro.org>
* gdb.dwarf2/dynarr-ptr.exp (assemble): Use $ptr_size instead
of ":$ptr_size" and set its form explicitly.
I see the following two timeout fails on pandaboard (arm-linux target),
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: continue until exit (timeout)
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: continue until exit (timeout)
In this test, more than one watchpoint is used, so the following
watchpoint requests fall back to software watchpoint, so that GDB
will single step all the way and it is very slow.
This patch is to copy the fix from
[PATCH] GDB/testsuite: Correct gdb.base/watchpoint-solib.exp timeout tweak
https://sourceware.org/ml/gdb-patches/2014-07/msg00716.html
I find the left-over of this patch review is to factor out code into
a procedure, so I do that in this patch.
Re-run tests watch-bitfields.exp, watchpoint-solib.exp, sigall-reverse.exp,
and until-precsave.exp on pandaboard, no regression.
gdb/testsuite:
2015-04-15 Pedro Alves <palves@redhat.com>
Yao Qi <yao.qi@linaro.org>
* gdb.base/watch-bitfields.exp (test_watch_location): Increase
timeout by factor of 4.
(test_regular_watch): Likewise.
* gdb.base/watchpoint-solib.exp: Use with_timeout_factor.
* gdb.reverse/sigall-reverse.exp: Likewise.
* gdb.reverse/until-precsave.exp: Likewise.
* lib/gdb.exp (with_timeout_factor): New proc.
(gdb_expect): Move some code to ...
(get_largest_timeout): ... here. New procedure.
Reinstate test message and replace hardcoded test command with a variable.
gdb/testsuite/ChangeLog:
2015-04-14 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/bp-permanent.exp (test): Reinstate correct test message.
GDB has five places where it pretends to stat for bfd_openr_iovec.
Four of these only set the incoming buffer's st_size, leaving the
other fields unchanged, which is to say very likely populated with
random values from the stack. remote_bfd_iovec_stat was fixed in
0a93529c56714b1da3d7106d3e0300764f8bb81c; this commit fixes the
other four.
gdb/ChangeLog:
* jit.c (mem_bfd_iovec_stat): Zero supplied buffer.
* minidebug.c (lzma_stat): Likewise.
* solib-spu.c (spu_bfd_iovec_stat): Likewise.
* spu-linux-nat.c (spu_bfd_iovec_stat): Likewise.
Recognize NT_X86_XSTATE notes in FreeBSD process cores. Recent
FreeBSD versions include a note containing the XSAVE state for each
thread in the process when XSAVE is in use. The note stores a copy of
the current XSAVE mask in a reserved section of the machine-defined
XSAVE state at the same offset as Linux's NT_X86_XSTATE note.
For native processes, use the PT_GETXSTATE_INFO ptrace request to
determine if XSAVE is enabled, and if so the active XSAVE state mask
(that is, the value of %xcr0 for the target process) as well as the
size of XSAVE state area. Use the PT_GETXSTATE and PT_SETXSTATE requests
to fetch and store the XSAVE state, respectively, in the BSD x86
native targets.
In addition, the FreeBSD amd64 and i386 native targets now include
"read_description" target methods to determine the correct x86 target
description for the current XSAVE mask. On FreeBSD amd64 this also
properly returns an i386 target description for 32-bit binaries which
allows the 64-bit GDB to run 32-bit binaries.
Note that the ptrace changes are in the BSD native targets, not the
FreeBSD-specific native targets since that is where the other ptrace
register accesses occur. Of the other BSDs, NetBSD and DragonFly use
XSAVE in the kernel but do not currently export the extended state via
ptrace(2). OpenBSD does not currently support XSAVE.
bfd/ChangeLog:
* elf.c (elfcore_grok_note): Recognize NT_X86_XSTATE on
FreeBSD.
(elfcore_write_xstatereg): Use correct note name on FreeBSD.
gdb/ChangeLog:
* amd64-tdep.c (amd64_target_description): New function.
* amd64-tdep.h: Export amd64_target_description and tdesc_amd64.
* amd64bsd-nat.c [PT_GETXSTATE_INFO]: New variable amd64bsd_xsave_len.
(amd64bsd_fetch_inferior_registers) [PT_GETXSTATE_INFO]: Handle
x86 extended save area.
(amd64bsd_store_inferior_registers) [PT_GETXSTATE_INFO]: Likewise.
* amd64bsd-nat.h: Export amd64bsd_xsave_len.
* amd64fbsd-nat.c (amd64fbsd_read_description): New function.
(_initialize_amd64fbsd_nat): Set "to_read_description" to
"amd64fbsd_read_description".
* amd64fbsd-tdep.c (amd64fbsd_core_read_description): New function.
(amd64fbsd_supply_xstateregset): New function.
(amd64fbsd_collect_xstateregset): New function.
Add "amd64fbsd_xstateregset".
(amd64fbsd_iterate_over_regset_sections): New function.
(amd64fbsd_init_abi): Set "xsave_xcr0_offset" to
"I386_FBSD_XSAVE_XCR0_OFFSET".
Add "iterate_over_regset_sections" gdbarch method.
Add "core_read_description" gdbarch method.
* i386-tdep.c (i386_target_description): New function.
* i386-tdep.h: Export i386_target_description and tdesc_i386.
* i386bsd-nat.c [PT_GETXSTATE_INFO]: New variable i386bsd_xsave_len.
(i386bsd_fetch_inferior_registers) [PT_GETXSTATE_INFO]: Handle
x86 extended save area.
(i386bsd_store_inferior_registers) [PT_GETXSTATE_INFO]: Likewise.
* i386bsd-nat.h: Export i386bsd_xsave_len.
* i386fbsd-nat.c (i386fbsd_read_description): New function.
(_initialize_i386fbsd_nat): Set "to_read_description" to
"i386fbsd_read_description".
* i386fbsd-tdep.c (i386fbsd_core_read_xcr0): New function.
(i386fbsd_core_read_description): New function.
(i386fbsd_supply_xstateregset): New function.
(i386fbsd_collect_xstateregset): New function.
Add "i386fbsd_xstateregset".
(i386fbsd_iterate_over_regset_sections): New function.
(i386fbsd4_init_abi): Set "xsave_xcr0_offset" to
"I386_FBSD_XSAVE_XCR0_OFFSET".
Add "iterate_over_regset_sections" gdbarch method.
Add "core_read_description" gdbarch method.
* i386fbsd-tdep.h: New file.
This testcase does not work as expected in QEMU (aarch64 QEMU in my case). It
fails when trying to manually write the breakpoint instruction to a certain
PC address.
(gdb) p /x addr_bp[0] = buffer[0]^M
Cannot access memory at address 0x400834^M
(gdb) PASS: gdb.base/bp-permanent.exp: always_inserted=off, sw_watchpoint=0: setup: p /x addr_bp[0] = buffer[0]
p /x addr_bp[1] = buffer[1]^M
Cannot access memory at address 0x400835^M
(gdb) PASS: gdb.base/bp-permanent.exp: always_inserted=off, sw_watchpoint=0: setup: p /x addr_bp[1] = buffer[1]
p /x addr_bp[2] = buffer[2]^M
Cannot access memory at address 0x400836^M
(gdb) PASS: gdb.base/bp-permanent.exp: always_inserted=off, sw_watchpoint=0: setup: p /x addr_bp[2] = buffer[2]
p /x addr_bp[3] = buffer[3]^M
Cannot access memory at address 0x400837^M
(gdb) PASS: gdb.base/bp-permanent.exp: always_inserted=off, sw_watchpoint=0: setup: p /x addr_bp[3] = buffer[3]
The following patch prevents a number of failures by detecting this and bailing out in case the target has such a restriction. Writing to .text from within the program isn't any better. It just leads to a SIGSEGV.
Before the patch:
=== gdb Summary ===
After the patch:
=== gdb Summary ===
gdb/testsuite/ChangeLog:
2015-04-13 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/bp-permanent.exp (test): Handle the case of being unable
to write to the .text section.
This testcase seems to assume the target is running Linux, so bare metal,
simulators and other debugging stubs running different OS' will have a
hard time executing some of the commands the testcase issues.
Even restricting the testcase to Linux systems (which the patch below does),
there are still problems with, say, QEMU not providing PID information when
"info inferior" is issued. As a consequence, the subsequent tests will either
fail or will not make much sense.
The attached patch checks if PID information is available. If not, it just
bails out and avoids running into a number of failures.
gdb/testsuite/ChangeLog:
2015-04-13 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/coredump-filter.exp: Restrict test to Linux systems only.
Handle the case of targets that do not provide PID information.
I see the error when I run gdb-sigterm.exp with native-gdbserver
on x86_64-linux.
infrun: prepare_to_wait^M
Cannot execute this command while the target is running.^M
Use the "interrupt" command to stop the target^M
and then try again.^M
gdb.base/gdb-sigterm.exp: expect eof #0: got eof
gdb.base/gdb-sigterm.exp: expect eof #0: stepped 12 times
ERROR OCCURED: : spawn id exp8 not open
while executing
"expect {
-i exp8 -timeout 10
-re "$gdb_prompt $" {
exp_continue
}
-i "$server_spawn_id" eof {
wait -i $expect_out(spawn_id)
unse..."
("uplevel" body line 1)
invoked from within
In gdb-sigterm.exp, SIGTERM is sent to GDB and it exits. However,
Dejagnu or tcl doesn't know this.
This patch is to catch the exception, but error messages are still
shown in the console and gdb.log. In order to avoid this, we also
replace gdb_expect with expect.
gdb/testsuite:
2015-04-13 Yao Qi <yao.qi@linaro.org>
* lib/gdbserver-support.exp (gdb_exit): Catch exception
and use expect instead of gdb_expect.
This commit renames the global array variable "addr" to an unique name
"coredump_var_addr" in the test gdb.base/coredump-filter.exp. This is
needed because global arrays can have name conflicts between tests.
For example, this specific test was conflicting with dmsym.exp,
causing errors like:
ERROR: tcl error sourcing ../../../../../binutils-gdb/gdb/testsuite/gdb.base/dmsym.exp.
ERROR: can't set "addr": variable is array
while executing
"set addr "0x\[0-9a-zA-Z\]+""
(file "../../../../../binutils-gdb/gdb/testsuite/gdb.base/dmsym.exp" line 45)
invoked from within
"source ../../../../../binutils-gdb/gdb/testsuite/gdb.base/dmsym.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source ../../../../../binutils-gdb/gdb/testsuite/gdb.base/dmsym.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
This problem was reported by Yao Qi at:
<https://sourceware.org/ml/gdb-patches/2015-04/msg00373.html>
Message-Id: <1428666671-12926-1-git-send-email-qiyaoltc@gmail.com>
gdb/testsuite/ChangeLog:
2015-04-13 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/coredump-filter.exp: Rename variable "addr" to
"coredump_var_addr" to avoid naming conflict with other testcases.
Pedro Alves:
The commands that enables aren't even documented in the manual.
Judging from that, I assume that only wdb users would ever really
be using the --xdb switch.
I think it's time to drop "support" for the --xdb switch too. I
looked through the commands that that exposes, the only that looked
potentially interesting was "go", but then it's just an alias
for "tbreak+jump", which can easily be done with "define go...end".
I'd rather free up the "go" name for something potentially
more interesting (either run control, or maybe even unrelated,
e.g., for golang).
gdb/ChangeLog
2015-04-11 Jan Kratochvil <jan.kratochvil@redhat.com>
* NEWS (Changes since GDB 7.9): Add removed -xdb.
* breakpoint.c (command_line_is_silent): Remove xdb_commands
conditional.
(_initialize_breakpoint): Remove xdb_commands for bc, ab, sb, db, ba
and lb.
* cli/cli-cmds.c (_initialize_cli_cmds): Remove xdb_commands for v and
va.
* cli/cli-decode.c (find_command_name_length): Remove xdb_commands
conditional.
* defs.h (xdb_commands): Remove declaration.
* f-valprint.c (_initialize_f_valprint): Remove xdb_commands for lc.
* guile/scm-cmd.c (command_classes): Remove xdb from comment.
* infcmd.c (run_no_args_command, go_command): Remove.
(_initialize_infcmd): Remove xdb_commands for S, go, g, R and lr.
* infrun.c (xdb_handle_command): Remove.
(_initialize_infrun): Remove xdb_commands for lz and z.
* main.c (xdb_commands): Remove variable.
(captured_main): Remove "xdb" from long_options.
(print_gdb_help): Remove --xdb from help.
* python/py-cmd.c (gdbpy_initialize_commands): Remove xdb from comment.
* source.c (_initialize_source): Remove xdb_commands for D, ld, / and ?.
* stack.c (backtrace_full_command, args_plus_locals_info)
(current_frame_command): Remove.
(_initialize_stack): Remove xdb_commands for t, T and l.
* symtab.c (_initialize_symtab): Remove xdb_commands for lf and lg.
* thread.c (_initialize_thread): Remove xdb_commands condition.
* tui/tui-layout.c (tui_toggle_layout_command)
(tui_toggle_split_layout_command, tui_handle_xdb_layout): Remove.
(_initialize_tui_layout): Remove xdb_commands for td and ts.
* tui/tui-regs.c (tui_scroll_regs_forward_command)
(tui_scroll_regs_backward_command): Remove.
(_initialize_tui_regs): Remove xdb_commands for fr, gr, sr, +r and -r.
* tui/tui-win.c (tui_xdb_set_win_height_command): Remove.
(_initialize_tui_win): Remove xdb_commands for U and w.
* utils.c (pagination_on_command, pagination_off_command): Remove.
(initialize_utils): Remove xdb_commands for am and sm.
gdb/doc/ChangeLog
2015-04-11 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.texinfo (Mode Options): Remove -xdb.
gdb/testsuite/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp: Use
gdb_test_sequence and gdb_assert.
Diffing test results, I noticed:
-PASS: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: next: b *0x0000000000400811 thread 1
+PASS: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: next: b *0x00000000004007d1 thread 1
gdb/testsuite/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
* gdb.threads/step-over-trips-on-watchpoint.exp (do_test): Use
test messages that don't include the breakpoint address.
Hi,
ARM linux kernel has some requirements on the address/length setting
for HW breakpoints/watchpoints, but watchpoint-reuse-slot.exp doesn't
consider them and sets HW points on various addresses. Many fails
are causes as a result:
stepi^M
Warning:^M
Could not insert hardware watchpoint 20.^M
Could not insert hardware breakpoints:^M
You may have requested too many hardware breakpoints/watchpoints.^M
^M
(gdb) FAIL: gdb.base/watchpoint-reuse-slot.exp: always-inserted off: watch x watch: : width 2, iter 2: base + 1: stepi advanced
watch *(buf.byte + 2 + 1)@2^M
Hardware watchpoint 388: *(buf.byte + 2 + 1)@2^M
Warning:^M
Could not insert hardware watchpoint 388.^M
Could not insert hardware breakpoints:^M
You may have requested too many hardware breakpoints/watchpoints.^M
^M
(gdb) FAIL: gdb.base/watchpoint-reuse-slot.exp: always-inserted on: watch x watch: : width 2, iter 2: base + 1: watch *(buf.byte + 2 + 1)@2
This patch is to reflect kernel requirements in watchpoint-reuse-slot.exp
in order to skip some tests.
gdb/testsuite:
2015-04-10 Yao Qi <yao.qi@linaro.org>
* gdb.base/watchpoint-reuse-slot.exp (valid_addr_p): Return
false for some offset and width combinations which aren't
supported by linux kernel.
PPC64 currently fails this test like:
FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: no thread-specific bp: step: step
FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: no thread-specific bp: next: next
FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: no thread-specific bp: continue: continue (the program exited)
FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: step: step
FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: next: next
FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: continue: continue (the program exited)
The problem is that PPC is a non-continuable watchpoints architecture
and the displaced stepping code isn't coping with that correctly. On
such targets/architectures, a watchpoint traps _before_ the
instruction executes/completes. On a watchpoint trap, the PC points
at the instruction that triggers the watchpoint (side effects haven't
happened yet). In order to move past the watchpoint, GDB needs to
remove the watchpoint, single-step, and reinsert the watchpoint, just
like when stepping past a breakpoint.
The trouble is that if GDB is stepping over a breakpoint with
displaced stepping, and the instruction under the breakpoint triggers
a watchpoint, we get the watchpoint SIGTRAP, expecting a finished
(hard or software) step trap. Even though the thread's PC hasn't
advanced yet (must remove watchpoint for that), since we get a
SIGTRAP, displaced_step_fixup thinks the single-step finished
successfuly anyway, and calls gdbarch_displaced_step_fixup, which then
adjusts the thread's registers incorrectly.
The fix is to cancel the displaced step if we trip on a watchpoint.
handle_inferior_event then processes the watchpoint event, and starts
a new step-over, here:
...
/* At this point, we are stopped at an instruction which has
attempted to write to a piece of memory under control of
a watchpoint. The instruction hasn't actually executed
yet. If we were to evaluate the watchpoint expression
now, we would get the old value, and therefore no change
would seem to have occurred.
...
ecs->event_thread->stepping_over_watchpoint = 1;
keep_going (ecs);
return;
...
but this time, since we have a watchpoint to step over, watchpoints
are removed from the target, so the step-over succeeds.
The keep_going/resume changes are necessary because if we're stepping
over a watchpoint, we need to remove it from the target - displaced
stepping doesn't help, the copy of the instruction in the scratch pad
reads/writes to the same addresses, thus triggers the watchpoint
too... So without those changes we keep triggering the watchpoint
forever, never making progress. With non-stop that means we'll need
to pause all threads momentarily, which we can't today. We could
avoid that by removing the watchpoint _only_ from the thread that is
moving past the watchpoint, but GDB is not prepared for that today
either. For remote targets, that would need new packets, so good to
be able to step over it in-line as fallback anyway.
gdb/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
* infrun.c (displaced_step_fixup): Switch to the event ptid
earlier. If the thread stopped for a watchpoint and the
target/arch has non-continuable watchpoints, cancel the displaced
step.
(resume): Don't start a displaced step if in-line step-over info
is valid.
These tests exercise the infrun.c:proceed code that needs to know to
start new step overs (along with switch_back_to_stepped_thread, etc.).
That code is tricky to get right in the multitude of possible
combinations (at least):
(native | remote)
X (all-stop | all-stop-but-target-always-in-non-stop)
X (displaced-stepping | in-line step-over).
The first two above are properties of the target, but the different
step-over-breakpoint methods should work with any target that supports
them. This patch makes sure we always test both methods on all
targets.
Tested on x86-64 Fedora 20.
gdb/testsuite/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
* gdb.threads/step-over-lands-on-breakpoint.exp (do_test): New
procedure, factored out from ...
(top level): ... here. Add "set displaced-stepping" testing axis.
* gdb.threads/step-over-trips-on-watchpoint.exp (do_test): New
parameter "displaced". Use it.
(top level): Use foreach and add "set displaced-stepping" testing
axis.
This test is currently failing like this on (at least) PPC64 and s390x:
FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: step
FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: next: next
FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: with thread-specific bp: step: step
FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: with thread-specific bp: next: next
gdb.log:
(gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: set scheduler-locking off
step
wait_threads () at ../../../src/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c:49
49 return 1; /* in wait_threads */
(gdb) FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: step
The problem is that the test assumes that both the "watch_me = 1;" and
the "other = 1;" lines compile to a single instruction each, which
happens to be true on x86, but no necessarily true everywhere else.
The result is that the test doesn't really test what it wants to test.
Fix it by looking for the instruction that triggers the watchpoint.
gdb/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
* gdb.threads/step-over-trips-on-watchpoint.c (child_function):
Remove comment.
* gdb.threads/step-over-trips-on-watchpoint.exp (do_test): Find
both the address of the instruction that triggers the watchpoint
and the address of the instruction immediately after, and use
those addresses for the test. Fix comment.
TL;DR:
When stepping over a breakpoint with displaced stepping, the core must
be notified of all signals, otherwise the displaced step fixup code
confuses a breakpoint trap in the signal handler for the expected trap
indicating the displaced instruction was single-stepped
normally/successfully.
Detailed version:
Running sigstep.exp with displaced stepping on, against my x86
software single-step branch, I got:
FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step
FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next
FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue
Turning on debug logs, we see:
(gdb) step
infrun: clear_proceed_status_thread (process 32147)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842
displaced: stepping process 32147 now
displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0
displaced: %rip-relative addressing used.
displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c
displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00
displaced: displaced pc to 0x400622
displaced: run 0x400622: c7 81 1c 08
LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147
LLR: PTRACE_CONT process 32147, 0 (resume event thread)
linux_nat_wait: [process -1], [TARGET_WNOHANG]
LLW: enter
LNW: waitpid(-1, ...) returned 32147, No child processes
LLW: waitpid 32147 received Alarm clock (stopped)
LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle')
LNW: waitpid(-1, ...) returned 0, No child processes
LLW: exit (ignore)
sigchld
infrun: target_wait (-1.0.0, status) =
infrun: -1.0.0 [process -1],
infrun: status->kind = ignore
infrun: TARGET_WAITKIND_IGNORE
infrun: prepare_to_wait
linux_nat_wait: [process -1], [TARGET_WNOHANG]
LLW: enter
LNW: waitpid(-1, ...) returned 32147, No child processes
LLW: waitpid 32147 received Trace/breakpoint trap (stopped)
CSBB: process 32147 stopped by software breakpoint
LNW: waitpid(-1, ...) returned 0, No child processes
LLW: trap ptid is process 32147.
LLW: exit
infrun: target_wait (-1.0.0, status) =
infrun: 32147.32147.0 [process 32147],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
displaced: restored process 32147 0x400622
displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ...
displaced: restoring reg 2 to 0x3615eafd37
displaced: relocated %rip from 0x400717 to 0x400937
infrun: stop_pc = 0x400937
infrun: delayed software breakpoint trap, ignoring
infrun: no line number info
infrun: stop_waiting
0x0000000000400937 in __dso_handle ()
1: x/i $pc
=> 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1
(gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step
What should have happened is that the breakpoint hit in the signal
handler should have been presented to the user. But note that
"preempt 'handle'" -- what happened instead is that
displaced_step_fixup confused the breakpoint in the signal handler for
the expected SIGTRAP indicating the displaced instruction was
single-stepped normally/successfully.
This should be affecting all software single-step targets in the same
way.
The fix is to make sure the core sees all signals when displaced
stepping, just like we already must see all signals when doing an
stepping over a breakpoint in-line. We now get:
infrun: target_wait (-1.0.0, status) =
infrun: 570.570.0 [process 570],
infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM
infrun: TARGET_WAITKIND_STOPPED
displaced: restored process 570 0x400622
infrun: stop_pc = 0x400842
infrun: random signal (GDB_SIGNAL_ALRM)
infrun: signal arrived while stepping over breakpoint
infrun: inserting step-resume breakpoint at 0x400842
infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842
LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570
LLR: PTRACE_CONT process 570, Alarm clock (resume event thread)
infrun: prepare_to_wait
linux_nat_wait: [process -1], [TARGET_WNOHANG]
LLW: enter
LNW: waitpid(-1, ...) returned 0, No child processes
LLW: exit (ignore)
infrun: target_wait (-1.0.0, status) =
infrun: -1.0.0 [process -1],
infrun: status->kind = ignore
sigchld
infrun: TARGET_WAITKIND_IGNORE
infrun: prepare_to_wait
linux_nat_wait: [process -1], [TARGET_WNOHANG]
LLW: enter
LNW: waitpid(-1, ...) returned 570, No child processes
LLW: waitpid 570 received Trace/breakpoint trap (stopped)
CSBB: process 570 stopped by software breakpoint
LNW: waitpid(-1, ...) returned 0, No child processes
LLW: trap ptid is process 570.
LLW: exit
infrun: target_wait (-1.0.0, status) =
infrun: 570.570.0 [process 570],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400717
infrun: BPSTAT_WHAT_STOP_NOISY
infrun: stop_waiting
Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35
35 done = 1;
Hardware single-step targets already behave this way, because the
Linux backends (both native and gdbserver) always report signals to
the core if the thread was single-stepping.
As mentioned in the new comment in do_target_resume, we can't fix this
by instead making the displaced_step_fixup phase skip fixing up the PC
if the single step stopped somewhere we didn't expect. Here's what
the backtrace would look like if we did that:
Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35
35 done = 1;
1: x/i $pc
=> 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done>
(gdb) bt
#0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35
#1 <signal handler called>
#2 0x0000000000400622 in _start ()
(gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace
gdb/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
* infrun.c (displaced_step_in_progress): New function.
(do_target_resume): Advise target to report all signals if
displaced stepping.
gdb/testsuite/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
* gdb.base/sigstep.exp (breakpoint_to_handler)
(breakpoint_to_handler_entry): New parameter 'displaced'. Use it.
Test "backtrace" in handler.
(breakpoint_over_handler): New parameter 'displaced'. Use it.
(top level): Add new "displaced" test axis to
breakpoint_to_handler, breakpoint_to_handler_entry and
breakpoint_over_handler.
The problem is that with hardware step targets and displaced stepping,
"signal FOO" when stopped at a breakpoint steps the breakpoint
instruction at the same time it delivers a signal. This results in
tp->stepped_breakpoint set, but no step-resume breakpoint set. When
the next stop event arrives, GDB crashes. Irrespective of whether we
should do something more/different to step past the breakpoint in this
scenario (e.g., PR 18225), it's just wrong to assume there'll be a
step-resume breakpoint set (and was not the original intention).
gdb/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
PR gdb/18216
* infrun.c (process_event_stop_test): Don't assume a step-resume
is set if tp->stepped_breakpoint is true.
gdb/testsuite/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
PR gdb/18216
* gdb.threads/multiple-step-overs.exp: Remove expected eof.
Recent patch series "V2 All-stop on top of non-stop" causes a SIGSEGV
in the test case,
> -PASS: gdb.base/info-shared.exp: continue to breakpoint: library function #4
> +FAIL: gdb.base/info-shared.exp: continue to breakpoint: library function #4
>
> continue^M
> Continuing.^M
> ^M
> Program received signal SIGSEGV, Segmentation fault.^M
> 0x40021564 in ?? () gdb/testsuite/gdb.base/info-shared-solib1.so^M
> (gdb) FAIL: gdb.base/info-shared.exp: continue to breakpoint: library function #4
and an ARM displaced stepping bug is exposed. It can be reproduced by
the modified gdb.arch/arm-disp-step.exp as below,
continue^M
Continuing.^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0xa713cfcc in ?? ()^M
(gdb) FAIL: gdb.arch/arm-disp-step.exp: continue to breakpoint: continue to test_add_rn_pc_end
This patch is to fix it.
gdb:
2015-04-10 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (install_alu_reg): Update comment.
(thumb_copy_alu_reg): Remove local variable rn. Update
debugging message. Use r2 instead of r1 in the modified
instruction.
gdb/testsuite:
2015-04-10 Yao Qi <yao.qi@linaro.org>
* gdb.arch/arm-disp-step.S (main): Call test_add_rn_pc.
(test_add_rn_pc): New function.
* gdb.arch/arm-disp-step.exp (test_add_rn_pc): New proc.
(top level): Invoke test_add_rn_pc.
Running break-interp.exp with the target always in non-stop mode trips
on PR13858, as enabling non-stop also enables displaced stepping.
The problem is that when GDB doesn't know where the entry point is, it
doesn't know where to put the displaced stepping scratch pad. The
test added by this commit exercises this. Without the fix, we get:
(gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=on: break *$pc
set displaced-stepping on
(gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=on: set displaced-stepping on
stepi
0x00000000004005be in ?? ()
Entry point address is not known.
(gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=on: stepi
p /x $pc
$2 = 0x4005be
(gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=on: get after PC
FAIL: gdb.base/step-over-no-symbols.exp: displaced=on: advanced
The fix switches all GNU/Linux ports to get the entry point from
AT_ENTRY in the target auxiliary vector instead of from symbols. This
is currently only done by PPC when Cell debugging is enabled, but I
think all archs should be able to do the same. Note that
ppc_linux_displaced_step_location cached the result, I'm guessing to
avoid constantly re-fetching the auxv out of remote targets, but
that's no longer necessary nowadays, as the auxv blob is itself cached
in the inferior object. The ppc_linux_entry_point_addr global is
obviously bad for multi-process too nowadays.
Tested on x86-64 (-m64/-m32), PPC64 (-m64/-m32) and S/390 GNU/Linux.
Yao tested the new test on ARM as well.
gdb/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
PR gdb/13858
* amd64-linux-tdep.c (amd64_linux_init_abi_common): Install
linux_displaced_step_location as gdbarch_displaced_step_location
hook.
* arm-linux-tdep.c (arm_linux_init_abi): Likewise.
* i386-linux-tdep.c (i386_linux_init_abi): Likewise.
* linux-tdep.c (linux_displaced_step_location): New function,
based on ppc_linux_displaced_step_location.
* linux-tdep.h (linux_displaced_step_location): New declaration.
* ppc-linux-tdep.c (ppc_linux_entry_point_addr): Delete.
(ppc_linux_inferior_created, ppc_linux_displaced_step_location):
Delete.
(ppc_linux_init_abi): Install linux_displaced_step_location as
gdbarch_displaced_step_location hook, even without Cell/B.E..
(_initialize_ppc_linux_tdep): Don't install
ppc_linux_inferior_created as inferior_created observer.
* s390-linux-tdep.c (s390_gdbarch_init): Install
linux_displaced_step_location as gdbarch_displaced_step_location
hook.
gdb/testsuite/
2015-04-10 Pedro Alves <palves@redhat.com>
PR gdb/13858
* gdb.base/step-over-no-symbols.exp: New file.
gdb/doc/ChangeLog
2015-04-10 Jan Kratochvil <jan.kratochvil@redhat.com>
Eli Zaretskii <eliz@gnu.org>
* gdb.texinfo (Compiling and Injecting Code): Describe set debug
compile, show debug compile. New subsection Compilation options for
the compile command. New subsection Compiler search for the compile
command.
This commit introduces a new shared function to replace three
identical functions in various places in the codebase.
gdb/ChangeLog:
* common/common-remote-fileio.h (remote_fileio_to_fio_error):
New declaration.
* common/common-remote-fileio.c (remote_fileio_to_fio_error):
New function, factored out the named functions below.
* inf-child.c (gdb/fileio.h): Remove include.
(common-remote-fileio.h): New include.
(inf_child_errno_to_fileio_error): Remove function. Update
all callers to use remote_fileio_to_fio_error.
* remote-fileio.c (remote_fileio_errno_to_target): Likewise.
gdb/gdbserver/ChangeLog:
* hostio-errno.c (errno_to_fileio_error): Remove function.
Update caller to use remote_fileio_to_fio_error.
gdb/ChangeLog:
2015-04-09 Pedro Alves <palves@redhat.com>
* gnulib/update-gnulib.sh (aclocal version check): Filter out
"called too early to check prototype".
Hi,
I see the following error on arm linux gdbserver,
continue^M
Continuing.^M
../../../binutils-gdb/gdb/gdbserver/linux-arm-low.c:458: A problem internal to GDBserver has been detected.^M
raw_bkpt_type_to_arm_hwbp_type: unhandled raw type^M
Remote connection closed^M
(gdb) FAIL: gdb.base/cond-eval-mode.exp: hbreak: continue
After we make GDBserver handling Zx/zx packet idempotent,
[PATCH 3/3] [GDBserver] Make Zx/zx packet handling idempotent.
https://sourceware.org/ml/gdb-patches/2014-04/msg00480.html
> Now removal/insertion of all kinds of breakpoints/watchpoints, either
> internal, or from GDB, always go through the target methods.
GDBserver handles all kinds of breakpoints/watchpoints through target
methods. However, some target backends, such as arm, don't support Z0
packet but need software breakpoint to do breakpoint stepping over in
linux-low.c:start_step_over,
if (can_hardware_single_step ())
{
step = 1;
}
else
{
CORE_ADDR raddr = (*the_low_target.breakpoint_reinsert_addr) ();
set_reinsert_breakpoint (raddr);
step = 0;
}
a software breakpoint is requested to the backend, and the error is
triggered. This problem should affect targets having
breakpoint_reinsert_addr hooked.
Instead of handling memory breakpoint in these affected linux backend,
this patch handles memory breakpoint in linux_{insert,remove}_point,
that, if memory breakpoint is requested, call
{insert,remove}_memory_breakpoint respectively. Then, it becomes
unnecessary to handle memory breakpoint for linux x86 backend, so
this patch removes the code there.
This patch is tested with GDBserver on x86_64-linux and arm-linux
(-marm, -mthumb). Note that there are still some fails in
gdb.base/cond-eval-mode.exp with -mthumb, because GDBserver doesn't
know how to select the correct breakpoint instruction according to
the arm-or-thumb-mode of requested address. This is a separate
issue, anyway.
gdb/gdbserver:
2015-04-09 Yao Qi <yao.qi@linaro.org>
* linux-low.c (linux_insert_point): Call
insert_memory_breakpoint if TYPE is raw_bkpt_type_sw.
(linux_remove_point): Call remove_memory_breakpoint if type is
raw_bkpt_type_sw.
* linux-x86-low.c (x86_insert_point): Don't call
insert_memory_breakpoint.
(x86_remove_point): Don't call remove_memory_breakpoint.
This patch is related to PR python/16699, and is an improvement over the
patch posted here:
<https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html>
Keith noticed that, when using the "complete" command on GDB to complete
a Python command, some strange things could happen. In order to
understand what can go wrong, I need to explain how the Python
completion mechanism works.
When the user requests a completion of a Python command by using TAB,
GDB will first try to determine the right set of "brkchars" that will be
used when doing the completion. This is done by actually calling the
"complete" method of the Python class. Then, when we already know the
"brkchars" that will be used, we call the "complete" method again, for
the same values.
If you read the thread mentioned above, you will see that one of the
design decisions was to make the "cmdpy_completer_helper" (which is the
function the does the actual calling of the "complete" method) cache the
first result of the completion, since this result will be used in the
second call, to do the actual completion.
The problem is that the "complete" command does not process the
brkchars, and the current Python completion mechanism (improved by the
patch mentioned above) relies on GDB trying to determine the brkchars,
and then doing the completion itself. Therefore, when we use the
"complete" command instead of doing a TAB-completion on GDB, there is a
scenario where we can use the invalid cache of a previous Python command
that was completed before. For example:
(gdb) A <TAB>
(gdb) complete B
B value1
B value10
B value2
B value3
B value4
B value5
B value6
B value7
B value8
B value9
(gdb) B <TAB>
comp1 comp2 comp4 comp6 comp8
comp10 comp3 comp5 comp7 comp9
Here, we see that "complete B " gave a different result than "B <TAB>".
The reason for that is because "A <TAB>" was called before, and its
completion results were "value*", so when GDB tried to "complete B " it
wrongly answered with the results for A. The problem here is using a
wrong cache (A's cache) for completing B.
We tried to come up with a solution that would preserve the caching
mechanism, but it wasn't really possible. So I decided to completely
remove the cache, and doing the method calling twice for every
completion. This is not optimal, but I do not think it will impact
users noticeably.
It is worth mentioning another small issue that I found. The code was
doing:
wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL);
which is totally wrong, because using "sizeof" here will lead to always
the same result. So I changed this to use "strlen". The testcase also
catches this problem.
Keith kindly expanded the existing testcase to cover the problem
described above, and everything is passing.
gdb/ChangeLog:
2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* python/py-cmd.c (cmdpy_completer_helper): Adjust function to not
use a caching mechanism. Adjust comments and code to reflect
that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'.
(cmdpy_completer_handle_brkchars): Adjust call to
cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'.
(cmdpy_completer): Likewise.
gdb/testsuite/ChangeLog:
2015-04-08 Keith Seitz <keiths@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New tests for completion.
* gdb.python/py-completion.py (CompleteLimit1): New class.
(CompleteLimit2): Likewise.
(CompleteLimit3): Likewise.
(CompleteLimit4): Likewise.
(CompleteLimit5): Likewise.
(CompleteLimit6): Likewise.
(CompleteLimit7): Likewise.
Both PRs are triggered by the same use case.
PR18214 is about software single-step targets. On those, the 'resume'
code that detects that we're stepping over a breakpoint and delivering
a signal at the same time:
/* Currently, our software single-step implementation leads to different
results than hardware single-stepping in one situation: when stepping
into delivering a signal which has an associated signal handler,
hardware single-step will stop at the first instruction of the handler,
while software single-step will simply skip execution of the handler.
...
Fortunately, we can at least fix this particular issue. We detect
here the case where we are about to deliver a signal while software
single-stepping with breakpoints removed. In this situation, we
revert the decisions to remove all breakpoints and insert single-
step breakpoints, and instead we install a step-resume breakpoint
at the current address, deliver the signal without stepping, and
once we arrive back at the step-resume breakpoint, actually step
over the breakpoint we originally wanted to step over. */
doesn't handle the case of _another_ thread also needing to step over
a breakpoint. Because the other thread is just resumed at the PC
where it had stopped and a breakpoint is still inserted there, the
thread immediately re-traps the same breakpoint. This test exercises
that. On software single-step targets, it fails like this:
KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr3: continue to sigusr1_handler
KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr2: continue to sigusr1_handler
gdb.log (simplified):
(gdb) continue
Continuing.
Breakpoint 4, child_function_2 (arg=0x0) at src/gdb/testsuite/gdb.threads/multiple-step-overs.c:66
66 callme (); /* set breakpoint thread 2 here */
(gdb) thread 3
(gdb) queue-signal SIGUSR1
(gdb) thread 1
[Switching to thread 1 (Thread 0x7ffff7fc1740 (LWP 24824))]
#0 main () at src/gdb/testsuite/gdb.threads/multiple-step-overs.c:106
106 wait_threads (); /* set wait-threads breakpoint here */
(gdb) break sigusr1_handler
Breakpoint 5 at 0x400837: file src/gdb/testsuite/gdb.threads/multiple-step-overs.c, line 31.
(gdb) continue
Continuing.
[Switching to Thread 0x7ffff7fc0700 (LWP 24828)]
Breakpoint 4, child_function_2 (arg=0x0) at src/gdb/testsuite/gdb.threads/multiple-step-overs.c:66
66 callme (); /* set breakpoint thread 2 here */
(gdb) KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr3: continue to sigusr1_handler
For good measure, I made the test try displaced stepping too. And
then I found it crashes GDB on x86-64 (a hardware step target), but
only when displaced stepping... :
KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr1: continue to sigusr1_handler (PRMS: gdb/18216)
KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr2: continue to sigusr1_handler (PRMS: gdb/18216)
KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr3: continue to sigusr1_handler (PRMS: gdb/18216)
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000062a83a in process_event_stop_test (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4964
4964 if (sr_bp->loc->permanent
Setting up the environment for debugging gdb.
Breakpoint 1 at 0x79fcfc: file src/gdb/common/errors.c, line 54.
Breakpoint 2 at 0x50a26c: file src/gdb/cli/cli-cmds.c, line 217.
(top-gdb) p sr_bp
$1 = (struct breakpoint *) 0x0
(top-gdb) bt
#0 0x000000000062a83a in process_event_stop_test (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4964
#1 0x000000000062a1af in handle_signal_stop (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4715
#2 0x0000000000629097 in handle_inferior_event (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4165
#3 0x0000000000627482 in fetch_inferior_event (client_data=0x0) at src/gdb/infrun.c:3298
#4 0x000000000064ad7b in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:56
#5 0x00000000004c375f in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4658
#6 0x0000000000648c47 in handle_file_event (file_ptr=0x2e0eaa0, ready_mask=1) at src/gdb/event-loop.c:658
The all-stop-non-stop series fixes this, but meanwhile, this augments
the multiple-step-overs.exp test to cover this, KFAILed.
gdb/testsuite/ChangeLog:
2015-04-08 Pedro Alves <palves@redhat.com>
PR gdb/18214
PR gdb/18216
* gdb.threads/multiple-step-overs.c (sigusr1_handler): New
function.
(main): Install it as SIGUSR1 handler.
* gdb.threads/multiple-step-overs.exp (setup): Remove 'prefix'
parameter. Always use "setup" as prefix. Toggle "set
displaced-stepping" off/on depending on global. Don't switch to
thread 1 here.
(top level): Add displaced stepping "off/on" test axis. Update
"setup" calls. Wrap each subtest with with_test_prefix. Test
continuing with a queued signal in each thread.
Nowadays, in infrun.c:resume, the setting to 'step' variable is like:
if (use_displaced_stepping (gdbarch)
&& tp->control.trap_expected
&& sig == GDB_SIGNAL_0
&& !current_inferior ()->waiting_for_vfork_done)
{
}
/* Do we need to do it the hard way, w/temp breakpoints? */
else if (step)
step = maybe_software_singlestep (gdbarch, pc); <-- [1]
...
if (execution_direction != EXEC_REVERSE
&& step && breakpoint_inserted_here_p (aspace, pc))
{
...
if (gdbarch_cannot_step_breakpoint (gdbarch)) <-- [2]
step = 0;
}
spu doesn't have displaced stepping and uses software single step,
so 'step' is set to zero in [1], and [2] becomes unreachable as a
result. So don't have to call set_gdbarch_cannot_step_breakpoint
in spu_gdbarch_init.
gdb:
2015-04-08 Yao Qi <yao.qi@linaro.org>
* spu-tdep.c (spu_gdbarch_init): Don't call
set_gdbarch_cannot_step_breakpoint.
The recent actions.exp change to check gdb_run_cmd succeeded caught
further problems. The test now fails like this
with --target_board=native-extended-gdbserver:
FAIL: gdb.trace/actions.exp: Can't run to main
gdb.log shows:
(gdb) run
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.trace/actions
Running the default executable on the remote target failed; try "set remote exec-file"?
(gdb) FAIL: gdb.trace/actions.exp: Can't run to main
The problem is that a gdb_load call is missing.
Grepping around for similar problems in other tests, I found that
infotrace.exp and while-stepping.exp should be likewise affected. And
indeed this is what we get today:
FAIL: gdb.trace/infotrace.exp: tstart
FAIL: gdb.trace/infotrace.exp: continue to end (the program is no longer running)
FAIL: gdb.trace/infotrace.exp: tstop
FAIL: gdb.trace/infotrace.exp: 2.6: info tracepoints (trace buffer usage)
FAIL: gdb.trace/while-stepping.exp: tstart
FAIL: gdb.trace/while-stepping.exp: tstop
FAIL: gdb.trace/while-stepping.exp: tfile: info tracepoints
FAIL: gdb.trace/while-stepping.exp: ctf: info tracepoints
while-stepping.exp even has the same race bug actions.exp had.
After this, {actions,infotrace,while-stepping}.exp all pass cleanly
with the native-extended-gdbserver board.
gdb/testsuite/ChangeLog:
2015-04-08 Pedro Alves <palves@redhat.com>
* gdb.trace/actions.exp: Use gdb_load before gdb_run_cmd.
* gdb.trace/infotrace.exp: Use gdb_load before gdb_run_cmd. Use
gdb_breakpoint instead of gdb_test that doesn't expect anything.
Return early if running to main fails.
* gdb.trace/while-stepping.exp: Likewise.
The gdb.base/interrupt.exp test is important for testing system call
restarting, but because it depends on inferior I/O, it ends up skipped
against gdbserver. This patch adjusts the test to use send_inferior
and $inferior_spawn_id so it works against GDBserver.
gdb/testsuite/ChangeLog:
2015-04-07 Pedro Alves <palves@redhat.com>
* gdb.base/interrupt.exp: Don't skip if $inferior_spawn_id !=
$gdb_spawn_id. Use send_inferior and $inferior_spawn_id to
interact with inferior program.
Some important tests, like gdb.base/interrupt.exp end up skipped
against gdbserver, because they depend on inferior I/O, which
gdbserver doesn't do.
This patch adds a mechanism that makes it possible to make them work.
It adds a new "inferior_spawn_id" global that is the spawn ID used for
I/O interaction with the inferior. By default, for native targets, or
remote targets that can do I/O through GDB (semi-hosting) this will be
the same as the gdb/host spawn ID. Otherwise, the board may set this
to some other spawn ID. When debugging with GDBserver, this will be
set to GDBserver's spawn ID.
Then tests can use send_inferior instead of send_gdb to send input to
the inferior, and use expect's "-i" switch to select which spawn ID to
use for matching input/output. That is, something like this will now
work:
send_inferior "echo me\n"
gdb_test_multiple "continue" "test msg" {
-i "$inferior_spawn_id" -re "echo me\r\necho\r\n" {
...
}
}
Or even:
gdb_test_multiple "continue" "test msg" {
-i "$inferior_spawn_id" -re "hello world" {
...
}
-i "$gdb_spawn_id" -re "error.*$gdb_prompt $" {
...
}
}
Of course, by default, gdb_test_multiple still matches with
$gdb_spawn_id.
gdb/testsuite/ChangeLog:
2015-04-07 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (inferior_spawn_id): New global.
(gdb_test_multiple): Handle "-i". Reset the spawn id to GDB's
spawn id after processing the user code.
(default_gdb_start): Set inferior_spawn_id.
(send_inferior): New procedure.
* lib/gdbserver-support.exp (gdbserver_start): Set
inferior_spawn_id.
(close_gdbserver, gdb_exit): Unset inferior_spawn_id.
I adjusted a test to do 'expect -i $server_spawn_id -re ...', and saw
really strange behavior. Whether that expect would work, depended on
whether GDB would also send output and the same expect matched it too
(on $gdb_spawn_id). I was perplexed until I noticed that
gdbserver_spawn spawns gdbserver and then uses expect_background to
reap gdbserver. That expect_background conflicts/races with any
"expect -i $server_spawn_id" done anywhere else in parallel...
In order to make it possible for tests to read inferior I/O out of
$server_spawn_id, we to get rid of that expect_background. This patch
makes us instead reap gdbserver's spawn id when GDB exits. If GDB is
still around, this gives a chance for gdbserver to exit cleanly. The
current code in gdb_finish uses "kill", but that doesn't work with
extended-remote (gdbserver doesn't exit). We now use "monitor exit"
instead which works in both remote and extended-remote modes.
gdb/testsuite/ChangeLog:
2015-04-07 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_finish): Delete persistent gdbserver handling.
* lib/gdbserver-support.exp (gdbserver_start): Make
$server_spawn_id global.
(gdbserver_start): Don't wait for gdbserver's spawn id with
expect_background.
(close_gdbserver): New procedure.
(gdb_exit): Rename the default version and reimplement.
While teaching gdb_test_multiple to forward "-i" to gdb_expect, I
found that with:
gdb_test_multiple (...) {
-i $some_variable -re "..." {}
}
$some_variable was not getting expanded in the gdb_test_multiple
caller's scope. This is a bug inside gdb_test_multiple. When
processing an argument in passed in user code, it was appending the
original argument literally, instead of appending the uplist'ed
argument.
gdb/testsuite/ChangeLog:
2015-04-07 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_test_multiple): When processing an argument,
append the substituted item, not the original item.
Working on splitting gdb and inferior output handling in this test, I
noticed a race that happens to be masked out today.
The test sends "a\n" to the inferior, and then inferior echoes back
"a\n".
If expect manages to read only the first "a\r\n" into its buffer, then
this matches:
-re "^a\r\n(|a\r\n)$" {
and leaves the second "a\r\n" in output.
Then the next test that processes inferior I/O sends "data\n", and expects:
-re "^(\r\n|)data\r\n(|data\r\n)$"
which fails given the anchor and given "a\r\n" is still in the buffer.
This is masked today because the test relies on inferior I/O being
done on GDB's terminal, and there are tested GDB commands in between,
which consume the "a\r\n" that was left in the output.
We don't support SunOS4 anymore, so just remove the workaround.
gdb/testsuite/ChangeLog
2015-04-07 Pedro Alves <palves@redhat.com>
* gdb.base/interrupt.exp: Don't handle the case of the inferior
output appearing once only.
I saw this on PPC64 once:
not installed on target
(gdb) PASS: gdb.trace/actions.exp: 5.10a: verify teval actions set for two tracepoints
break main
Breakpoint 4 at 0x10000c6c: file ../../../src/gdb/testsuite/gdb.trace/actions.c, line 139.
(gdb) PASS: gdb.trace/actions.exp: break main
run
Starting program: /home/palves/gdb/build/gdb/testsuite/outputs/gdb.trace/actions/actions
tstatus
Breakpoint 4, main (argc=1, argv=0x3fffffffebb8, envp=0x3fffffffebc8) at ../../../src/gdb/testsuite/gdb.trace/actions.c:139
139 begin ();
(gdb) tstatus
Trace can not be run on this target.
(gdb) actions 1
Enter actions for tracepoint 1, one per line.
End with a line saying just "end".
>collect $regs
>end
(gdb) PASS: gdb.trace/actions.exp: set actions for first tracepoint
tstart
You can't do that when your target is `native'
(gdb) FAIL: gdb.trace/actions.exp: tstart
info tracepoints 1
Num Type Disp Enb Address What
1 tracepoint keep y 0x00000000100007c8 in gdb_c_test at ../../../src/gdb/testsuite/gdb.trace/actions.c:74
collect $regs
not installed on target
...
followed by a cascade of FAILs. The "tstatus" was supposed to detect
that this target (native) can't do tracepoints, but, alas, it didn't.
That detection failed because 'gdb_test "break main"' doesn't expect
anything, and then the output was slow enough that 'gdb_test ""
"Breakpoint .*"' matched the output of "break main"...
The fix is to use gdb_breakpoint instead. Also check the result of
gdb_test while at it.
Tested on x86-64 Fedora 20, native and gdbserver.
gdb/testsuite/ChangeLog:
2015-04-07 Pedro Alves <palves@redhat.com>
* gdb.trace/actions.exp: Use gdb_breakpoint instead of gdb_test
that doesn't expect anything. Return early if running to main
fails.
On GNU/Linux, if the running kernel supports clone events, then
linux-thread-db.c defers thread listing to the target beneath:
static void
thread_db_update_thread_list (struct target_ops *ops)
{
...
if (target_has_execution && !thread_db_use_events ())
ops->beneath->to_update_thread_list (ops->beneath);
else
thread_db_update_thread_list_td_ta_thr_iter (ops);
...
}
However, when live debugging, the target beneath, linux-nat.c, does
not implement the to_update_thread_list method. The result is that if
a thread is marked exited (because it can't be deleted right now,
e.g., it was the selected thread), then it won't ever be deleted,
until the process exits or is killed/detached.
A similar thing happens with the remote.c target. Because its
target_update_thread_list implementation skips exited threads when it
walks the current thread list looking for threads that no longer exits
on the target side, using ALL_NON_EXITED_THREADS_SAFE, stale exited
threads are never deleted.
This is not a big deal -- I can't think of any way this might be user
visible, other than gdb's memory growing a tiny bit whenever a thread
gets stuck in exited state. Still, might as well clean things up
properly.
All other targets use prune_threads, so are unaffected.
The fix adds a ALL_THREADS_SAFE macro, that like
ALL_NON_EXITED_THREADS_SAFE, walks the thread list and allows deleting
the iterated thread, and uses that in places that are walking the
thread list in order to delete threads. Actually, after converting
linux-nat.c and remote.c to use this, we find the only other user of
ALL_NON_EXITED_THREADS_SAFE is also walking the list to delete
threads. So we convert that too, and end up deleting
ALL_NON_EXITED_THREADS_SAFE.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/ChangeLog
2015-04-07 Pedro Alves <palves@redhat.com>
* gdbthread.h (ALL_NON_EXITED_THREADS_SAFE): Rename to ...
(ALL_THREADS_SAFE): ... this, and don't skip exited threads.
(delete_exited_threads): New declaration.
* infrun.c (follow_exec): Use ALL_THREADS_SAFE.
* linux-nat.c (linux_nat_update_thread_list): New function.
(linux_nat_add_target): Install it.
* remote.c (remote_update_thread_list): Use ALL_THREADS_SAFE.
* thread.c (prune_threads): Use ALL_THREADS_SAFE.
(delete_exited_threads): New function.
Although not currently possible in practice when we get here,
'resume_ptid' can also be a wildcard throughout this function. It's
clearer to fetch the regcache using the thread's ptid.
gdb/ChangeLog:
2015-04-07 Pedro Alves <pedro@codesourcery.com>
* infrun.c (resume) <displaced stepping debug output>: Get the
leader thread's regcache, not resume_ptid's.
Nowadays, the alarm value is 60, and alarm is generated on some slow
boards. This patch is to pass DejaGNU timeout value to the program,
and move the alarm call before going to infinite loop. If any thread
has activities, the alarm is reset.
gdb/testsuite:
2015-04-07 Yao Qi <yao.qi@linaro.org>
* gdb.threads/non-stop-fair-events.c (SECONDS): New macro.
(child_function): Call alarm.
(main): Move call to alarm into the loop.
* gdb.threads/non-stop-fair-events.exp: Build program with
-DTIMEOUT=$timeout.
The "dest" parameter to fpc_compile/gpc_compile is the name of
compilation destination file, not a board name.
This patch fixes this by using names consistent with
lib/future.exp:gdb_default_target_compile.
gdb/testsuite/ChangeLog:
* lib/pascal.exp (gpc_compile): Rename dest arg to destfile.
Fix dest parameter to board_info.
(fpc_compile): Ditto.
(gdb_compile_pascal): Rename dest arg to destfile.
gdb/ChangeLog:
* symtab.c (hash_symbol_entry): Hash STRUCT_DOMAIN symbols as
VAR_DOMAIN.
(symbol_cache_lookup): Clarify use of bsc_ptr, slot_ptr parameters.
Include symbol domain in debugging output.
Currently building gdb is impossible without an installed termcap or
curses library. But, GDB already has a very minimal termcap in the
tree to handle this situation for Windows -- gdb/stub-termcap.c. This
patch makes that the fallback for all hosts.
Testing this on GNU/Linux (by simply hacking away the termcap/curses
detection in gdb/configure.ac), we trip on:
../readline/libreadline.a(terminal.o): In function `_rl_init_terminal_io':
/home/pedro/gdb/mygit/src/readline/terminal.c:527: undefined reference to `PC'
/home/pedro/gdb/mygit/src/readline/terminal.c:528: undefined reference to `BC'
/home/pedro/gdb/mygit/src/readline/terminal.c:529: undefined reference to `UP'
/home/pedro/gdb/mygit/src/readline/terminal.c:538: undefined reference to `PC'
/home/pedro/gdb/mygit/src/readline/terminal.c:539: undefined reference to `BC'
/home/pedro/gdb/mygit/src/readline/terminal.c:540: undefined reference to `UP'
These are globals that are normally defined by termcap (or ncurses'
termcap emulation).
Now, we could just define replacements in stub-termcap.c, but
readline/terminal.c (at least the copy in our tree) has this:
#if !defined (__linux__) && !defined (NCURSES_VERSION)
# if defined (__EMX__) || defined (NEED_EXTERN_PC)
extern
# endif /* __EMX__ || NEED_EXTERN_PC */
char PC, *BC, *UP;
#endif /* !__linux__ && !NCURSES_VERSION */
which can result in readline defining the globals too. That will
usually work out in C, given that "-fcommon" is usually the default
for C compilers, but that won't work for C++, or C with -fno-common
(link fails with "multiple definition" errors)...
Mirroring those #ifdef conditions in the stub termcap screams
"brittle" to me -- I can see them changing in latter readline
versions.
Work around that by simply using __attribute__((weak)).
Windows/PE/COFF's do support weak, but not on gcc 3.4 based toolchains
(4.8.x does work). Given the file never needed the variables while it
was Windows-only, just continue not defining them there. All other
supported hosts should support this.
gdb/ChangeLog:
2015-04-06 Pedro Alves <palves@redhat.com>
Bernd Edlinger <bernd.edlinger@hotmail.de>
* configure.ac: Remove the mingw32-specific stub-termcap.o
fallback, and instead fallback to the stub termcap on all hosts.
* configure: Regenerate.
* stub-termcap.c [!__MINGW32__] (PC, BC, UP): Define as weak
symbols.
This paramater is no longer useful after the previous commit, so remove
it as a cleanup.
gdb/ChangeLog:
* gdbtypes.c (is_dynamic_type_internal): Remove the unused
"top_level" parameter.
(resolve_dynamic_type_internal): Remove the unused "top_level"
parameter. Update call to is_dynamic_type_internal.
(is_dynamic_type): Update call to is_dynamic_type_internal.
(resolve_dynamic_range): Update call to
resolve_dynamic_type_internal.
(resolve_dynamic_union): Likewise.
(resolve_dynamic_struct): Likewise.
(resolve_dynamic_type): Likewise.
Even when referenced types are dynamic, the corresponding referencing
type should not be considered as dynamic: it's only a pointer. This
prevents reference type for values not in memory to be resolved.
gdb/ChangeLog:
* gdbtypes.c (is_dynamic_type_internal): Remove special handling
of TYPE_CODE_REF types so that they are not considered as
dynamic depending on the referenced type.
(resolve_dynamic_type_internal): Likewise.
gdb/testsuite/ChangeLog:
* gdb.ada/funcall_ref.exp: New file.
* gdb.ada/funcall_ref/foo.adb: New file.
I see these two fails in no-unwaited-for-left.exp in remote testing
for aarch64-linux target.
...
continue
Continuing.
warning: Remote failure reply: E.No unwaited-for children left.
[Thread 1084] #2 stopped.
(gdb) FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when thread 2 exits
....
continue
Continuing.
warning: Remote failure reply: E.No unwaited-for children left.
[Thread 1081] #1 stopped.
(gdb) FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits
I checked the gdb.log on buildbot, and find that these two fails also
appear on Debian-i686-native-extended-gdbserver and Fedora-ppc64be-native-gdbserver-m64.
I recall that they are about local/remote parity, and related RSP is missing.
There has been already a PR 14618 about it. This patch is to kfail them
on remote target.
gdb/testsuite:
2015-04-02 Yao Qi <yao.qi@linaro.org>
* gdb.threads/no-unwaited-for-left.exp: Set up kfail if target
is remote.
This commit makes GDB default to a sysroot of "target:".
One testcase needed updating as a result of this change.
gdb/ChangeLog:
* main.c (captured_main): Set gdb_sysroot to "target:"
if not otherwise set.
gdb/testsuite/ChangeLog:
* gdb.base/break-probes.exp: Cope with "target:" sysroot.
This commit adds support for filenames prefixed with "target:" to
exec_file_attach. This is required to correctly follow inferior
exec* calls when a gdb_sysroot prefixed with "target:" is set.
gdb/ChangeLog:
* exec.c (exec_file_attach): Support "target:" filenames.
This commit updates solib_find to strip the "target:" prefix from
gdb_sysroot when accessing local files. This ensures that the same
search algorithm is used for local files regardless of whether a
"target:" prefix was used or not. It also avoids cluttering GDB's
output with unnecessary "target:" prefixes on paths.
gdb/ChangeLog:
* solib.c (solib_find): Strip "target:" prefix from sysroot
if accessing local files.
symfile_bfd_open handled what were remote files as a special case.
Converting from "remote:" files to "target:" made symfile_bfd_open
look like this:
if remote:
open bfd, check format, etc
return
local-specific stuff
open bfd, check format, etc
return
This commit rearranges symfile_bfd_open to remove the duplicated
code, like this:
if local:
local-specific stuff
open bfd, check format, etc
return
gdb/ChangeLog:
* symfile.c (symfile_bfd_open): Reorder to remove duplicated
checks and error messages.
The functionality of "target:" sysroots is a superset of the
functionality of "remote:" sysroots. This commit causes the
"set sysroot" command to rewrite "remote:" sysroots as "target:"
sysroots and replaces "remote:" specific code with "target:"
specific code where still necessary.
gdb/ChangeLog:
* remote.h (REMOTE_SYSROOT_PREFIX): Remove definition.
(remote_filename_p): Remove declaration.
(remote_bfd_open): Likewise.
* remote.c (remote_bfd_iovec_open): Remove function.
(remote_bfd_iovec_close): Likewise.
(remote_bfd_iovec_pread): Likewise.
(remote_bfd_iovec_stat): Likewise.
(remote_filename_p): Likewise.
(remote_bfd_open): Likewise.
* symfile.h (gdb_bfd_open_maybe_remote): Remove declaration.
* symfile.c (separate_debug_file_exists): Use gdb_bfd_open.
(gdb_bfd_open_maybe_remote): Remove function.
(symfile_bfd_open): Replace remote filename check with
target filename check.
(reread_symbols): Use gdb_bfd_open.
* build-id.c (gdbcore.h): New include.
(build_id_to_debug_bfd): Use gdb_bfd_open.
* infcmd.c (attach_command_post_wait): Remove remote filename
check.
* solib.c (solib_find): Replace remote-specific handling with
target-specific handling. Update comments where necessary.
(solib_bfd_open): Replace remote-specific handling with
target-specific handling.
(gdb_sysroot_changed): New function.
(_initialize_solib): Call the above when gdb_sysroot changes.
* windows-tdep.c (gdbcore.h): New include.
(windows_xfer_shared_library): Use gdb_bfd_open.
This commit updates gdb_bfd_open to access files using target
fileio functions if the supplied path starts with "target:"
and if the local and target filesystems are not the same.
This allows users to specify "set sysroot target:" and have
GDB access files locally or from the remote as appropriate.
The new functions in gdb_bfd.c are copies of functions from
remote.c. This duplication is intentional and will be removed
by the next commit in this series.
gdb/ChangeLog:
* gdb/gdb_bfd.h (TARGET_SYSROOT_PREFIX): New definition.
(is_target_filename): New declaration.
(gdb_bfd_has_target_filename): Likewise.
(gdb_bfd_open): Update documentation comment.
* gdb_bfd.c (target.h): New include.
(gdb/fileio.h): Likewise.
(is_target_filename): New function.
(gdb_bfd_has_target_filename): Likewise.
(fileio_errno_to_host): Likewise.
(gdb_bfd_iovec_fileio_open): Likewise.
(gdb_bfd_iovec_fileio_pread): Likewise.
(gdb_bfd_iovec_fileio_close): Likewise.
(gdb_bfd_iovec_fileio_fstat): Likewise.
(gdb_bfd_open): Use target fileio to access paths prefixed
with "target:" where necessary.
This commit introduces a new target method target_filesystem_is_local
which can be used to determine whether or not the filesystem accessed
by the target_fileio_* methods is the local filesystem.
gdb/ChangeLog:
* target.h (struct target_ops) <to_filesystem_is_local>:
New field.
(target_filesystem_is_local): New macro.
* target-delegates.c: Regenerate.
* remote.c (remote_filesystem_is_local): New function.
(init_remote_ops): Initialize to_filesystem_is_local.
This commit introduces a new target method target_fileio_fstat
which can be used to retrieve information about files opened with
target_fileio_open.
gdb/ChangeLog:
* target.h (struct target_ops) <to_fileio_fstat>: New field.
(target_fileio_fstat): New declaration.
* target.c (target_fileio_fstat): New function.
* inf-child.c (inf_child_fileio_fstat): Likewise.
(inf_child_target): Initialize to_fileio_fstat.
* remote.c (init_remote_ops): Likewise.
My all-stop-on-top-of-non-stop series manages to shows regressions due
to this latent bug. currently_stepping returns true if
stepped_breakpoint is set. Obviously we should clear
it before checking currently_stepping, not after.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-04-01 Pedro Alves <palves@redhat.com>
* infrun.c (resume): Check currently_stepping after clearing
stepped_breakpoint, not before.
If interrupt_and_wait manages to trigger the FAIL path, we get:
ERROR OCCURED: can't read "test": no such variable
gdb/testsuite/ChangeLog:
2015-04-01 Pedro Alves <palves@redhat.com>
* gdb.threads/manythreads.exp (interrupt_and_wait): Pass $message
to fail instead of non-existent $test.
By inspection, I noticed a path where we return without discarding the
cleanups.
gdb/ChangeLog:
2015-04-01 Pedro Alves <palves@redhat.com>
* infrun.c (keep_going): Also discard cleanups if inserting
breakpoints fails.
Noticed that if an error is thrown out of target_wait, we miss running
finish_thread_state_cleanup.
Tested on x86_64 Fedora 20, with "maint set target-async off".
gdb/ChangeLog:
2015-04-01 Pedro Alves <palves@redhat.com>
* infrun.c (wait_for_inferior): Install the
finish_thread_state_cleanup cleanup across the whole function, not
just around handle_inferior_event.
We can use the recently added do_target_resume do simplify the code a
bit here.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-04-01 Pedro Alves <palves@redhat.com>
* infrun.c (resume) <step past permanent breakpoint>: Use
do_target_resume.
My all-stop-on-top-of-non-stop series manages to trip on a bug in the
linux-nat.c backend while running the testsuite. If a thread is
discovered while threads are being momentarily paused (without the
core's intervention), the thread ends up stuck in THREAD_STOPPED
state, even though from the user's perspective, the thread is running
even while it is paused.
From inspection, in the current sources, this can happen if we call
stop_and_resume_callback, though there's no way to test that with
current Linux kernels.
(While trying to come up with test to exercise this, I stumbled on:
https://sourceware.org/ml/gdb-patches/2015-03/msg00850.html
... which does include a non-trivial test, so I think I can still
claim I come out net positive. :-) )
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-04-01 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_handle_extended_wait): Always call set_running.
On GNU/Linux, if the target reuses the TID of a thread that GDB still
has in its list marked as THREAD_EXITED, GDB crashes, like:
(gdb) continue
Continuing.
src/gdb/thread.c:789: internal-error: set_running: Assertion `tp->state != THREAD_EXITED' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.threads/tid-reuse.exp: continue to breakpoint: after_reuse_time (GDB internal error)
Here:
(top-gdb) bt
#0 internal_error (file=0x953dd8 "src/gdb/thread.c", line=789, fmt=0x953da0 "%s: Assertion `%s' failed.")
at src/gdb/common/errors.c:54
#1 0x0000000000638514 in set_running (ptid=..., running=1) at src/gdb/thread.c:789
#2 0x00000000004bda42 in linux_handle_extended_wait (lp=0x16f5760, status=0, stopping=0) at src/gdb/linux-nat.c:2114
#3 0x00000000004bfa24 in linux_nat_filter_event (lwpid=20570, status=198015) at src/gdb/linux-nat.c:3127
#4 0x00000000004c070e in linux_nat_wait_1 (ops=0xe193d0, ptid=..., ourstatus=0x7fffffffd2c0, target_options=1) at src/gdb/linux-nat.c:3478
#5 0x00000000004c1015 in linux_nat_wait (ops=0xe193d0, ptid=..., ourstatus=0x7fffffffd2c0, target_options=1) at src/gdb/linux-nat.c:3722
#6 0x00000000004c92d2 in thread_db_wait (ops=0xd80b60 <thread_db_ops>, ptid=..., ourstatus=0x7fffffffd2c0, options=1)
at src/gdb/linux-thread-db.c:1525
#7 0x000000000066db43 in delegate_wait (self=0xd80b60 <thread_db_ops>, arg1=..., arg2=0x7fffffffd2c0, arg3=1) at src/gdb/target-delegates.c:116
#8 0x000000000067e54b in target_wait (ptid=..., status=0x7fffffffd2c0, options=1) at src/gdb/target.c:2206
#9 0x0000000000625111 in fetch_inferior_event (client_data=0x0) at src/gdb/infrun.c:3275
#10 0x0000000000648a3b in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:56
#11 0x00000000004c2ecb in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4655
I managed to come up with a test that reliably reproduces this. It
spawns enough threads for the pid number space to wrap around, so
could potentially take a while. On my box that's 4 seconds; on
gcc110, a PPC box which has max_pid set to 65536, it's over 10
seconds. So I made the test compute how long that would take, and cap
the time waited if it would be unreasonably long.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-04-01 Pedro Alves <palves@redhat.com>
* linux-thread-db.c (record_thread): Readd the thread to gdb's
list if it was marked exited.
gdb/testsuite/ChangeLog:
2015-04-01 Pedro Alves <palves@redhat.com>
* gdb.threads/tid-reuse.c: New file.
* gdb.threads/tid-reuse.exp: New file.
--attach/--multi are currently only mentioned on the usage info first
lines, the meaning of PROG is completely absent and the COMM text does
not mention '-/stdio'.
A few options are missing:
. --disable-randomization / --no-disable-randomization is not mentioned.
Although the manual has a comment saying these are superceded by
QDisableRandomization, that only makes sense for "run" in
extended-remote mode. When we start gdbserver passing it a PROG,
--disable-randomization / --no-disable-randomization do take effect.
So I think we should document these.
. We show --debug / --remote-debug, so might as well show --disable-packet too.
GDB's --help has this "For more information, consult the GDB manual"
blurb that is missing in GDBserver's --help.
Then shuffle things around a bit into "Operating modes", "Other
options" and "Debug options" sections, similarly to GDB's --help
structure.
Before:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ ./gdbserver/gdbserver --help
Usage: gdbserver [OPTIONS] COMM PROG [ARGS ...]
gdbserver [OPTIONS] --attach COMM PID
gdbserver [OPTIONS] --multi COMM
COMM may either be a tty device (for serial debugging), or
HOST:PORT to listen for a TCP connection.
Options:
--debug Enable general debugging output.
--debug-format=opt1[,opt2,...]
Specify extra content in debugging output.
Options:
all
none
timestamp
--remote-debug Enable remote protocol debugging output.
--version Display version information and exit.
--wrapper WRAPPER -- Run WRAPPER to start new programs.
--once Exit after the first connection has closed.
Report bugs to "<http://www.gnu.org/software/gdb/bugs/>".
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ ./gdbserver/gdbserver --help
Usage: gdbserver [OPTIONS] COMM PROG [ARGS ...]
gdbserver [OPTIONS] --attach COMM PID
gdbserver [OPTIONS] --multi COMM
COMM may either be a tty device (for serial debugging),
HOST:PORT to listen for a TCP connection, or '-' or 'stdio' to use
stdin/stdout of gdbserver.
PROG is the executable program. ARGS are arguments passed to inferior.
PID is the process ID to attach to, when --attach is specified.
Operating modes:
--attach Attach to running process PID.
--multi Start server without a specific program, and
only quit when explicitly commanded.
--once Exit after the first connection has closed.
--help Print this message and then exit.
--version Display version information and exit.
Other options:
--wrapper WRAPPER -- Run WRAPPER to start new programs.
--disable-randomization
Run PROG with address space randomization disabled.
--no-disable-randomization
Don't disable address space randomization when
starting PROG.
Debug options:
--debug Enable general debugging output.
--debug-format=opt1[,opt2,...]
Specify extra content in debugging output.
Options:
all
none
timestamp
--remote-debug Enable remote protocol debugging output.
--disable-packet=opt1[,opt2,...]
Disable support for RSP packets or features.
Options:
vCont, Tthread, qC, qfThreadInfo and
threads (disable all threading packets).
For more information, consult the GDB manual (available as on-line
info or a printed manual).
Report bugs to "<http://www.gnu.org/software/gdb/bugs/>".
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gdb/gdbserver/ChangeLog:
2015-04-01 Pedro Alves <palves@redhat.com>
Cleber Rosa <crosa@redhat.com>
* server.c (gdbserver_usage): Reorganize and extend the usage
message.
This patch, as the subject says, extends GDB so that it is able to use
the contents of the file /proc/PID/coredump_filter when generating a
corefile. This file contains a bit mask that is a representation of
the different types of memory mappings in the Linux kernel; the user
can choose to dump or not dump a certain type of memory mapping by
enabling/disabling the respective bit in the bit mask. Currently,
here is what is supported:
bit 0 Dump anonymous private mappings.
bit 1 Dump anonymous shared mappings.
bit 2 Dump file-backed private mappings.
bit 3 Dump file-backed shared mappings.
bit 4 (since Linux 2.6.24)
Dump ELF headers.
bit 5 (since Linux 2.6.28)
Dump private huge pages.
bit 6 (since Linux 2.6.28)
Dump shared huge pages.
(This table has been taken from core(5), but you can also read about it
on Documentation/filesystems/proc.txt inside the Linux kernel source
tree).
The default value for this file, used by the Linux kernel, is 0x33,
which means that bits 0, 1, 4 and 5 are enabled. This is also the
default for GDB implemented in this patch, FWIW.
Well, reading the file is obviously trivial. The hard part, mind you,
is how to determine the types of the memory mappings. For that, I
extended the code of gdb/linux-tdep.c:linux_find_memory_regions_full and
made it rely *much more* on the information gathered from
/proc/<PID>/smaps. This file contains a "verbose dump" of the
inferior's memory mappings, and we were not using as much information as
we could from it. If you want to read more about this file, take a look
at the proc(5) manpage (I will also write a blog post soon about
everything I had to learn to get this patch done, and when I it is ready
I will post it here).
With Oleg Nesterov's help, we could improve the current algorithm for
determining whether a memory mapping is anonymous/file-backed,
private/shared. GDB now also respects the MADV_DONTDUMP flag and does
not dump the memory mapping marked as so, and will always dump
"[vsyscall]" or "[vdso]" mappings (just like the Linux kernel).
In a nutshell, what the new code is doing is:
- If the mapping is associated to a file whose name ends with
" (deleted)", or if the file is "/dev/zero", or if it is "/SYSV%08x"
(shared memory), or if there is no file associated with it, or if
the AnonHugePages: or the Anonymous: fields in the /proc/PID/smaps
have contents, then GDB considers this mapping to be anonymous.
There is a special case in this, though: if the memory mapping is a
file-backed one, but *also* contains "Anonymous:" or
"AnonHugePages:" pages, then GDB considers this mapping to be *both*
anonymous and file-backed, just like the Linux kernel does. What
that means is simple: this mapping will be dumped if the user
requested anonymous mappings *or* if the user requested file-backed
mappings to be present in the corefile.
It is worth mentioning that, from all those checks described above,
the most fragile is the one to see if the file name ends with
" (deleted)". This does not necessarily mean that the mapping is
anonymous, because the deleted file associated with the mapping may
have been a hard link to another file, for example. The Linux
kernel checks to see if "i_nlink == 0", but GDB cannot easily do
this check (as it has been discussed, GDB would need to run as root,
and would need to check the contents of the /proc/PID/map_files/
directory in order to determine whether the deleted was a hardlink
or not). Therefore, we made a compromise here, and we assume that
if the file name ends with " (deleted)", then the mapping is indeed
anonymous. FWIW, this is something the Linux kernel could do
better: expose this information in a more direct way.
- If we see the flag "sh" in the VmFlags: field (in /proc/PID/smaps),
then certainly the memory mapping is shared (VM_SHARED). If we have
access to the VmFlags, and we don't see the "sh" there, then
certainly the mapping is private. However, older Linux kernels (see
the code for more details) do not have the VmFlags field; in that
case, we use another heuristic: if we see 'p' in the permission
flags, then we assume that the mapping is private, even though the
presence of the 's' flag there would mean VM_MAYSHARE, which means
the mapping could still be private. This should work OK enough,
however.
Finally, it is worth mentioning that I added a new command, 'set
use-coredump-filter on/off'. When it is 'on', it will read the
coredump_filter' file (if it exists) and use its value; otherwise, it
will use the default value mentioned above (0x33) to decide which memory
mappings to dump.
gdb/ChangeLog:
2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Oleg Nesterov <oleg@redhat.com>
PR corefiles/16092
* linux-tdep.c: Include 'gdbcmd.h' and 'gdb_regex.h'.
New enum identifying the various options of the coredump_filter
file.
(struct smaps_vmflags): New struct.
(use_coredump_filter): New variable.
(decode_vmflags): New function.
(mapping_is_anonymous_p): Likewise.
(dump_mapping_p): Likewise.
(linux_find_memory_regions_full): New variables
'coredumpfilter_name', 'coredumpfilterdata', 'pid', 'filterflags'.
Removed variable 'modified'. Read /proc/<PID>/smaps file; improve
parsing of its information. Implement memory mapping filtering
based on its contents.
(show_use_coredump_filter): New function.
(_initialize_linux_tdep): New command 'set use-coredump-filter'.
* NEWS: Mention the possibility of using the
'/proc/PID/coredump_filter' file when generating a corefile.
Mention new command 'set use-coredump-filter'.
gdb/doc/ChangeLog:
2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com>
PR corefiles/16092
* gdb.texinfo (gcore): Mention new command 'set
use-coredump-filter'.
(set use-coredump-filter): Document new command.
gdb/testsuite/ChangeLog:
2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com>
PR corefiles/16092
* gdb.base/coredump-filter.c: New file.
* gdb.base/coredump-filter.exp: Likewise.
When loading a corefile that has some inaccessible memory region(s),
GDB complains about it:
(gdb) core /my/corefile
[New LWP 28468]
Cannot access memory at address 0x355fc21148
Cannot access memory at address 0x355fc21140
(gdb)
However, despite not seeing the message "Core was generated by...", it
is still possible to inspect the corefile using regular GDB commands.
The reason for that is because read_memory_unsigned_integer throws an
exception when it cannot read the memory region, but
solib_svr4_r_ldsomap was not catching it. The fix is to catch the
exception and act accordingly.
Tested on Fedora 20 x86_64, no regressions found.
gdb/ChangeLog:
2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com>
* solib-svr4.c (solib_svr4_r_ldsomap): Catch possible exception by
read_memory_unsigned_integer.
This patch adds cpu information on linux based on /proc/cpuinfo as :
cpus Listing of all cpus/cores on the system
This patch also reorders the info os commands so that they are listed
in alphabetical order.
gdb/ChangeLog:
* NEWS: Mention info os cpus support.
* gdb/nat/linux-osdata.c (linux_xfer_osdata_cpus): New function.
(struct osdata_type): Add cpus entry, reorder the entries in
alphabetical order.
gdb/doc/ChangeLog:
* gdb.texinfo (Operating System Auxiliary Information): Add info os cpus
documentation, reorder the info os entries in alphabetical order.
This allows triplets where the vendor is not set.
gdb/ChangeLog:
2015-03-31 Matthias Klose <doko@ubuntu.com>
* compile/compile.c (compile_to_object): Allow triplets with or
without vendor set.
gdb/ChangeLog:
* remote.c (remote_mourn_1): Remove function. Update all callers
to use remote_mourn.
(extended_remote_mourn_1): Remove function. Update all callers
to use extended_remote_mourn.
(extended_remote_attach_1): Remove function. Update all callers
to use extended_remote_attach.
Simon Marchi:
I think this patch is wrong. Starting with that commit (f30d5c7),
some tests (e.g. mi-break.exp) started to fail for me, because
of gdb segfaulting.
The address of expr is passed to the cleanup. When the cleanup is ran,
expr is no longer in scope, so what is at that address is probably not
safe to use anymore. That's my guess.
gdb/ChangeLog
2015-03-27 Jan Kratochvil <jan.kratochvil@redhat.com>
Revert:
2015-03-26 Jan Kratochvil <jan.kratochvil@redhat.com>
Code cleanup.
* printcmd.c (print_command_1): Move expr variable scope.
GCC 4.4.7 generates the following warning:
| cc1: warnings being treated as errors
| dtrace-probe.c: In function ‘dtrace_process_dof_probe’:
| dtrace-probe.c:416: error: ‘expr’ may be used uninitialized in this function
| make[2]: *** [dtrace-probe.o] Error 1
Later versions (GCC 5) do a better job and don't generate the warning,
but it does not hurt to pre-initialize "expr" to NULL.
gdb/ChangeLog:
* dtrace-probe.c (dtrace_process_dof_probe): Initialize expr to NULL.
Indexes returned for special sections are off by one, i.e. with N+4
sections last one has index N+4 returned which is outside allocated
obstack (at the same time index N is not used at all).
In worst case, if sections obstack is allocated up to end of chunk,
writing last section data will cause buffer overrun and some data
corruption.
Here's output from Valgrind::
==14630== Invalid write of size 8
==14630== at 0x551B1A: add_to_objfile_sections_full (objfiles.c:225)
==14630== by 0x552768: allocate_objfile (objfiles.c:324)
==14630== by 0x4E8E2E: symbol_file_add_with_addrs (symfile.c:1171)
==14630== by 0x4E9453: symbol_file_add_from_bfd (symfile.c:1280)
==14630== by 0x4E9453: symbol_file_add (symfile.c:1295)
==14630== by 0x4E94B7: symbol_file_add_main_1 (symfile.c:1320)
==14630== by 0x514246: catch_command_errors_const (main.c:398)
==14630== by 0x5150AA: captured_main (main.c:1061)
==14630== by 0x51123C: catch_errors (exceptions.c:240)
==14630== by 0x51569A: gdb_main (main.c:1164)
==14630== by 0x408824: main (gdb.c:32)
==14630== Address 0x635f3b8 is 8 bytes after a block of size 4,064 alloc'd
==14630== at 0x4C2ABA0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14630== by 0x60F797: xmalloc (common-utils.c:41)
==14630== by 0x5E787FB: _obstack_begin (obstack.c:184)
==14630== by 0x552679: allocate_objfile (objfiles.c:294)
==14630== by 0x4E8E2E: symbol_file_add_with_addrs (symfile.c:1171)
==14630== by 0x4E9453: symbol_file_add_from_bfd (symfile.c:1280)
==14630== by 0x4E9453: symbol_file_add (symfile.c:1295)
==14630== by 0x4E94B7: symbol_file_add_main_1 (symfile.c:1320)
==14630== by 0x514246: catch_command_errors_const (main.c:398)
==14630== by 0x5150AA: captured_main (main.c:1061)
==14630== by 0x51123C: catch_errors (exceptions.c:240)
==14630== by 0x51569A: gdb_main (main.c:1164)
==14630== by 0x408824: main (gdb.c:32)
gdb/ChangeLog:
* gdb_bfd.c (gdb_bfd_section_index): Fix off-by-one for special
sections.
Exactly like x86_64-*-mingw, SYMBOL_PREFIX should not be set to "_" for
x86_64_*_cygwin
gdb/testuite/ChangeLog:
* lib/gdb.exp (gdb_target_symbol_prefix_flags): Don't set
SYMBOL_PREFIX for x86_64-*-cygwin.
The debugger on Solaris has been broken since the introduction of
DTrace probe support:
(gdb) start
Temporary breakpoint 1 at 0x80593bc: file simple_main.adb, line 4.
Starting program: /[...]/simple_main
[Thread debugging using libthread_db enabled]
No definition of "mutex_t" in current context.
The problem occurs while trying to parse a probe's argument,
and the exception propagates all the way to the top. This patch
fixes the issue by containing the exception and falling back on
using the "long" builtin type if the argument's type could not
be determined.
Also, the parsing should be done using the C language parser.
gdb/ChangeLog:
* dtrace-probe.c (dtrace_process_dof_probe): Contain any
exception raised while parsing the probe arguments.
Force parsing to be done using the C language parser.
* expression.h (parse_expression_with_language): Declare.
* parse.c (parse_expression_with_language): New function.
Variables with a DW_AT_const_value but without a DW_AT_location were not
getting added to the partial symbol table. They are added to the full
symbol table, however, when the compilation unit's psymtabs are
expanded.
Before:
(gdb) p one
No symbol "one" in current context.
(gdb) mt flush-symbol-cache
(gdb) mt expand one.c
(gdb) p one
$1 = 1
After:
(gdb) p one
$1 = 1
To the user it's pretty strange, as depending on whether tab completion
has forced expansion of all CUs or not the lookup might succeed, or not
if the failure was already added to the symbol cache.
This commit simply makes sure to add constants to the partial symbol
tables.
gdb/testsuite/ChangeLog:
PR symtab/18148
* gdb.dwarf2/dw2-intercu.S (one, two): Add variables that have a
const_value but not a location.
* gdb.dwarf2/dw2-intercu.exp: Add tests that constants without
location defined in non-main CUs are visible.
gdb/ChangeLog:
PR symtab/18148
* dwarf2read.c (struct partial_die_info): Add has_const_value
member.
(add_partial_symbol): Don't punt on symbols that have const_value
attributes.
(read_partial_die): Detect DW_AT_const_value.
On Windows amd64, setting a breakpoint on a symbol imported from a
shared library after that library is loaded creates a breakpoint with
two locations, one on the import stub, and another in the shared
library, while on i386, the breakpoint is only set in the shared
library.
This is due to the minimal symbol for the import stub not being
correctly given the type mst_solib_trampoline on Windows amd64, unlike
Windows i386.
As currently written, coff_symfile_read is always skipping over the
character after the "__imp_" (amd64) or "_imp_" (i386) prefix,
assuming that it is '_'. However, while i386 is an underscored
target, amd64 is not.
On x86_64-pc-cygwin, it fixes:
- FAIL: gdb.base/solib-symbol.exp: foo in libmd
+ PASS: gdb.base/solib-symbol.exp: foo in libmd
Unfortunately, several other tests which passed now fail but that's
because this issue was masking other problems.
No change on i686-pc-cygwin.
gdb/ChangeLog:
2015-03-26 Pedro Alves <palves@redhat.com>
Jon TURNEY <jon.turney@dronecode.org.uk>
* coffread.c (coff_symfile_read): When constructing the name of an
import stub symbol from import symbol for amd64, only skip the
char after _imp_ if the target is underscored (like i386) and the
char is indeed the target's leading char.
break-asm-file.exp has some manually written dwarf to create some line
number entries like this,
[0x0000013d] Extended opcode 2: set Address to 0x40053f
[0x00000144] Advance Line by 4 to 7
[0x00000146] Copy
[0x00000147] Extended opcode 2: set Address to 0x400541
[0x0000014e] Advance Line by 1 to 8
[0x00000150] Copy
[0x00000151] Extended opcode 2: set Address to 0x400547
[0x00000158] Extended opcode 1: End of Sequence
0x40053f is the start address of function func, and is mapped to line
7. 0x400541 is within function func, and is mapped to line 8.
(gdb) disassemble /r 0x40053f,+8
Dump of assembler code from 0x40053f to 0x400547:
0x000000000040053f <func+0>: 00 00 add %al,(%rax)
0x0000000000400541 <func+2>: 00 00 add %al,(%rax)
0x0000000000400543 <func+4>: 00 00 add %al,(%rax)
0x0000000000400545 <func+6>: 00 00 add %al,(%rax)
in the following test,
(gdb) break a/break-asm-file0.s:func
Breakpoint 1 at 0x40053f: file a/break-asm-file0.s, line 7.
As we can see, breakpoint is set at the start address of function func
on x86, which means no prologue is skipped. On other targets, such as
arm and aarch64, breakpoint is set at the address *after* the start
address, which is mapped to line 8. Then test fails.
In fact, it is lucky this test doesn't fail on x86 and x86_64, whose
gdbarch method skip_prologue doesn't reply on skip_prologue_using_sal
if producer isn't clang.
if (find_pc_partial_function (start_pc, NULL, &func_addr, NULL))
{
CORE_ADDR post_prologue_pc
= skip_prologue_using_sal (gdbarch, func_addr);
struct compunit_symtab *cust = find_pc_compunit_symtab (func_addr);
/* Clang always emits a line note before the prologue and another
one after. We trust clang to emit usable line notes. */
if (post_prologue_pc
&& (cust != NULL
&& COMPUNIT_PRODUCER (cust) != NULL
&& startswith (COMPUNIT_PRODUCER (cust), "clang ")))
return max (start_pc, post_prologue_pc);
}
so it doesn't return and go further to prologue analyser. Since ".int 0"
isn't an instruction of prologue, nothing is skipped, starting address
is used, and test passes.
however, on targets which don't have such producer checking, the first
line number entry is skipped, and skip_prologue_using_sal returns sal
represents the second line number entry.
The idea of this patch is to force GDB stop at somewhere which is stilled
mapped to line 7 after skipping prologue. I choose to add a new line
number entry for the following instruction but mapped to the same line (7),
because I see the comments in dwarf2read.c,
... fact that two consecutive
line number entries for the same line is a heuristic used by gcc
to denote the end of the prologue.
then the line table becomes:
[0x000000d4] Extended opcode 2: set Address to 0x400529
[0x000000db] Advance Line by 4 to 7
[0x000000dd] Copy
[0x000000de] Extended opcode 2: set Address to 0x40052a
[0x000000e5] Advance Line by 0 to 7
[0x000000e7] Copy
[0x000000e8] Extended opcode 2: set Address to 0x40052b
[0x000000ef] Advance Line by 1 to 8
[0x000000f1] Copy
[0x000000f2] Extended opcode 2: set Address to 0x40052c
[0x000000f9] Extended opcode 1: End of Sequence
gdb/testsuite:
2015-03-26 Yao Qi <yao.qi@linaro.org>
PR testsuite/18139
* gdb.linespec/break-asm-file0.s (func): New label .Lfunc_2.
Add a line number entry for the same line.
* gdb.linespec/break-asm-file1.s (func): New label .Lfunc_2.
Add a line number entry for the same line.
There are some hard-coded stuff in .s files, such as .int 0 and
address offset, which isn't portable. This patch is to replace
".int 0" with nop and address offset with labels.
gdb/testsuite:
2015-03-26 Yao Qi <yao.qi@linaro.org>
* gdb.linespec/break-asm-file0.s (func2): Use nop instead of
.int 0.
(func): Likewise. Add .Lfunc_1 label.
Use .Lfunc_1 label.
* gdb.linespec/break-asm-file1.s (func3): Use nop instead of
.int 0.
(func): Likewise.
Use .Lfunc_1 label.
If I add some nop into break-asm-file1.s like this,
--- INDEX:/gdb/testsuite/gdb.linespec/break-asm-file1.s
+++ WORKDIR:/gdb/testsuite/gdb.linespec/break-asm-file1.s
@@ -31,8 +31,8 @@ _func:
.type func, %function
func:
.Lbegin_func:
- .int 0
- .int 0
+ nop
+ nop
.Lend_func:
.size func, .-func
.Lend_text1:
I get the following error:
Running gdb/testsuite/gdb.linespec/break-asm-file.exp ...
gdb/testsuite/gdb.linespec/break-asm-file1.s: Assembler messages:^M
gdb/testsuite/gdb.linespec/break-asm-file1.s: Fatal error: duplicate .debug_line sections
break-asm-file0.s and break-asm-file1.s have already had debug information
(written manually), so don't need to generate debug infor for them.
gdb/testsuite:
2015-03-26 Yao Qi <yao.qi@linaro.org>
* gdb.linespec/break-asm-file.exp: Don't call prepare_for_testing.
Call gdb_compile instead to compile each .s files without debug
information.
Hi,
I see the following two fails in gdb.base/savedregs.exp on aarch64-linux,
info frame 2^M
Stack frame at 0x7ffffffa60:^M
pc = 0x40085c in thrower (/home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/savedregs.c:49); saved pc = 0x400898^M
called by frame at 0x7ffffffa70, caller of frame at 0x7fffffe800^M
source language c.^M
Arglist at 0x7ffffffa60, args: ^M
Locals at 0x7ffffffa60, Previous frame's sp is 0x7ffffffa60^M
(gdb) FAIL: gdb.base/savedregs.exp: Get thrower info frame
info frame 2^M
Stack frame at 0x7fffffe800:^M
pc = 0x400840 in catcher (/home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/savedregs.c:42); saved pc = 0x7fb7ffc350^M
called by frame at 0x7fffffe800, caller of frame at 0x7fffffe7e0^M
source language c.^M
Arglist at 0x7fffffe7f0, args: sig=11^M
Locals at 0x7fffffe7f0, Previous frame's sp is 0x7fffffe800
(gdb) FAIL: gdb.base/savedregs.exp: Get catcher info frame
looks the test expects to match "Saved registers:" from the output of
"info frame", but no registers are saved on these two frames, because
thrower and catcher are simple and leaf functions.
(gdb) disassemble thrower
Dump of assembler code for function thrower:
0x0000000000400858 <+0>: mov x0, #0x0 // #0
0x000000000040085c <+4>: strb wzr, [x0]
0x0000000000400860 <+8>: ret
End of assembler dump.
(gdb) disassemble catcher
Dump of assembler code for function catcher:
0x0000000000400838 <+0>: sub sp, sp, #0x10
0x000000000040083c <+4>: str w0, [sp,#12]
0x0000000000400840 <+8>: adrp x0, 0x410000
0x0000000000400844 <+12>: add x0, x0, #0xb9c
0x0000000000400848 <+16>: mov w1, #0x1 // #1
0x000000000040084c <+20>: str w1, [x0]
0x0000000000400850 <+24>: add sp, sp, #0x10
0x0000000000400854 <+28>: ret
There are two ways to fix these fails, one is to modify functions to
force some registers saved (for example, doing function call in them),
and the other one is to relax the pattern to optionally match
"Saved registers:". I did both, and feel that the latter is simple,
so here is it.
gdb/testsuite:
2015-03-26 Yao Qi <yao.qi@linaro.org>
* gdb.base/savedregs.exp (process_saved_regs): Make
"Saved registers:" optional in the pattern.
The x86-record_goto.S assembly source file does not build on 32-bit.
This breaks many tests that use this file.
Split it into x86_64-record_goto.S and i686-record_goto.S. Luckily, we
can use either one with the same test .exp file.
It further turned out that most tests do not really need a fixed binary;
they should work pretty well with a newly-compiled C program. The
one thing that breaks this is the heavy use of "record goto" to navigate
inside the recorded execution.
Combine step.exp, next,exp, and finish.exp into a single test step.exp
and use normal stepping and reverse-stepping commands for navigation.
testsuite/
* gdb.btrace/next.exp: Merged into step.exp.
* gdb.btrace/finish.exp: Merged into step.exp.
* gdb.btrace/nexti.exp: Merged into stepi.exp.
* gdb.btrace/step.exp: Use record_goto.c as test file. Avoid using
"record goto" and checking the exact replay position.
* gdb.btrace/stepi.exp: Choose test file based on target. Do not
check for "Recording format" in "info record" output.
* gdb.btrace/record_goto.exp: Choose test file based on target.
* gdb.btrace/x86-record_goto.S: Renamed into ...
* gdb.btrace/x86_64-record_goto.S: ... this.
* gdb.btrace/i686-record_goto.S: New.
* gdb.btrace/x86-tailcall.S: Renamed into ...
* gdb.btrace/x86_64-tailcall.S: ... this.
* gdb.btrace/i686-tailcall.S: New.
* gdb.btrace/x86-tailcall.c: Renamed into ...
* gdb.btrace/tailcall.c: ... this. Split "return ++answer" into two
separate statements. Update test.
* gdb.btrace/delta.exp: Use record_goto.c as test file.
* gdb.btrace/gcore.exp: Use record_goto.c as test file.
* gdb.btrace/nohist.exp: Use record_goto.c as test file.
* gdb.btrace/tailcall.exp: Choose test file based on target.
* gdb.btrace/Makefile.in: Remove next, finish, and nexti.
The trace for throwing and catching an exception can be quite big.
Increase the buffer size to avoid spurious fails.
testsuite/
* gdb.btrace/exception.exp: Increase BTS buffer size.
All callers of target_async pass it the same callback
(inferior_event_handler). Since both common code and target backends
need to be able to put the target in and out of target async mode at
any given time, there's really no way that a different callback could
be passed. This commit simplifies things, and removes the indirection
altogether. Bonus: with this, gdb's target_async method ends up with
the same signature as gdbserver's.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/ChangeLog:
2015-03-25 Pedro Alves <palves@redhat.com>
* target.h <to_async>: Replace 'callback' and 'context' parameters
with boolean 'enable' parameter.
(target_async): Replace CALLBACK and CONTEXT parameters with
boolean ENABLE parameter.
* inf-loop.c (inferior_event_handler): Adjust.
* linux-nat.c (linux_nat_attach, linux_nat_resume)
(linux_nat_resume): Adjust.
(async_client_callback, async_client_context): Delete.
(handle_target_event): Call inferior_event_handler directly.
(linux_nat_async): Replace 'callback' and 'context' parameters
with boolean 'enable' parameter. Adjust. Remove references to
async_client_callback and async_client_context.
(linux_nat_close): Adjust.
* record-btrace.c (record_btrace_async): Replace 'callback' and
'context' parameters with boolean 'enable' parameter. Adjust.
(record_btrace_resume): Adjust.
* record-full.c (record_full_async): Replace 'callback' and
'context' parameters with boolean 'enable' parameter. Adjust.
(record_full_resume, record_full_core_resume): Adjust.
* remote.c (struct remote_state) <async_client_callback,
async_client_context>: Delete fields.
(remote_start_remote, extended_remote_attach_1, remote_resume)
(extended_remote_create_inferior): Adjust.
(remote_async_serial_handler): Call inferior_event_handler
directly.
(remote_async): Replace 'callback' and 'context' parameters with
boolean 'enable' parameter. Adjust.
* top.c (gdb_readline_wrapper_cleanup, gdb_readline_wrapper):
Adjust.
* target-delegates.c: Regenerate.
Various target_fileio_* functions use integer file descriptors to
refer to open files. File operation functions are looked up from
the target stack as they are used, which causes problems if the
target stack changes after the file is opened.
For example, if a file is opened on a remote target and the remote
target disconnects or closes the remote target will be popped off
the stack. If target_fileio_close is then called on that file and
"set auto-connect-native-target" is "on" (the default) then the
native target's close method will be called. If the file opened
on the remote happens to share the same number with a file open in
GDB then that file will be closed by mistake.
This commit changes target_fileio_open to store newly opened file
descriptors in a table together with the target_ops used to open
them. The index into the table is returned and used as the file
descriptor argument to all target_fileio_* functions that accept
file descriptor arguments.
gdb/ChangeLog:
* target.c (fileio_ft_t): New typedef, define object vector.
(fileio_fhandles): New static variable.
(is_closed_fileio_fh): New macro.
(lowest_closed_fd): New static variable.
(acquire_fileio_fd): New function.
(release_fileio_fd): Likewise.
(fileio_fd_to_fh): New macro.
(target_fileio_open): Wrap the file descriptor on success.
(target_fileio_pwrite): Updated to use wrapped file descriptor.
(target_fileio_pread): Likewise.
(target_fileio_close): Likewise.
I noticed that "thread apply all" sometimes crashes.
The problem is that thread_apply_all_command doesn take exited threads
into account, and we qsort and then walk more elements than there
really ever were put in the array. Valgrind shows:
The current thread <Thread ID 3> has terminated. See `help thread'.
(gdb) thread apply all p 1
Thread 1 (Thread 0x7ffff7fc2740 (LWP 29579)):
$1 = 1
==29576== Use of uninitialised value of size 8
==29576== at 0x639CA8: set_thread_refcount (thread.c:1337)
==29576== by 0x5C2C7B: do_my_cleanups (cleanups.c:155)
==29576== by 0x5C2CE8: do_cleanups (cleanups.c:177)
==29576== by 0x63A191: thread_apply_all_command (thread.c:1477)
==29576== by 0x50374D: do_cfunc (cli-decode.c:105)
==29576== by 0x506865: cmd_func (cli-decode.c:1893)
==29576== by 0x7562CB: execute_command (top.c:476)
==29576== by 0x647DA4: command_handler (event-top.c:494)
==29576== by 0x648367: command_line_handler (event-top.c:692)
==29576== by 0x7BF7C9: rl_callback_read_char (callback.c:220)
==29576== by 0x64784C: rl_callback_read_char_wrapper (event-top.c:171)
==29576== by 0x647CB5: stdin_event_handler (event-top.c:432)
==29576==
...
This can happen easily today as linux-nat.c/linux-thread-db.c are
forgetting to purge non-current exited threads. But even with that
fixed, we can always do "thread apply all" with an exited thread
selected, which won't be deleted until the user switches to another
thread. That's what the test added by this commit exercises.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-03-24 Pedro Alves <palves@redhat.com>
* thread.c (thread_apply_all_command): Take exited threads into
account.
gdb/testsuite/ChangeLog:
2015-03-24 Pedro Alves <palves@redhat.com>
* gdb.threads/no-unwaited-for-left.exp: Test "thread apply all".
... and move comment to declaration.
gdb/ChangeLog:
2015-03-24 Pedro Alves <palves@redhat.com>
* infrun.c (user_visible_resume_ptid): Rewrite going from
most-locked to unlocked instead of the opposite. Move comment ...
* infrun.h (user_visible_resume_ptid): ... here.
This adds/tweaks a few debug logs I found useful recently.
gdb/gdbserver/ChangeLog:
2015-03-24 Pedro Alves <palves@redhat.com>
* linux-low.c (check_stopped_by_breakpoint): Tweak debug log
output. Also dump TRAP_TRACE.
(linux_low_filter_event): In debug output, distinguish a
resume_stop SIGSTOP from a delayed SIGSTOP.
gdb/ChangeLog:
2015-03-24 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_nat_resume): Output debug logs before trying
to resume the event lwp. Use the lwp's ptid instead of the passed
in (maybe wildcard) ptid.
(stop_wait_callback): Tweak debug log output.
(check_stopped_by_breakpoint): Tweak debug log output. Also dump
TRAP_TRACE.
(linux_nat_filter_event): In debug output, distinguish a
resume_stop SIGSTOP from a delayed SIGSTOP. Output debug logs
before trying to resume the lwp.
struct dynamic_prop_list is declared as follow:
struct dynamic_prop_list
{
[...]
/* The dynamic property itself. */
struct dynamic_prop *prop;
[...]
};
In this case, the pointer indirection is unnecessary and costing us,
for each dynamic property, the memory needed to store one pointer.
This patch removes this pointer indirection, savin us a tiny bit of
memory, as well as reduces a bit the complexity by removing the need
to allocate memory for the property, as the allocation is now part
of the struct itself.
gdb/ChangeLog:
* gdbtypes.h (struct dynamic_prop_list) <prop>: Remove
pointer indirection.
* gdbtypes.c (get_dyn_prop): Adjust, following change above.
(add_dyn_prop, copy_dynamic_prop_list): Likewise.
Tested on x86_64-linux.
Patrick Palka
Jon Turney
Pierre Muller
Gary Benson
Kevin Buettner
Pierre-Marie de Rodat
Gabriel Krisman Bertazi
Thomas Schwinge
Doug Evans
Max Filippov
Yao Qi
Mike Frysinger
Pedro Alves
Andreas Arnez
Romain Naour
Simon Marchi
Luis Machado
Stan Shebs
John Baldwin
Sergio Durigan Junior
Jan Kratochvil
Andy Wingo
H.J. Lu
Doug Evans
Sasha Smundak
Petr Machata
Antoine Tremblay
Matthias Klose
James Bowman
Joel Brobecker
Andrzej Kaczmarek
Don Breazeal
Markus Metzger