Commit graph

5424 commits

Author SHA1 Message Date
Yao Qi
2efe15c428 Catch exception in lib/gdbserver-support.exp:gdb_exit
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.
2015-04-13 15:46:11 +01:00
Sergio Durigan Junior
8cd8f2f8ac Rename variable "addr" to "coredump_var_addr" in gdb.base/coredump-filter.exp
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.
2015-04-13 02:45:16 -04:00
Pedro Alves
9ee417720b Cleanup signal-while-stepping-over-bp-other-thread.exp
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.
2015-04-10 19:49:00 +01:00
Pedro Alves
07473109e1 step-over-trips-on-watchpoint.exp: Don't put addresses in test messages
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.
2015-04-10 19:23:24 +01:00
Yao Qi
de3db44c87 [arm] watchpoint-reuse-slot.exp: skip setting HW points on some 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.
2015-04-10 16:23:13 +01:00
Pedro Alves
c79d856c88 Test step-over-{lands-on-breakpoint|trips-on-watchpoint}.exp with displaced stepping
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.
2015-04-10 13:31:59 +01:00
Pedro Alves
ebc90b50ce Make gdb.threads/step-over-trips-on-watchpoint.exp effective on !x86
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.
2015-04-10 13:11:32 +01:00
Pedro Alves
8f572e5c0f Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets
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.
2015-04-10 10:55:09 +01:00
Pedro Alves
8d707a12ef gdb/18216: displaced step+deliver signal, a thread needs step-over, crash
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.
2015-04-10 10:36:23 +01:00
Yao Qi
ef713951c5 [arm] Fix displaced stepping for thumb alu reg instruction
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.
2015-04-10 10:33:01 +01:00
Pedro Alves
906d60cf46 PR13858 - Can't do displaced stepping with no symbols
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.
2015-04-10 10:07:02 +01:00
Andy Wingo
f2983cc34e Add Guile frame-read-register command
gdb/ChangeLog:

	* guile/scm-frame.c (gdbscm_frame_read_register): New function.
	(frame_functions): Bind gdbscm_frame_read_register to
	frame-read-register.
	* guile/lib/gdb.scm (frame-read-register): Export.

gdb/doc/ChangeLog:

	* guile.texi (Frames In Guile): Describe frame-read-register.

gdb/testsuite/ChangeLog:

	* gdb.guile/scm-frame.exp: Add frame-read-register tests, modelled
	after the Python tests.
2015-04-09 14:39:00 +02:00
Sergio Durigan Junior
6d62641c83 Fix Python completion when using the "complete" command
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.
2015-04-08 18:27:10 -04:00
Pedro Alves
f3770638ca Add test for PR18214 and PR18216 - multiple step-overs with queued signals
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.
2015-04-08 19:59:03 +01:00
Pedro Alves
4496bed7f3 Fix gdb.trace/{actions,infotrace,while-stepping}.exp with extended-remote
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.
2015-04-08 10:39:43 +01:00
Pedro Alves
b97fde9213 gdb.base/interrupt.exp: Use send_inferior/$inferior_spawn_id
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.
2015-04-07 18:29:12 +01:00
Pedro Alves
f71c18e755 testsuite: Introduce $inferior_spawn_id
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.
2015-04-07 18:28:38 +01:00
Pedro Alves
6423214fcb testsuite: Don't use expect_background to reap gdbserver
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.
2015-04-07 18:27:55 +01:00
Pedro Alves
71c0ee8cb9 gdb_test_multiple: Fix user code argument processing
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.
2015-04-07 18:27:24 +01:00
Pedro Alves
203bc29be2 gdb.base/interrupt.exp: Use gdb_test_multiple instead of gdb_expect
gdb/testsuite/ChangeLog:
2015-04-07  Pedro Alves  <palves@redhat.com>

	* gdb.base/interrupt.exp: Use gdb_test_multiple instead of
	gdb_expect.
2015-04-07 18:27:22 +01:00
Pedro Alves
508a3ddf63 gdb.base/interrupt.exp: Fix race
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.
2015-04-07 18:19:29 +01:00
Pedro Alves
9f6dbe2bbb Fix gdb.trace/actions.exp race
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.
2015-04-07 17:04:18 +01:00
Yao Qi
337532fab1 Properly set alarm value in gdb.threads/non-stop-fair-events.exp
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.
2015-04-07 11:30:07 +01:00
Doug Evans
01b622d4c7 * lib/pascal.exp (gpc_compile): Rename dest arg to destfile.
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.
2015-04-06 08:45:06 -07:00
Pierre-Marie de Rodat
961f416025 Do not consider reference types as dynamic
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.
2015-04-03 15:23:49 +02:00
Yao Qi
cafda5977a kfail two tests in no-unwaited-for-left.exp for remote target
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.
2015-04-02 13:51:31 +01:00
Gary Benson
fed040c6a5 Make the default sysroot be "target:"
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.
2015-04-02 13:38:29 +01:00
Sasha Smundak
d11916aa89 Add support for writing unwinders in Python.
gdb/ChangeLog:

	* Makefile.in (SUBDIR_PYTHON_OBJS): Add py-unwind.o.
	(SUBDIR_PYTHON_SRCS): Add py-unwind.c.
	(py-unwind.o): New recipe.
	* NEWS: mention Python frame unwinding.
	* data-directory/Makefile.in (PYTHON_FILE_LIST): Add
	gdb/unwinder.py and gdb/command/unwinder.py
	* python/lib/gdb/__init__.py (packages): Add frame_unwinders
	list.
	(execute_unwinders): New function.
	* python/lib/gdb/command/unwinders.py: New file.
	* python/lib/gdb/unwinder.py: New file.
	* python/py-objfile.c (objfile_object): Add frame_unwinders field.
	(objfpy_dealloc): Decrement frame_unwinders reference count.
	(objfpy_initialize): Create frame_unwinders list.
	(objfpy_get_frame_unwinders): New function.
	(objfpy_set_frame_unwinders): Ditto.
	(objfile_getset): Add frame_unwinders attribute to Objfile.
	* python/py-progspace.c (pspace_object): Add frame_unwinders field.
	(pspy_dealloc): Decrement frame_unwinders reference count.
	(pspy_initialize): Create frame_unwinders list.
	(pspy_get_frame_unwinders): New function.
	(pspy_set_frame_unwinders): Ditto.
	(pspy_getset): Add frame_unwinders attribute to gdb.Progspace.
	* python/py-unwind.c: New file.
	* python/python-internal.h (pspy_get_name_unwinders): New prototype.
	(objpy_get_frame_unwinders): New prototype.
	(gdbpy_initialize_unwind): New prototype.
	* python/python.c (gdbpy_apply_type_printers): Call
	gdbpy_initialize_unwind.

gdb/doc/ChangeLog:

	* doc/python.texi (Writing a Frame Unwinder in Python): Add
	section.

gdb/testsuite/ChangeLog:

	* gdb.python/py-unwind-maint.c: New file.
	* gdb.python/py-unwind-maint.exp: New test.
	* gdb.python/py-unwind-maint.py: New file.
	* gdb.python/py-unwind.c: New file.
	* gdb.python/py-unwind.exp: New test.
	* gdb.python/py-unwind.py: New test.
2015-04-01 11:49:12 -07:00
Pedro Alves
a14711808e gdb.threads/manythreads.exp: can't read "test": no such variable
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.
2015-04-01 15:30:13 +01:00
Pedro Alves
0bbeccb1ee Fix gdb_spawn_with_cmdline_opts with non-empty GDBFLAGS
Running attach.exp with a DejaGnu board that sets GDBFLAGS, like
e.g.,:

  set GDBFLAGS "-ex \"set displaced off\""

fails with (line breaks added for clarity):

 (gdb) PASS: gdb.base/attach.exp: starting with --pid
 Executing on build: kill -9 3537    (timeout = 300)
 spawn -ignore SIGHUP kill -9 3537
 spawn of build/gdb/gdb -nw -nx \
  -data-directory build/gdb/testsuite/../data-directory  \
  -ex "set displaced off"-iex "set height 0" -iex "set width 0" \
                     ^^^^^^^^
  --pid=4468 -ex "start"  failed
 ERROR: Spawning build/gdb/gdb failed.
 UNRESOLVED: gdb.base/attach.exp: cmdline attach run: run to prompt

gdb/testsuite/ChangeLog:
2015-04-01  Pedro Alves  <palves@redhat.com>

	* lib/gdb.exp (gdb_spawn_with_cmdline_opts): Append space to
	GDBFLAGS if not empty.
2015-04-01 15:25:21 +01:00
Pierre-Marie de Rodat
3c724c8ca9 Share the "multi_line" helper among all testcases
gdb/testsuite/ChangeLog:

	* gdb.ada/complete.exp: Remove "multi_line".
	* gdb.ada/info_exc.exp: Remove "multi_line".
	* gdb.ada/packed_tagged.exp: Remove "multi_line".
	* gdb.ada/ptype_field.exp: Remove "multi_line".
	* gdb.ada/sym_print_name.exp: Remove "multi_line".
	* gdb.ada/tagged.exp: Remove "multi_line".
	* gdb.btrace/buffer-size.exp: Replace [join [list ...]] with
	[multi_line ...]
	* gdb.btrace/delta.exp: Likewise.
	* gdb.btrace/exception.exp: Likewise.
	* gdb.btrace/function_call_history.exp: Likewise.
	* gdb.btrace/instruction_history.exp: Likewise.
	* gdb.btrace/nohist.exp: Likewise.
	* gdb.btrace/record_goto.exp: Likewise.
	* gdb.btrace/segv.exp: Likewise.
	* gdb.btrace/stepi.exp: Likewise.
	* gdb.btrace/tailcall.exp: Likewise.
	* gdb.btrace/unknown_functions.exp: Likewise.
	* gdb.dwarf2/dw2-undefined-ret-addr.exp: Likewise.
	* lib/gdb.exp: Add the "multi_line" helper.
2015-04-01 15:06:39 +02:00
Pedro Alves
4eec2deb06 Crash on thread id wrap around
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.
2015-04-01 13:38:06 +01:00
Sergio Durigan Junior
df8411da08 Implement support for checking /proc/PID/coredump_filter
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.
2015-03-31 19:32:34 -04:00
Petr Machata
6ef37366be dwarf.exp: Allow generating a stub .debug_line section
Example of use:

	Dwarf::assemble "foo.s" {
	    build_id 0102030405060708

	    declare_labels L;
	    cu {is_64 0 version 4 addr_size 8} {
		DW_TAG_compile_unit {
		    {DW_AT_stmt_list $L DW_FORM_sec_offset}
		} {
		    DW_TAG_subprogram {
			# We can now reference the source file.
			{DW_AT_decl_file 1 DW_FORM_data1}
		    }
		}
	    }

	    lines {is_64 0 version 2 addr_size 8} L {
		include_dir "foo"
		include_dir "bar"
		file_name "foo.c" 1
		file_name "bar.c" 1
		file_name "baz.c" 2
	    }
	}

Signed-off-by: Petr Machata <pmachata@redhat.com>
2015-03-31 16:25:07 +02:00
Jon Turney
7ec911b0fb testsuite: Don't set SYMBOL_PREFIX for x86_64_*_cygwin
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.
2015-03-26 22:37:24 +00:00
Andy Wingo
ff908ebf86 Properly intern constants into psymtab
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.
2015-03-26 19:41:54 +01:00
Yao Qi
6d5f0679fe Handle the effect of skipping prologue
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.
2015-03-26 08:29:48 +00:00
Yao Qi
2898689ba3 Remove some hard-coded stuff in tests
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.
2015-03-26 08:29:48 +00:00
Yao Qi
8518049884 Compile break-asm-file{0,1}.s without debug info
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.
2015-03-26 08:29:48 +00:00
Yao Qi
8aa08a8dd5 Relax pattern to match the output of "info frame" in gdb.base/savedregs.exp
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.
2015-03-26 08:16:20 +00:00
Markus Metzger
66849923d2 btrace: fix tests for 32-bit
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.
2015-03-25 14:18:02 +01:00
Markus Metzger
11cc1b7453 btrace: increase buffer size for exception test
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.
2015-03-25 14:15:07 +01:00
Pedro Alves
a25d8bf9c5 Fix "thread apply all" with exited threads
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".
2015-03-24 21:01:29 +00:00
Pedro Alves
856e7dd698 Make "set scheduler-locking step" depend on user intention, only
Currently, "set scheduler-locking step" is a bit odd.  The manual
documents it as being optimized for stepping, so that focus of
debugging does not change unexpectedly, but then it says that
sometimes other threads may run, and thus focus may indeed change
unexpectedly...  A user can then be excused to get confused and wonder
why does GDB behave like this.

I don't think a user should have to know about details of how "next"
or whatever other run control command is implemented internally to
understand when does the "scheduler-locking step" setting take effect.

This patch completes a transition that the code has been moving
towards for a while.  It makes "set scheduler-locking step" hold
threads depending on whether the _command_ the user entered was a
stepping command [step/stepi/next/nexti], or not.

Before, GDB could end up locking threads even on "continue" if for
some reason run control decides a thread needs to be single stepped
(e.g., for a software watchpoint).

After, if a "continue" happens to need to single-step for some reason,
we won't lock threads (unless when stepping over a breakpoint,
naturally).  And if a stepping command wants to continue a thread for
bit, like when skipping a function to a step-resume breakpoint, we'll
still lock threads, so focus of debugging doesn't change.

In order to make this work, we need to record in the thread structure
whether what set it running was a stepping command.

(A follow up patch will remove the "step" parameters of 'proceed' and 'resume')

FWIW, Fedora GDB, which defaults to "scheduler-locking step" (mainline
defaults to "off") carries a different patch that goes in this
direction as well.

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/ChangeLog:
2015-03-24  Pedro Alves  <palves@redhat.com>

	* gdbthread.h (struct thread_control_state) <stepping_command>:
	New field.
	* infcmd.c (step_once): Pass step=1 to clear_proceed_status.  Set
	the thread's stepping_command field.
	* infrun.c (resume): Check the thread's stepping_command flag to
	determine which threads should be resumed.  Rename 'entry_step'
	local to user_step.
	(clear_proceed_status_thread): Clear 'stepping_command'.
	(schedlock_applies): Change parameter type to struct thread_info
	pointer.  Adjust.
	(find_thread_needs_step_over): Remove 'step' parameter.  Adjust.
	(switch_back_to_stepped_thread): Adjust calls to
	'schedlock_applies'.
	(_initialize_infrun): Adjust "set scheduler-locking step" help.

gdb/testsuite/ChangeLog:
2015-03-24  Pedro Alves  <palves@redhat.com>

	* gdb.threads/schedlock.exp (test_step): No longer expect that
	"set scheduler-locking step" with "next" over a function call runs
	threads unlocked.

gdb/doc/ChangeLog:
2015-03-24  Pedro Alves  <palves@redhat.com>

	* gdb.texinfo (test_step) <set scheduler-locking step>: No longer
	mention that threads may sometimes run unlocked.
2015-03-24 17:50:31 +00:00
Antoine Tremblay
ad235a410a Fix mi-pending.exp test output to allow stable test diffing
gdb/testsuite/ChangeLog:

	* gdb.mi/mi-pending.exp: Fix output of breakpoint test.
2015-03-24 13:38:19 -04:00
Antoine Tremblay
1563054901 Fix breakpoint thread condition missing with mi and a pending breakpoint.
When setting a pending breakpoint with a thread condition while using
the mi interface, the thread condition would be lost by gdb when the breakpoint
was resolved.

This patch fixes this behavior by setting the thread condition properly in the
mi case.

Also, this patch modifies the mi-pending test case to test for this issue and
removes some unneeded code in the testcase and dependency on stdio.

gdb/Changelog:
	PR breakpoints/16466
	* breakpoint.c (create_breakpoint): Set thread on breakpoint struct.

gdb/testsuite/ChangeLog:
	PR breakpoints/16466
	* gdb.mi/Makefile.in: Add mi-pendshr2.sl to cleanup.
	* gdb.mi/mi-pending.c (thread_func): New function.
	(int main): Add threading support required.
	* gdb.mi/mi-pending.exp: Add tests for this issue.
	* gdb.mi/mi-pendshr.c (pendfunc1): Remove stdio dependency.
	(pendfunc2): Remove stdio dependency.
	* gdb.mi/mi-pendshr2.c: New file.
2015-03-24 08:38:49 -04:00
Keith Seitz
693dca065a Add missing changelog entries of last commit 2015-03-23 13:29:19 -07:00
Keith Seitz
7e993ebf23 PR gdb/18021 - defend against "static virtual" methods
This bug appears to be caused by bad debuginfo. The method
causing the sefault in the reporter's test case is marked both static
and virtual.

This patch simply safegaurds against this case in dwarf2_add_member_fn,
where the code assumes that there is a `this' pointer when a virtual method
is seen (more specifically, when DW_AT_vtable_elem is seen).

It previously dereferenced the first formal parameter
(`this' pointer), which in this case doesn't exist. GDB consequently
segfaulted dereferencing a NULL pointer.

gdb/ChangeLog
	PR gdb/18021
	* dwarf2read.c (dwarf2_add_member_fn): Issue a complaint
	if we find a static method with DW_AT_vtable_elem_location.

gdb/testsuite/ChangeLog
	PR gdb/18021
	* gdb.dwarf2/staticvirtual.exp: New test.
2015-03-23 12:50:28 -07:00
Jan Kratochvil
bc23328cc1 Remove gdb.hp
gdb/ChangeLog
2015-03-20  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* config/djgpp/README: Remove gdb.hp.

gdb/testsuite/ChangeLog
2015-03-20  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* Makefile.in (ALL_SUBDIRS): Remove gdb.hp.
	* README: Remove HP-UX and gdb.hp.
	(configuration):
	* configure: Regenerate.
	* configure.ac (AC_OUTPUT): Remove gdb.hp/Makefile,
	gdb.hp/gdb.objdbg/Makefile, gdb.hp/gdb.base-hp/Makefile,
	gdb.hp/gdb.aCC/Makefile, gdb.hp/gdb.compat/Makefile,
	gdb.hp/gdb.defects/Makefile.
	* gdb.hp/Makefile.in: File deleted.
	* gdb.hp/gdb.aCC/Makefile.in: File deleted.
	* gdb.hp/gdb.aCC/optimize.c: File deleted.
	* gdb.hp/gdb.aCC/optimize.exp: File deleted.
	* gdb.hp/gdb.aCC/run.c: File deleted.
	* gdb.hp/gdb.aCC/watch-cmd.exp: File deleted.
	* gdb.hp/gdb.base-hp/Makefile.in: File deleted.
	* gdb.hp/gdb.base-hp/callfwmall.c: File deleted.
	* gdb.hp/gdb.base-hp/callfwmall.exp: File deleted.
	* gdb.hp/gdb.base-hp/dollar.c: File deleted.
	* gdb.hp/gdb.base-hp/dollar.exp: File deleted.
	* gdb.hp/gdb.base-hp/genso-thresh.c: File deleted.
	* gdb.hp/gdb.base-hp/hwwatchbus.c: File deleted.
	* gdb.hp/gdb.base-hp/hwwatchbus.exp: File deleted.
	* gdb.hp/gdb.base-hp/pxdb.c: File deleted.
	* gdb.hp/gdb.base-hp/pxdb.exp: File deleted.
	* gdb.hp/gdb.base-hp/reg-pa64.exp: File deleted.
	* gdb.hp/gdb.base-hp/reg-pa64.s: File deleted.
	* gdb.hp/gdb.base-hp/reg.exp: File deleted.
	* gdb.hp/gdb.base-hp/reg.s: File deleted.
	* gdb.hp/gdb.base-hp/sized-enum.c: File deleted.
	* gdb.hp/gdb.base-hp/sized-enum.exp: File deleted.
	* gdb.hp/gdb.base-hp/so-thresh.exp: File deleted.
	* gdb.hp/gdb.base-hp/so-thresh.mk: File deleted.
	* gdb.hp/gdb.base-hp/so-thresh.sh: File deleted.
	* gdb.hp/gdb.compat/Makefile.in: File deleted.
	* gdb.hp/gdb.compat/average.c: File deleted.
	* gdb.hp/gdb.compat/sum.c: File deleted.
	* gdb.hp/gdb.compat/xdb.c: File deleted.
	* gdb.hp/gdb.compat/xdb0.c: File deleted.
	* gdb.hp/gdb.compat/xdb0.h: File deleted.
	* gdb.hp/gdb.compat/xdb1.c: File deleted.
	* gdb.hp/gdb.compat/xdb1.exp: File deleted.
	* gdb.hp/gdb.compat/xdb2.exp: File deleted.
	* gdb.hp/gdb.compat/xdb3.exp: File deleted.
	* gdb.hp/gdb.defects/Makefile.in: File deleted.
	* gdb.hp/gdb.defects/bs14602.c: File deleted.
	* gdb.hp/gdb.defects/bs14602.exp: File deleted.
	* gdb.hp/gdb.defects/solib-d.c: File deleted.
	* gdb.hp/gdb.defects/solib-d.exp: File deleted.
	* gdb.hp/gdb.defects/solib-d1.c: File deleted.
	* gdb.hp/gdb.defects/solib-d2.c: File deleted.
	* gdb.hp/gdb.objdbg/Makefile.in: File deleted.
	* gdb.hp/gdb.objdbg/objdbg01.exp: File deleted.
	* gdb.hp/gdb.objdbg/objdbg01/x1.cc: File deleted.
	* gdb.hp/gdb.objdbg/objdbg01/x2.cc: File deleted.
	* gdb.hp/gdb.objdbg/objdbg01/x3.cc: File deleted.
	* gdb.hp/gdb.objdbg/objdbg01/x3.h: File deleted.
	* gdb.hp/gdb.objdbg/objdbg02.exp: File deleted.
	* gdb.hp/gdb.objdbg/objdbg02/x1.cc: File deleted.
	* gdb.hp/gdb.objdbg/objdbg02/x2.cc: File deleted.
	* gdb.hp/gdb.objdbg/objdbg02/x3.cc: File deleted.
	* gdb.hp/gdb.objdbg/objdbg03.exp: File deleted.
	* gdb.hp/gdb.objdbg/objdbg03/x1.cc: File deleted.
	* gdb.hp/gdb.objdbg/objdbg03/x2.cc: File deleted.
	* gdb.hp/gdb.objdbg/objdbg03/x3.cc: File deleted.
	* gdb.hp/gdb.objdbg/objdbg04.exp: File deleted.
	* gdb.hp/gdb.objdbg/objdbg04/x.h: File deleted.
	* gdb.hp/gdb.objdbg/objdbg04/x1.cc: File deleted.
	* gdb.hp/gdb.objdbg/objdbg04/x2.cc: File deleted.
	* gdb.hp/gdb.objdbg/tools/symaddr: File deleted.
	* gdb.hp/gdb.objdbg/tools/symaddr.pa64: File deleted.
	* gdb.hp/gdb.objdbg/tools/test-objdbg.cc: File deleted.
	* gdb.hp/tools/odump: File deleted.
2015-03-20 17:15:15 +01:00
Pedro Alves
8bf3b159e5 gdbserver/Linux: unbreak thread event randomization
Wanting to make sure the new continue-pending-status.exp test tests
both cases of threads 2 and 3 reporting an event, I added counters to
the test, to make it FAIL if events for both threads aren't seen.
Assuming a well behaved backend, and given a reasonable number of
iterations, it should PASS.

However, running that against GNU/Linux gdbserver, I found that
surprisingly, that FAILed.  GDBserver always reported the breakpoint
hit for the same thread.

Turns out that I broke gdbserver's thread event randomization
recently, with git commit 582511be ([gdbserver] linux-low.c: better
starvation avoidance, handle non-stop mode too).  In that commit I
missed that the thread structure also has a status_pending_p field...
The end result was that count_events_callback always returns 0, and
then if no thread is stepping, select_event_lwp always returns the
event thread.  IOW, no randomization is happening at all.  Quite
curious how all the other changes in that patch were sufficient to fix
non-stop-fair-events.exp anyway even with that broken.

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/gdbserver/ChangeLog:
2015-03-19 Pedro Alves  <palves@redhat.com>

	* linux-low.c (count_events_callback, select_event_lwp_callback):
	Use the lwp's status_pending_p field, not the thread's.

gdb/testsuite/ChangeLog:
2015-03-19  Pedro Alves  <palves@redhat.com>

	* gdb.threads/continue-pending-status.exp (saw_thread_2)
	(saw_thread_3): New globals.
	(top level): Increment them when an event for the corresponding
	thread is seen.
	(no thread starvation): New test.
2015-03-19 12:38:05 +00:00