Toolchain/binutils-gdb
1
0
Fork 0
forked from Imagelibrary/binutils-gdb
Code Pull Requests Activity
97,165 Commits 422 Branches 140 Tags
e5a1a79a4e0ee33292d45b10a759eb41f7358b7c
Commit Graph

1017 Commits

Author SHA1 Message Date
Pedro Alves
3333f03ae1 No longer handle negative 'step' in 'proceed' 
Nothing ever passes a negative 'step' to proceed.
Gets rid of one of the few remaining stop_after_trap references.

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

	* infrun.c (proceed): No longer handle negative step.
 2015-03-24 17:50:29 +00:00
Pedro Alves
492d29ea1c Split TRY_CATCH into TRY + CATCH 
This patch splits the TRY_CATCH macro into three, so that we go from
this:

~~~
  volatile gdb_exception ex;

  TRY_CATCH (ex, RETURN_MASK_ERROR)
    {
    }
  if (ex.reason < 0)
    {
    }
~~~

to this:

~~~
  TRY
    {
    }
  CATCH (ex, RETURN_MASK_ERROR)
    {
    }
  END_CATCH
~~~

Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.

This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.

TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:

  TRY
    {
    }

  // some code here.

  CATCH (ex, RETURN_MASK_ERROR)
    {
    }
  END_CATCH

Just like it isn't valid to do that with C++'s native try/catch.

By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.

The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved.  After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch].  The result was folded into this patch so that GDB
still builds at each incremental step.

END_CATCH is necessary for two reasons:

First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:

  #define CATCH(EXCEPTION, mask) \
    for (struct gdb_exception EXCEPTION; \
         exceptions_state_mc_catch (&EXCEPTION, MASK); \
	 EXCEPTION = exception_none)

would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.

Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow.  That will
be done in END_CATCH.

After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.

IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.

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

	* common/common-exceptions.c (struct catcher) <exception>: No
	longer a pointer to volatile exception.  Now an exception value.
	<mask>: Delete field.
	(exceptions_state_mc_init): Remove all parameters.  Adjust.
	(exceptions_state_mc): No longer pop the catcher here.
	(exceptions_state_mc_catch): New function.
	(throw_exception): Adjust.
	* common/common-exceptions.h (exceptions_state_mc_init): Remove
	all parameters.
	(exceptions_state_mc_catch): Declare.
	(TRY_CATCH): Rename to ...
	(TRY): ... this.  Remove EXCEPTION and MASK parameters.
	(CATCH, END_CATCH): New.
	All callers adjusted.

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

	Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
	instead.
 2015-03-07 15:14:14 +00:00
Pedro Alves
527a273ac1 garbage collect target_decr_pc_after_break 
record-btrace was the only target making use of this, and it no longer
uses it.

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

	* target.h (struct target_ops) <to_decr_pc_after_break>: Delete.
	(target_decr_pc_after_break): Delete declaration.
	* target.c (default_target_decr_pc_after_break)
	(target_decr_pc_after_break): Delete.
	* linux-nat.c (check_stopped_by_breakpoint, linux_nat_wait_1): Use
	gdbarch_decr_pc_after_break instead of target_decr_pc_after_break.
	* linux-thread-db.c (check_event): Likewise.
	* infrun.c (adjust_pc_after_break): Likewise.
	* darwin-nat.c (cancel_breakpoint): Likewise.
	* aix-thread.c (aix_thread_wait): Likewise.
	* target-delegates.c: Regenerate.
 2015-03-04 20:41:17 +00:00
Pedro Alves
1cf4d9513a Teach GDB about targets that can tell whether a trap is a breakpoint event 
The moribund locations heuristics are problematic.  This patch teaches
GDB about targets that can reliably tell whether a trap was caused by
a software or hardware breakpoint, and thus don't need moribund
locations, thus bypassing all the problems that mechanism has.

The non-stop-fair-events.exp test is frequently failing currently.
E.g., see https://sourceware.org/ml/gdb-testers/2015-q1/msg03148.html.

The root cause is a fundamental problem with moribund locations.  For
example, the stepped_breakpoint logic added by af48d08f breaks in this
case (which is what happens with that test):

 - Step thread A, no breakpoint is set at PC.

 - The kernel doesn't schedule thread A yet.

 - Insert breakpoint at A's PC, for some reason (e.g., a step-resume
   breakpoint for thread B).

 - Kernel finally schedules thread A.

 - thread A's stepped_breakpoint flag is not set, even though it now
   stepped a breakpoint instruction.

 - adjust_pc_after_break gets the PC wrong, because PC == PREV_PC, but
   stepped_breakpoint is not set.

We needed the stepped_breakpoint logic to workaround moribund
locations, because otherwise adjust_pc_after_break could apply an
adjustment when it shouldn't just because there _used_ to be a
breakpoint at PC (a moribund breakpoint location).  For example, on
x86, that's wrong if the thread really hasn't executed an int3, but
instead executed some other 1-byte long instruction.  Getting the PC
adjustment wrong of course leads to the inferior executing the wrong
instruction.

Other problems with moribund locations are:

 - if a true SIGTRAP happens to be raised when the program is
   executing the PC that used to have a breakpoint, GDB will assume
   that is a trap for a breakpoint that has recently been removed, and
   thus we miss reporting the random signal to the user.

 - to minimize that, we get rid of moribund location after a while.
   That while is defined as just a certain number of events being
   processed.  That number of events sometimes passes by before a
   delayed breakpoint is processed, and GDB confuses the trap for a
   random signal, thus reporting the random trap.  Once the user
   resumes the thread, the program crashes because the PC was not
   adjusted...

The fix for all this is to bite the bullet and get rid of heuristics
and instead rely on the target knowing accurately what caused the
SIGTRAP.  The target/kernel/stub is in the best position to know what
that, because it can e.g. consult priviledged CPU flags GDB has no
access to, or by knowing which exception vector entry was called when
the instruction trapped, etc.  Most debug APIs I've seen to date
report breakpoint hits as a distinct event in some fashion.  For
example, on the Linux kernel, whether a breakpoint was executed is
exposed to userspace in the si_code field of the SIGTRAP's siginfo.
On Windows, the debug API reports a EXCEPTION_BREAKPOINT exception
code.

We needed to keep around deleted breakpoints in an on-the-side list
(the moribund locations) for two main reasons:

  - Know that a SIGTRAP actually is a delayed event for a hit of a
    breakpoint that was removed before the event was processed, and
    thus should not be reported as a random signal.

  - So we still do the decr_pc_after_break adjustment in that case, so
    that the thread is resumed at the correct address.

In the new model, if GDB processes an event the target tells is a
breakpoint trap, and GDB doesn't find the corresponding breakpoint in
its breakpoint tables, it means that event is a delayed event for a
breakpoint that has since been removed, and thus the event should be
ignored.

For the decr_pc_after_after issue, it ends up being much simpler that
on targets that can reliably tell whether a breakpoint trapped, for
the breakpoint trap to present the PC already adjusted.  Proper
multi-threading support already implies that targets needs to be doing
decr_pc_after_break adjustment themselves, otherwise for example, in
all-stop if two threads hit a breakpoint simultaneously, and the user
does "info threads", he'll see the non-event thread that hit the
breakpoint stopped at the wrong PC.

This way (target adjusts) also ends up eliminating the need for some
awkward re-incrementing of the PC in the record-full and Linux targets
that we do today, and the need for the target_decr_pc_after_break
hook.

If the target always adjusts, then there's a case where GDB needs to
re-increment the PC.  Say, on x86, an "int3" instruction that was
explicitly written in the program traps.  In this case, GDB should
report a random SIGTRAP signal to the user, with the PC pointing at
the instruction past the int3, just like if GDB was not debugging the
program.  The user may well decide to pass the SIGTRAP to the program
because the program being debugged has a SIGTRAP handler that handles
its own breakpoints, and expects the PC to be unadjusted.

Tested on x86-64 Fedora 20.

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

	* breakpoint.c (need_moribund_for_location_type): New function.
	(bpstat_stop_status): Don't skipping checking moribund locations
	of breakpoint types which the target tell caused a stop.
	(program_breakpoint_here_p): New function, factored out from ...
	(bp_loc_is_permanent): ... this.
	(update_global_location_list): Don't create a moribund location if
	the target supports reporting stops of the type of the removed
	breakpoint.
	* breakpoint.h (program_breakpoint_here_p): New declaration.
	* infrun.c (adjust_pc_after_break): Return early if the target has
	already adjusted the PC.  Add comments.
	(handle_signal_stop): If nothing explains a signal, and the target
	tells us the stop was caused by a software breakpoint, check if
	there's a breakpoint instruction in the memory.  If so, adjust the
	PC before presenting the stop to the user.  Otherwise, ignore the
	trap.  If nothing explains a signal, and the target tells us the
	stop was caused by a hardware breakpoint, ignore the trap.
	* target.h (struct target_ops) <to_stopped_by_sw_breakpoint,
	to_supports_stopped_by_sw_breakpoint, to_stopped_by_hw_breakpoint,
	to_supports_stopped_by_hw_breakpoint>: New fields.
	(target_stopped_by_sw_breakpoint)
	(target_supports_stopped_by_sw_breakpoint)
	(target_stopped_by_hw_breakpoint)
	(target_supports_stopped_by_hw_breakpoint): Define.
	* target-delegates.c: Regenerate.
 2015-03-04 20:41:15 +00:00
Pedro Alves
79639e1132 follow-fork: don't lose the ptids as set by the target 
This Linuxism has made its way into infrun.c, in the follow-fork code:

       inferior_ptid = ptid_build (child_pid, child_pid, 0);

The OS-specific code should fill in the LWPID, TID parts with the
appropriate values, if any, and the core code should not be peeking at
the components of the ptids.

gdb/
2015-03-04  Pedro Alves  <palves@redhat.com>

	* infrun.c (follow_fork_inferior): Use the whole of the
	inferior_ptid and pending_follow.related_pid ptids instead of
	building ptids from the process components.  Adjust verbose output
	to use target_pid_to_str.
	* linux-nat.c (linux_child_follow_fork): Use the whole of the
	inferior_ptid and pending_follow.related_pid ptids instead of
	building ptids from the process components.
 2015-03-04 15:03:33 +00:00
Pedro Alves
95e50b2723 follow-exec: delete all non-execing threads 
This fixes invalid reads Valgrind first caught when debugging against
a GDBserver patched with a series that adds exec events to the remote
protocol.  Like these, using the gdb.threads/thread-execl.exp test:

$ valgrind ./gdb -data-directory=data-directory ./testsuite/gdb.threads/thread-execl  -ex "tar extended-remote :9999" -ex "b thread_execler" -ex "c" -ex "set scheduler-locking on"
...
Breakpoint 1, thread_execler (arg=0x0) at src/gdb/testsuite/gdb.threads/thread-execl.c:29
29        if (execl (image, image, NULL) == -1)
(gdb) n
Thread 32509.32509 is executing new program: build/gdb/testsuite/gdb.threads/thread-execl
[New Thread 32509.32532]
==32510== Invalid read of size 4
==32510==    at 0x5AA7D8: delete_breakpoint (breakpoint.c:13989)
==32510==    by 0x6285D3: delete_thread_breakpoint (thread.c:100)
==32510==    by 0x628603: delete_step_resume_breakpoint (thread.c:109)
==32510==    by 0x61622B: delete_thread_infrun_breakpoints (infrun.c:2928)
==32510==    by 0x6162EF: for_each_just_stopped_thread (infrun.c:2958)
==32510==    by 0x616311: delete_just_stopped_threads_infrun_breakpoints (infrun.c:2969)
==32510==    by 0x616C96: fetch_inferior_event (infrun.c:3267)
==32510==    by 0x63A2DE: inferior_event_handler (inf-loop.c:57)
==32510==    by 0x4E0E56: remote_async_serial_handler (remote.c:11877)
==32510==    by 0x4AF620: run_async_handler_and_reschedule (ser-base.c:137)
==32510==    by 0x4AF6F0: fd_event (ser-base.c:182)
==32510==    by 0x63806D: handle_file_event (event-loop.c:762)
==32510==  Address 0xcf333e0 is 16 bytes inside a block of size 200 free'd
==32510==    at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32510==    by 0x77CB74: xfree (common-utils.c:98)
==32510==    by 0x5AA954: delete_breakpoint (breakpoint.c:14056)
==32510==    by 0x5988BD: update_breakpoints_after_exec (breakpoint.c:3765)
==32510==    by 0x61360F: follow_exec (infrun.c:1091)
==32510==    by 0x6186FA: handle_inferior_event (infrun.c:4061)
==32510==    by 0x616C55: fetch_inferior_event (infrun.c:3261)
==32510==    by 0x63A2DE: inferior_event_handler (inf-loop.c:57)
==32510==    by 0x4E0E56: remote_async_serial_handler (remote.c:11877)
==32510==    by 0x4AF620: run_async_handler_and_reschedule (ser-base.c:137)
==32510==    by 0x4AF6F0: fd_event (ser-base.c:182)
==32510==    by 0x63806D: handle_file_event (event-loop.c:762)
==32510==
[Switching to Thread 32509.32532]

Breakpoint 1, thread_execler (arg=0x0) at src/gdb/testsuite/gdb.threads/thread-execl.c:29
29        if (execl (image, image, NULL) == -1)
(gdb)

The breakpoint in question is the step-resume breakpoint of the
non-main thread, the one that was "next"ed.

The exact same issue can be seen on mainline with native debugging, by
running the thread-execl.exp test in non-stop mode, because the kernel
doesn't report a thread exit event for the execing thread.

Tested on x86_64 Fedora 20.

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

	* infrun.c (follow_exec): Delete all threads of the process except
	the event thread.  Extended comments.

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

	* gdb.threads/thread-execl.exp (do_test): Handle non-stop.
	(top level): Call do_test with non-stop as well.
 2015-03-03 01:25:17 +00:00
Pedro Alves
0703599a49 Fix adjust_pc_after_break, remove still current thread check 
On decr_pc_after_break targets, GDB adjusts the PC incorrectly if a
background single-step stops somewhere where PC-$decr_pc has a
breakpoint, and the thread that finishes the step is not the current
thread, like:

   ADDR1 nop <-- breakpoint here
   ADDR2 jmp PC

IOW, say thread A is stepping ADDR2's line in the background (an
infinite loop), and the user switches focus to thread B.  GDB's
adjust_pc_after_break logic confuses the single-step stop of thread A
for a hit of the breakpoint at ADDR1, and thus adjusts thread A's PC
to point at ADDR1 when it should not, and reports a breakpoint hit,
when thread A did not execute the instruction at ADDR1 at all.

The test added by this patch exercises exactly that.

I can't find any reason we'd need the "thread to be examined is still
the current thread" condition in adjust_pc_after_break, at least
nowadays; it might have made sense in the past.  Best just remove it,
and rely on currently_stepping().

Here's the test's log of a run with an unpatched GDB:

 35        while (1);
 (gdb) PASS: gdb.threads/step-bg-decr-pc-switch-thread.exp: next over nop
 next&
 (gdb) PASS: gdb.threads/step-bg-decr-pc-switch-thread.exp: next& over inf loop
 thread 1
 [Switching to thread 1 (Thread 0x7ffff7fc2740 (LWP 29027))](running)
 (gdb)
 PASS: gdb.threads/step-bg-decr-pc-switch-thread.exp: switch to main thread
 Breakpoint 2, thread_function (arg=0x0) at ...src/gdb/testsuite/gdb.threads/step-bg-decr-pc-switch-thread.c:34
 34        NOP; /* set breakpoint here */
 FAIL: gdb.threads/step-bg-decr-pc-switch-thread.exp: no output while stepping

gdb/ChangeLog:
2015-02-11  Pedro Alves  <pedro@codesourcery.com>

	* infrun.c (adjust_pc_after_break): Don't adjust the PC just
	because the event thread is not the current thread.

gdb/testsuite/ChangeLog:
2015-02-11  Pedro Alves  <pedro@codesourcery.com>

	* gdb.threads/step-bg-decr-pc-switch-thread.c: New file.
	* gdb.threads/step-bg-decr-pc-switch-thread.exp: New file.
 2015-02-11 09:45:41 +00:00
Pedro Alves
b052c4fbf5 displaced_step_fixup may access memory from the wrong inferior/thread 
displaced_step_fixup takes an thread to work with, as argument.  OTOH,
gdbarch_displaced_step_fixup fixes up the current thread.  The former
calls the latter without making sure the current thread is the one
that was passed in.  If it is not, then gdbarch_displaced_step_fixup
may e.g., try reading from a running thread, which doesn't work on
some targets, or worse, read memory from the wrong inferior and
succeed.

This is mostly a latent problem currently, as non-stop switches the
current thread to the event thread early in fetch_inferior_event.

Tested on x86_64 Fedora 20.

gdb/
2015-02-10  Pedro Alves  <palves@redhat.com>

	* infrun.c (displaced_step_fixup): Switch to the event thread
	before calling gdbarch_displaced_step_fixup.
 2015-02-10 19:13:31 +00:00
Pedro Alves
6c400b59d5 PR cli/17828: -batch -ex r breaks terminal 
Commit d3d4baed (PR python/17372 - Python hangs when displaying
help()) had the side effect of causing 'gdb -batch' to leave the
terminal in the wrong state if the program was run.  E.g,.

 $ echo 'main(){*(int*)0=0;}' | gcc -x c -; ./gdb/gdb -batch -ex r ./a.out
 Program received signal SIGSEGV, Segmentation fault.
 0x00000000004004ff in main ()
 $

If you start typing the next command, seemingly nothing happens - GDB
left the terminal with echo disabled.

The issue is that that "r" ends up in fetch_inferior_event, which
calls reinstall_readline_callback_handler_cleanup, which causes
readline to prep the terminal (raw, echo disabled).  But "-batch"
causes GDB to exit before the top level event loop is first started,
and then nothing de-preps the terminal.

The reinstall_readline_callback_handler_cleanup function's intro
comment mentions:

 "Need to do this as we go back to the event loop, ready to process
 further input."

but the implementation forgets the case of when the interpreter is
sync, which indicates we won't return to the event loop yet, or as in
the case of -batch, we have not started it yet.

The fix is to not install the readline callback in that case.

For the test, in this case, checking that command echo still works is
sufficient.  Comparing stty output before/after running GDB is even
better.  Because stty may not be available, the test tries both ways.
In any case, since expect's spawn (what we use to start gdb) creates a
new pseudo tty, another expect spawn or tcl exec after GDB exits would
not see the wrong terminal settings.  So instead, the test spawns a
shell and runs stty and GDB in it.

Tested on x86_64 Fedora 20.

gdb/
2015-01-14  Pedro Alves  <palves@redhat.com>

	PR cli/17828
	* infrun.c (reinstall_readline_callback_handler_cleanup): Don't
	reinstall if the interpreter is sync.

gdb/testsuite/
2015-01-14  Pedro Alves  <palves@redhat.com>

	PR cli/17828
	* gdb.base/batch-preserve-term-settings.c: New file.
	* gdb.base/batch-preserve-term-settings.exp: New file.
 2015-01-14 11:51:06 +00:00
Joel Brobecker
32d0add0a6 Update year range in copyright notice of all files owned by the GDB project. 
gdb/ChangeLog:

        Update year range in copyright notice of all files.
 2015-01-01 13:32:14 +04:00
Simon Marchi
c9657e708a Introduce utility function find_inferior_ptid 
This patch introduces find_inferior_ptid to replace the common idiom

  find_inferior_pid (ptid_get_pid (...));

It replaces all the instances of that idiom that I found with the new
function.

No significant changes before/after the patch in the regression suite
on amd64 linux.

gdb/ChangeLog:

	* inferior.c (find_inferior_ptid): New function.
	* inferior.h (find_inferior_ptid): New declaration.
	* ada-tasks.c (ada_get_task_number): Use find_inferior_ptid.
	* corelow.c (core_pid_to_str): Same.
	* darwin-nat.c (darwin_resume): Same.
	* infrun.c (fetch_inferior_event): Same.
	(get_inferior_stop_soon): Same.
	(handle_inferior_event): Same.
	(handle_signal_stop): Same.
	* linux-nat.c (resume_lwp): Same.
	(stop_wait_callback): Same.
	* mi/mi-interp.c (mi_new_thread): Same.
	(mi_thread_exit): Same.
	* proc-service.c (ps_pglobal_lookup): Same.
	* record-btrace.c (record_btrace_step_thread): Same.
	* remote-sim.c (gdbsim_close_inferior): Same.
	(gdbsim_resume): Same.
	(gdbsim_stop): Same.
	* sol2-tdep.c (sol2_core_pid_to_str): Same.
	* target.c (memory_xfer_partial_1): Same.
	(default_thread_address_space): Same.
	* thread.c (thread_change_ptid): Same.
	(switch_to_thread): Same.
	(do_restore_current_thread_cleanup): Same.
 2014-12-15 12:00:55 -05:00
Doug Evans
43f3e411c4 Split struct symtab into two: struct symtab and compunit_symtab. 
Currently "symtabs" in gdb are stored as a single linked list of
struct symtab that contains both symbol symtabs (the blockvectors)
and file symtabs (the linetables).

This has led to confusion, bugs, and performance issues.

This patch is conceptually very simple: split struct symtab into
two pieces: one part containing things common across the entire
compilation unit, and one part containing things specific to each
source file.

Example.
For the case of a program built out of these files:

foo.c
  foo1.h
  foo2.h
bar.c
  foo1.h
  bar.h

Today we have a single list of struct symtabs:

objfile -> foo.c -> foo1.h -> foo2.h -> bar.c -> foo1.h -> bar.h -> NULL

where "->" means the "next" pointer in struct symtab.

With this patch, that turns into:

objfile -> foo.c(cu) -> bar.c(cu) -> NULL
            |            |
            v            v
           foo.c        bar.c
            |            |
            v            v
           foo1.h       foo1.h
            |            |
            v            v
           foo2.h       bar.h
            |            |
            v            v
           NULL         NULL

where "foo.c(cu)" and "bar.c(cu)" are struct compunit_symtab objects,
and the files foo.c, etc. are struct symtab objects.

So now, for example, when we want to iterate over all blockvectors
we can now just iterate over the compunit_symtab list.

Plus a lot of the data that was either unused or replicated for each
symtab in a compilation unit now lives in struct compunit_symtab.
E.g., the objfile pointer, the producer string, etc.
I thought of moving "language" out of struct symtab but there is
logic to try to compute the language based on previously seen files,
and I think that's best left as is for now.
With my standard monster benchmark with -readnow (which I can't actually
do, but based on my calculations), whereas today the list requires
77MB to store all the struct symtabs, it now only requires 37MB.
A modest space savings given the gigabytes needed for all the debug info,
etc.  Still, it's nice.  Plus, whereas today we create a copy of dirname
for each source file symtab in a compilation unit, we now only create one
for the compunit.

So this patch is basically just a data structure reorg,
I don't expect significant performance improvements from it.

Notes:

1) A followup patch can do a similar split for struct partial_symtab.
I have left that until after I get the changes I want in to
better utilize .gdb_index (it may affect how we do partial syms).

2) Another followup patch *could* rename struct symtab.
The term "symtab" is ambiguous and has been a source of confusion.
In this patch I'm leaving it alone, calling it the "historical" name
of "filetabs", which is what they are now: just the file-name + line-table.

gdb/ChangeLog:

	Split struct symtab into two: struct symtab and compunit_symtab.
	* amd64-tdep.c (amd64_skip_xmm_prologue): Fetch producer from compunit.
	* block.c (blockvector_for_pc_sect): Change "struct symtab *" argument
	to "struct compunit_symtab *".  All callers updated.
	(set_block_compunit_symtab): Renamed from set_block_symtab.  Change
	"struct symtab *" argument to "struct compunit_symtab *".
	All callers updated.
	(get_block_compunit_symtab): Renamed from get_block_symtab.  Change
	result to "struct compunit_symtab *".  All callers updated.
	(find_iterator_compunit_symtab): Renamed from find_iterator_symtab.
	Change result to "struct compunit_symtab *".  All callers updated.
	* block.h (struct global_block) <compunit_symtab>: Renamed from symtab.
	hange type to "struct compunit_symtab *".  All uses updated.
	(struct block_iterator) <d.compunit_symtab>: Renamed from "d.symtab".
	Change type to "struct compunit_symtab *".  All uses updated.
	* buildsym.c (struct buildsym_compunit): New struct.
	(subfiles, buildsym_compdir, buildsym_objfile, main_subfile): Delete.
	(buildsym_compunit): New static global.
	(finish_block_internal): Update to fetch objfile from
	buildsym_compunit.
	(make_blockvector): Delete objfile argument.
	(start_subfile): Rewrite to use buildsym_compunit.  Don't initialize
	debugformat, producer.
	(start_buildsym_compunit): New function.
	(free_buildsym_compunit): Renamed from free_subfiles_list.
	All callers updated.
	(patch_subfile_names): Rewrite to use buildsym_compunit.
	(get_compunit_symtab): New function.
	(get_macro_table): Delete argument comp_dir.  All callers updated.
	(start_symtab): Change result to "struct compunit_symtab *".
	All callers updated.  Create the subfile of the main source file.
	(watch_main_source_file_lossage): Rewrite to use buildsym_compunit.
	(reset_symtab_globals): Update.
	(end_symtab_get_static_block): Update to use buildsym_compunit.
	(end_symtab_without_blockvector): Rewrite.
	(end_symtab_with_blockvector): Change result to
	"struct compunit_symtab *".  All callers updated.
	Update to use buildsym_compunit.  Don't set symtab->dirname,
	instead set it in the compunit.
	Explicitly make sure main symtab is first in its list.
	Set debugformat, producer, blockvector, block_line_section, and
	macrotable in the compunit.
	(end_symtab_from_static_block): Change result to
	"struct compunit_symtab *".  All callers updated.
	(end_symtab, end_expandable_symtab): Ditto.
	(set_missing_symtab): Change symtab argument to
	"struct compunit_symtab *".  All callers updated.
	(augment_type_symtab): Ditto.
	(record_debugformat): Update to use buildsym_compunit.
	(record_producer): Update to use buildsym_compunit.
	* buildsym.h (struct subfile) <dirname>: Delete.
	<producer, debugformat>: Delete.
	<buildsym_compunit>: New member.
	(get_compunit_symtab): Declare.
	* dwarf2read.c (struct type_unit_group) <compunit_symtab>: Renamed
	from primary_symtab.  Change type to "struct compunit_symtab *".
	All uses updated.
	(dwarf2_start_symtab): Change result to "struct compunit_symtab *".
	All callers updated.
	(dwarf_decode_macros): Delete comp_dir argument.  All callers updated.
	(struct dwarf2_per_cu_quick_data) <compunit_symtab>: Renamed from
	symtab.  Change type to "struct compunit_symtab *".  All uses updated.
	(dw2_instantiate_symtab): Change result to "struct compunit_symtab *".
	All callers updated.
	(dw2_find_last_source_symtab): Ditto.
	(dw2_lookup_symbol): Ditto.
	(recursively_find_pc_sect_compunit_symtab): Renamed from
	recursively_find_pc_sect_symtab.  Change result to
	"struct compunit_symtab *".  All callers updated.
	(dw2_find_pc_sect_compunit_symtab): Renamed from
	dw2_find_pc_sect_symtab.  Change result to
	"struct compunit_symtab *".  All callers updated.
	(get_compunit_symtab): Renamed from get_symtab.  Change result to
	"struct compunit_symtab *".  All callers updated.
	(recursively_compute_inclusions): Change type of immediate_parent
	argument to "struct compunit_symtab *".  All callers updated.
	(compute_compunit_symtab_includes): Renamed from
	compute_symtab_includes.  All callers updated.  Rewrite to compute
	includes of compunit_symtabs and not symtabs.
	(process_full_comp_unit): Update to work with struct compunit_symtab.
	(process_full_type_unit): Ditto.
	(dwarf_decode_lines_1): Delete argument comp_dir.  All callers updated.
	(dwarf_decode_lines): Remove special case handling of main subfile.
	(macro_start_file): Delete argument comp_dir.  All callers updated.
	(dwarf_decode_macro_bytes): Ditto.
	* guile/scm-block.c (bkscm_print_block_syms_progress_smob): Update to
	use struct compunit_symtab.
	* i386-tdep.c (i386_skip_prologue): Fetch producer from compunit.
	* jit.c (finalize_symtab): Build compunit_symtab.
	* jv-lang.c (get_java_class_symtab): Change result to
	"struct compunit_symtab *".  All callers updated.
	* macroscope.c (sal_macro_scope): Fetch macro table from compunit.
	* macrotab.c (struct macro_table) <compunit_symtab>: Renamed from
	comp_dir.  Change type to "struct compunit_symtab *".
	All uses updated.
	(new_macro_table): Change comp_dir argument to cust,
	"struct compunit_symtab *".  All callers updated.
	* maint.c (struct cmd_stats) <nr_compunit_symtabs>: Renamed from
	nr_primary_symtabs.  All uses updated.
	(count_symtabs_and_blocks): Update to handle compunits.
	(report_command_stats): Update output, "primary symtabs" renamed to
	"compunits".
	* mdebugread.c (new_symtab): Change result to
	"struct compunit_symtab *".  All callers updated.
	(parse_procedure): Change type of search_symtab argument to
	"struct compunit_symtab *".  All callers updated.
	* objfiles.c (objfile_relocate1): Loop over blockvectors in a
	separate loop.
	* objfiles.h (struct objfile) <compunit_symtabs>: Renamed from
	symtabs.  Change type to "struct compunit_symtab *".  All uses updated.
	(ALL_OBJFILE_FILETABS): Renamed from ALL_OBJFILE_SYMTABS.
	All uses updated.
	(ALL_OBJFILE_COMPUNITS): Renamed from ALL_OBJFILE_PRIMARY_SYMTABS.
	All uses updated.
	(ALL_FILETABS): Renamed from ALL_SYMTABS.  All uses updated.
	(ALL_COMPUNITS): Renamed from ALL_PRIMARY_SYMTABS.  All uses updated.
	* psympriv.h (struct partial_symtab) <compunit_symtab>: Renamed from
	symtab.  Change type to "struct compunit_symtab *".  All uses updated.
	* psymtab.c (psymtab_to_symtab): Change result type to
	"struct compunit_symtab *".  All callers updated.
	(find_pc_sect_compunit_symtab_from_partial): Renamed from
	find_pc_sect_symtab_from_partial.  Change result type to
	"struct compunit_symtab *".  All callers updated.
	(lookup_symbol_aux_psymtabs): Change result type to
	"struct compunit_symtab *".  All callers updated.
	(find_last_source_symtab_from_partial): Ditto.
	* python/py-symtab.c (stpy_get_producer): Fetch producer from compunit.
	* source.c (forget_cached_source_info_for_objfile): Fetch debugformat
	and macro_table from compunit.
	* symfile-debug.c (debug_qf_find_last_source_symtab): Change result
	type to "struct compunit_symtab *".  All callers updated.
	(debug_qf_lookup_symbol): Ditto.
	(debug_qf_find_pc_sect_compunit_symtab): Renamed from
	debug_qf_find_pc_sect_symtab, change result type to
	"struct compunit_symtab *".  All callers updated.
	* symfile.c (allocate_symtab): Delete objfile argument.
	New argument cust.
	(allocate_compunit_symtab): New function.
	(add_compunit_symtab_to_objfile): New function.
	* symfile.h (struct quick_symbol_functions) <lookup_symbol>:
	Change result type to "struct compunit_symtab *".  All uses updated.
	<find_pc_sect_compunit_symtab>: Renamed from find_pc_sect_symtab.
	Change result type to "struct compunit_symtab *".  All uses updated.
	* symmisc.c (print_objfile_statistics): Compute blockvector count in
	separate loop.
	(dump_symtab_1): Update test for primary source symtab.
	(maintenance_info_symtabs): Update to handle compunit symtabs.
	(maintenance_check_symtabs): Ditto.
	* symtab.c (set_primary_symtab): Delete.
	(compunit_primary_filetab): New function.
	(compunit_language): New function.
	(iterate_over_some_symtabs): Change type of arguments "first",
	"after_last" to "struct compunit_symtab *".  All callers updated.
	Update to loop over symtabs in each compunit.
	(error_in_psymtab_expansion): Rename symtab argument to cust,
	and change type to "struct compunit_symtab *".  All callers updated.
	(find_pc_sect_compunit_symtab): Renamed from find_pc_sect_symtab.
	Change result type to "struct compunit_symtab *".  All callers updated.
	(find_pc_compunit_symtab): Renamed from find_pc_symtab.
	Change result type to "struct compunit_symtab *".  All callers updated.
	(find_pc_sect_line): Only loop over symtabs within selected compunit
	instead of all symtabs in the objfile.
	* symtab.h (struct symtab) <blockvector>: Moved to compunit_symtab.
	<compunit_symtab> New member.
	<block_line_section>: Moved to compunit_symtab.
	<locations_valid>: Ditto.
	<epilogue_unwind_valid>: Ditto.
	<macro_table>: Ditto.
	<dirname>: Ditto.
	<debugformat>: Ditto.
	<producer>: Ditto.
	<objfile>: Ditto.
	<call_site_htab>: Ditto.
	<includes>: Ditto.
	<user>: Ditto.
	<primary>: Delete
	(SYMTAB_COMPUNIT): New macro.
	(SYMTAB_BLOCKVECTOR): Update definition.
	(SYMTAB_OBJFILE): Update definition.
	(SYMTAB_DIRNAME): Update definition.
	(struct compunit_symtab): New type.  Common members among all source
	symtabs within a compilation unit moved here.  All uses updated.
	(COMPUNIT_OBJFILE): New macro.
	(COMPUNIT_FILETABS): New macro.
	(COMPUNIT_DEBUGFORMAT): New macro.
	(COMPUNIT_PRODUCER): New macro.
	(COMPUNIT_DIRNAME): New macro.
	(COMPUNIT_BLOCKVECTOR): New macro.
	(COMPUNIT_BLOCK_LINE_SECTION): New macro.
	(COMPUNIT_LOCATIONS_VALID): New macro.
	(COMPUNIT_EPILOGUE_UNWIND_VALID): New macro.
	(COMPUNIT_CALL_SITE_HTAB): New macro.
	(COMPUNIT_MACRO_TABLE): New macro.
	(ALL_COMPUNIT_FILETABS): New macro.
	(compunit_symtab_ptr): New typedef.
	(DEF_VEC_P (compunit_symtab_ptr)): New vector type.

gdb/testsuite/ChangeLog:

	* gdb.base/maint.exp: Update expected output.
 2014-11-20 07:47:44 -08:00
Pedro Alves
6218dc4bdb Garbage collect the infwait_state global 
No longer used since the non-continuable watchpoints handling rework.

gdb/
2014-11-12  Pedro Alves  <palves@redhat.com>

	* infrun.c (enum infwait_states, infwait_state): Delete.
 2014-11-12 11:02:11 +00:00
Pedro Alves
af48d08f97 fix skipping permanent breakpoints 
The gdb.arch/i386-bp_permanent.exp test is currently failing an
assertion recently added:

 (gdb) stepi
 ../../src/gdb/infrun.c:2237: internal-error: resume: Assertion `sig != GDB_SIGNAL_0' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n)
 FAIL: gdb.arch/i386-bp_permanent.exp: Single stepping past permanent breakpoint. (GDB internal error)

The assertion expects that the only reason we currently need to step a
breakpoint instruction is when we have a signal to deliver.  But when
stepping a permanent breakpoint (with or without a signal) we also
reach this code.

The assertion is correct and the permanent breakpoints skipping code
is wrong.

Consider the case of the user doing "step/stepi" when stopped at a
permanent breakpoint.  GDB's `resume' calls the
gdbarch_skip_permanent_breakpoint hook and then happily continues
stepping:

  /* Normally, by the time we reach `resume', the breakpoints are either
     removed or inserted, as appropriate.  The exception is if we're sitting
     at a permanent breakpoint; we need to step over it, but permanent
     breakpoints can't be removed.  So we have to test for it here.  */
  if (breakpoint_here_p (aspace, pc) == permanent_breakpoint_here)
    {
      gdbarch_skip_permanent_breakpoint (gdbarch, regcache);
    }

But since gdbarch_skip_permanent_breakpoint already advanced the PC
manually, this ends up executing the instruction that is _after_ the
breakpoint instruction.  The user-visible result is that a single-step
steps two instructions.

The gdb.arch/i386-bp_permanent.exp test is actually ensuring that
that's indeed how things work.  It runs to an int3 instruction, does
"stepi", and checks that "leave" was executed with that "stepi".  Like
this:

 (gdb) b *0x0804848c
 Breakpoint 2 at 0x804848c
 (gdb) c
 Continuing.

 Breakpoint 2, 0x0804848c in standard ()
 (gdb) disassemble
 Dump of assembler code for function standard:
    0x08048488 <+0>:     push   %ebp
    0x08048489 <+1>:     mov    %esp,%ebp
    0x0804848b <+3>:     push   %edi
 => 0x0804848c <+4>:     int3
    0x0804848d <+5>:     leave
    0x0804848e <+6>:     ret
    0x0804848f <+7>:     nop
 (gdb) si
 0x0804848e in standard ()
 (gdb) disassemble
 Dump of assembler code for function standard:
    0x08048488 <+0>:     push   %ebp
    0x08048489 <+1>:     mov    %esp,%ebp
    0x0804848b <+3>:     push   %edi
    0x0804848c <+4>:     int3
    0x0804848d <+5>:     leave
 => 0x0804848e <+6>:     ret
    0x0804848f <+7>:     nop
 End of assembler dump.
 (gdb)

One would instead expect that a stepi at 0x0804848c stops at
0x0804848d, _before_ the "leave" is executed.  This commit changes GDB
this way.  Care is taken to make stepping into a signal handler when
the step starts at a permanent breakpoint instruction work correctly.

The patch adjusts gdb.arch/i386-bp_permanent.exp in this direction,
and also makes it work on x86_64 (currently it only works on i*86).

The patch also adds a new gdb.base/bp-permanent.exp test that
exercises many different code paths related to stepping permanent
breakpoints, including the stepping with signals cases.  The test uses
"hack/trick" to make it work on all (or most) platforms -- it doesn't
really hard code a breakpoint instruction.

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/
2014-11-12  Pedro Alves  <palves@redhat.com>

	* infrun.c (resume): Clear the thread's 'stepped_breakpoint' flag.
	Rewrite stepping over a permanent breakpoint.
	(thread_still_needs_step_over, proceed): Don't set
	stepping_over_breakpoint for permanent breakpoints.
	(handle_signal_stop): Don't clear stepped_breakpoint.  Also pull
	single-step breakpoints out of the target on hardware step
	targets.
	(process_event_stop_test): If stepping a permanent breakpoint
	doesn't hit the step-resume breakpoint, delete the step-resume
	breakpoint.
	(switch_back_to_stepped_thread): Also check if the stepped thread
	has advanced already on hardware step targets.
	(currently_stepping): Return true if the thread stepped a
	breakpoint.

gdb/testsuite/
2014-11-12  Pedro Alves  <palves@redhat.com>

	* gdb.arch/i386-bp_permanent.c: New file.
	* gdb.arch/i386-bp_permanent.exp: Don't skip on x86_64.
	(srcfile): Set to i386-bp_permanent.c.
	(top level): Adjust to work in both 32-bit and 64-bit modes.  Test
	that stepi does not execute the 'leave' instruction, instead of
	testing it does execute.
	* gdb.base/bp-permanent.c: New file.
	* gdb.base/bp-permanent.exp: New file.
 2014-11-12 10:39:00 +00:00
Pedro Alves
ae9bb220ca add a default method for gdbarch_skip_permanent_breakpoint 
breakpoint.c uses gdbarch_breakpoint_from_pc to determine whether a
breakpoint location points at a permanent breakpoint:

 static int
 bp_loc_is_permanent (struct bp_location *loc)
 {
 ...
   addr = loc->address;
   bpoint = gdbarch_breakpoint_from_pc (loc->gdbarch, &addr, &len);
 ...
  if (target_read_memory (loc->address, target_mem, len) == 0
      && memcmp (target_mem, bpoint, len) == 0)
    retval = 1;
 ...

So I think we should default the gdbarch_skip_permanent_breakpoint
hook to advancing the PC by the length of the breakpoint instruction,
as determined by gdbarch_breakpoint_from_pc.  I believe that simple
implementation does the right thing for most architectures.  If
there's an oddball architecture where that doesn't work, then it
should override the hook, just like it should be overriding the hook
if there was no default anyway.

The only two implementation of skip_permanent_breakpoint are
i386_skip_permanent_breakpoint, for x86, and
hppa_skip_permanent_breakpoint, for PA-RISC/HP-UX

The x86 implementation is trivial, and can clearly be replaced by the
new default.

I don't know about the HP-UX one though, I know almost nothing about
PA.  It may well be advancing the PC ends up being equivalent.
Otherwise, it must be that "jump $pc_after_bp" doesn't work either...

Tested on x86_64 Fedora 20 native and gdbserver.

gdb/
2014-11-12  Pedro Alves  <palves@redhat.com>

	* arch-utils.c (default_skip_permanent_breakpoint): New function.
	* arch-utils.h (default_skip_permanent_breakpoint): New
	declaration.
	* gdbarch.sh (skip_permanent_breakpoint): Now an 'f' function.
	Install default_skip_permanent_breakpoint as default method.
	* i386-tdep.c (i386_skip_permanent_breakpoint): Delete function.
	(i386_gdbarch_init): Don't install it.
	* infrun.c (resume): Assume there's always a
	gdbarch_skip_permanent_breakpoint implementation.
	* gdbarch.h, gdbarch.c: Regenerate.
 2014-11-12 10:32:53 +00:00
Pedro Alves
b7a084bebe Revert old nexti prologue check and eliminate in_prologue 
The in_prologue check in the nexti code is obsolete; this commit
removes that, and then removes the in_prologue function as nothing
else uses it.

Looking at the code in GDB that makes use in_prologue, all we find is
this one caller:

      if ((ecs->event_thread->control.step_over_calls == STEP_OVER_NONE)
	  || ((ecs->event_thread->control.step_range_end == 1)
	      && in_prologue (gdbarch, ecs->event_thread->prev_pc,
			      ecs->stop_func_start)))
	{
	  /* I presume that step_over_calls is only 0 when we're
	     supposed to be stepping at the assembly language level
	     ("stepi").  Just stop.  */
	  /* Also, maybe we just did a "nexti" inside a prolog, so we
	     thought it was a subroutine call but it was not.  Stop as
	     well.  FENN */
	  /* And this works the same backward as frontward.  MVS */
	  end_stepping_range (ecs);
	  return;
	}

This was added by:

 commit 100a02e1de
 ...
     From Fernando Nasser:
     * infrun.c (handle_inferior_event): Handle "nexti" inside function
     prologues.

The mailing list thread is here:

  https://sourceware.org/ml/gdb-patches/2001-01/msg00047.html

Not much discussion there, and no test, but looking at the code around
what was patched in that revision, we see that the checks that detect
whether the program has just stepped into a subroutine didn't rely on
the unwinders at all back then.

From 'git show 100a02e1:gdb/infrun.c':

    if (stop_pc == ecs->stop_func_start         /* Quick test */
        || (in_prologue (stop_pc, ecs->stop_func_start) &&
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            !IN_SOLIB_RETURN_TRAMPOLINE (stop_pc, ecs->stop_func_name))
        || IN_SOLIB_CALL_TRAMPOLINE (stop_pc, ecs->stop_func_name)
        || ecs->stop_func_name == 0)
      {
        /* It's a subroutine call.  */

        if ((step_over_calls == STEP_OVER_NONE)
            || ((step_range_end == 1)
                && in_prologue (prev_pc, ecs->stop_func_start)))
          {
            /* I presume that step_over_calls is only 0 when we're
               supposed to be stepping at the assembly language level
               ("stepi").  Just stop.  */
            /* Also, maybe we just did a "nexti" inside a prolog,
               so we thought it was a subroutine call but it was not.
               Stop as well.  FENN */
            stop_step = 1;
            print_stop_reason (END_STEPPING_RANGE, 0);
            stop_stepping (ecs);
            return;
          }

Stripping the IN_SOLIB_RETURN_TRAMPOLINE checks for simplicity, we had:

    if (stop_pc == ecs->stop_func_start         /* Quick test */
        || in_prologue (stop_pc, ecs->stop_func_start)
        || ecs->stop_func_name == 0)
      {
        /* It's a subroutine call.  */

That is, detecting a subroutine call was based on prologue detection
back then.  So the in_prologue check in the current tree only made
sense back then as it was undoing a bad decision the in_prologue check
that used to exist above did.

Today, the check for a subroutine call relies on frame ids instead,
which are stable throughout the function.  So we can just remove the
in_prologue check for nexti, and the whole in_prologue function along
with it.

Tested on x86_64 Fedora 20, and also by nexti-ing manually a prologue.

gdb/
2014-11-07  Pedro Alves  <palves@redhat.com>

	* infrun.c (process_event_stop_test) <subroutine check>: Don't
	check if we did a "nexti" inside a prologue.
	* symtab.c (in_prologue): Delete function.
	* symtab.h (in_prologue): Delete declaration.
 2014-11-07 13:53:01 +00:00
Pedro Alves
354204061c PR 17408 - assertion failure in switch_back_to_stepped_thread 
This PR shows that GDB can easily trigger an assertion here, in
infrun.c:

 5392              /* Did we find the stepping thread?  */
 5393              if (tp->control.step_range_end)
 5394                {
 5395                  /* Yep.  There should only one though.  */
 5396                  gdb_assert (stepping_thread == NULL);
 5397
 5398                  /* The event thread is handled at the top, before we
 5399                     enter this loop.  */
 5400                  gdb_assert (tp != ecs->event_thread);
 5401
 5402                  /* If some thread other than the event thread is
 5403                     stepping, then scheduler locking can't be in effect,
 5404                     otherwise we wouldn't have resumed the current event
 5405                     thread in the first place.  */
 5406                  gdb_assert (!schedlock_applies (currently_stepping (tp)));
 5407
 5408                  stepping_thread = tp;
 5409                }

Like:

 gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed.

The way the assertion is written is assuming that with schedlock=step
we'll always leave threads other than the one with the stepping range
locked, while that's not true with the "next" command.  With schedlock
"step", other threads still run unlocked when "next" detects a
function call and steps over it.  Whether that makes sense or not,
still, it's documented that way in the manual.  If another thread hits
an event that doesn't cause a stop while the nexting thread steps over
a function call, we'll get here and fail the assertion.

The fix is just to adjust the assertion.  Even though we found the
stepping thread, we'll still step-over the breakpoint that just
triggered correctly.

Surprisingly, gdb.threads/schedlock.exp doesn't have any test that
steps over a function call.  This commits fixes that.  This ensures
that "next" doesn't switch focus to another thread, and checks whether
other threads run locked or not, depending on scheduler locking mode
and command.  There's a lot of duplication in that file that this ends
cleaning up.  There's more that could be cleaned up, but that would
end up an unrelated change, best done separately.

This new coverage in schedlock.exp happens to trigger the internal
error in question, like so:

 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount)

That's because we have more than one thread running the same loop, and
while one thread is stepping over a function call, the other thread
hits the step-resume breakpoint of the first, which needs to be
stepped over, and we end up in switch_back_to_stepped_thread exactly
in the problem case.

I think a simpler and more directed test is also useful, to not rely
on internal breakpoint magics.  So this commit also adds a test that
has a thread trip on a conditional breakpoint that doesn't cause a
user-visible stop while another thread is stepping over a call.  That
currently fails like this:

 FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error)

Tested on x86_64 Fedora 20.

gdb/
2014-10-29  Pedro Alves  <palves@redhat.com>

	PR gdb/17408
	* infrun.c (switch_back_to_stepped_thread): Use currently_stepping
	instead of assuming a thread with a stepping range is always
	stepping.

gdb/testsuite/
2014-10-29  Pedro Alves  <palves@redhat.com>

	PR gdb/17408
	* gdb.threads/schedlock.c (some_function): New function.
	(call_function): New global.
	(MAYBE_CALL_SOME_FUNCTION): New macro.
	(thread_function): Call it.
	* gdb.threads/schedlock.exp (get_args): Add description parameter,
	and use it instead of a global counter.  Adjust all callers.
	(get_current_thread): Use "find current thread" for test message
	here rather than having all callers pass down the same string.
	(goto_loop): New procedure, factored out from ...
	(my_continue): ... this.
	(step_ten_loops): Change parameter from test message to command to
	use.  Adjust.
	(list_count): Delete global.
	(check_result): New procedure, factored out from duplicate top
	level code.
	(continue tests): Wrap in with_test_prefix.
	(test_step): New procedure, factored out from duplicate top level
	code.
	(top level): Test "step" in combination with all scheduler-locking
	modes.  Test "next" in combination with all scheduler-locking
	modes, and in combination with stepping over a function call or
	not.
	* gdb.threads/next-bp-other-thread.c: New file.
	* gdb.threads/next-bp-other-thread.exp: New file.
 2014-10-29 18:15:39 +00:00
Pedro Alves
d3d4baedb6 PR python/17372 - Python hangs when displaying help() 
This is more of a readline/terminal issue than a Python one.

PR17372 is a regression in 7.8 caused by the fix for PR17072:

 commit 0017922d02
 Author: Pedro Alves <palves@redhat.com>
 Date:   Mon Jul 14 19:55:32 2014 +0100

    Background execution + pagination aborts readline/gdb

    gdb_readline_wrapper_line removes the handler after a line is
    processed.  Usually, we'll end up re-displaying the prompt, and that
    reinstalls the handler.  But if the output is coming out of handling
    a stop event, we don't re-display the prompt, and nothing restores the
    handler.  So the next input wakes up the event loop and calls into
    readline, which aborts.
...
    gdb/
    2014-07-14  Pedro Alves  <palves@redhat.com>

        PR gdb/17072
        * top.c (gdb_readline_wrapper_line): Tweak comment.
        (gdb_readline_wrapper_cleanup): If readline is enabled, reinstall
        the input handler callback.

The problem is that installing the input handler callback also preps
the terminal, putting it in raw mode and with echo disabled, which is
bad if we're going to call a command that assumes cooked/canonical
mode, and echo enabled, like in the case of the PR, Python's
interactive shell.  Another example I came up with that doesn't depend
on Python is starting a subshell with "(gdb) shell /bin/sh" from a
multi-line command.  Tests covering both these examples are added.

The fix is to revert the original fix for PR gdb/17072, and instead
restore the callback handler after processing an asynchronous target
event.

Furthermore, calling rl_callback_handler_install when we already have
some input in readline's line buffer discards that input, which is
obviously a bad thing to do while the user is typing.  No specific
test is added for that, because I first tried calling it even if the
callback handler was still installed and that resulted in hundreds of
failures in the testsuite.

gdb/
2014-10-29  Pedro Alves  <palves@redhat.com>

	PR python/17372
	* event-top.c (change_line_handler): Call
	gdb_rl_callback_handler_remove instead of
	rl_callback_handler_remove.
	(callback_handler_installed): New global.
	(gdb_rl_callback_handler_remove, gdb_rl_callback_handler_install)
	(gdb_rl_callback_handler_reinstall): New functions.
	(display_gdb_prompt): Call gdb_rl_callback_handler_remove and
	gdb_rl_callback_handler_install instead of
	rl_callback_handler_remove and rl_callback_handler_install.
	(gdb_disable_readline): Call gdb_rl_callback_handler_remove
	instead of rl_callback_handler_remove.
	* event-top.h (gdb_rl_callback_handler_remove)
	(gdb_rl_callback_handler_install)
	(gdb_rl_callback_handler_reinstall): New declarations.
	* infrun.c (reinstall_readline_callback_handler_cleanup): New
	cleanup function.
	(fetch_inferior_event): Install it.
	* top.c (gdb_readline_wrapper_line) Call
	gdb_rl_callback_handler_remove instead of
	rl_callback_handler_remove.
	(gdb_readline_wrapper_cleanup): Don't call
	rl_callback_handler_install.

gdb/testsuite/
2014-10-29  Pedro Alves  <palves@redhat.com>

	PR python/17372
	* gdb.python/python.exp: Test a multi-line command that spawns
	interactive Python.
	* gdb.base/multi-line-starts-subshell.exp: New file.
 2014-10-29 17:29:26 +00:00
Pedro Alves
7f5ef60532 PR gdb/12623: non-stop crashes inferior, PC adjustment and 1-byte insns 
TL;DR - if we step an instruction that is as long as
decr_pc_after_break (1-byte on x86) right after removing the
breakpoint at PC, in non-stop mode, adjust_pc_after_break adjusts the
PC, but it shouldn't.

In non-stop mode, when a breakpoint is removed, it is moved to the
"moribund locations" list.  This is because other threads that are
running may have tripped on that breakpoint as well, and we haven't
heard about it.  When a trap is reported, we check if perhaps it was
such a deleted breakpoint that caused the trap.  If so, we also need
to adjust the PC (decr_pc_after_break).

Now, say that, on x86:

 - a breakpoint was placed at an address where we have an instruction
of the same length as decr_pc_after_break on this arch (1 on x86).

 - the breakpoint is removed, and thus put on the moribund locations
   list.

 - the thread is single-stepped.

As there's no breakpoint inserted at PC anymore, the single-step
actually executes the 1-byte instruction normally.  GDB should _not_
adjust the PC for the resulting SIGTRAP.  But, adjust_pc_after_break
confuses the step SIGTRAP reported for this single-step as being a
SIGTRAP for the moribund location of the breakpoint that used to be at
the previous PC, and so infrun applies the decr_pc_after_break
adjustment incorrectly.

The confusion comes from the special case mentioned in the comment:

 static void
 adjust_pc_after_break (struct execution_control_state *ecs)
 {
 ...
	  As a special case, we could have hardware single-stepped a
	  software breakpoint.  In this case (prev_pc == breakpoint_pc),
	  we also need to back up to the breakpoint address.  */

       if (thread_has_single_step_breakpoints_set (ecs->event_thread)
	   || !ptid_equal (ecs->ptid, inferior_ptid)
	   || !currently_stepping (ecs->event_thread)
	   || (ecs->event_thread->stepped_breakpoint
	       && ecs->event_thread->prev_pc == breakpoint_pc))
	 regcache_write_pc (regcache, breakpoint_pc);

The condition that incorrectly triggers is the
"ecs->event_thread->prev_pc == breakpoint_pc" one.

Afterwards, the next resume resume re-executes an instruction that had
already executed, which if you're lucky, results in the inferior
crashing.  If you're unlucky, you'll get silent bad behavior...

The fix is to remember that we stepped a breakpoint.  Turns out the
only case we step a breakpoint instruction today isn't covered by the
testsuite.  It's the case of a 'handle nostop" signal arriving while a
step is in progress _and_ we have a software watchpoint, which forces
always single-stepping.  This commit extends sigstep.exp to cover
that, and adds a new test for the adjust_pc_after_break issue.

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/
2014-10-28  Pedro Alves  <palves@redhat.com>

	PR gdb/12623
	* gdbthread.h (struct thread_info) <stepped_breakpoint>: New
	field.
	* infrun.c (resume) <stepping breakpoint instruction>: Set the
	thread's stepped_breakpoint field.  Skip if reverse debugging.
	Add comment.
	(init_thread_stepping_state, handle_signal_stop): Clear the
	thread's stepped_breakpoint field.

gdb/testsuite/
2014-10-28  Pedro Alves  <palves@redhat.com>

	PR gdb/12623
	* gdb.base/sigstep.c (no_handler): New global.
	(main): If 'no_handler is true, set the signal handlers to
	SIG_IGN.
	* gdb.base/sigstep.exp (breakpoint_over_handler): Add
	with_sw_watch and no_handler parameters.  Handle them.
	(top level) <stepping over handler when stopped at a breakpoint
	test>: Add a test axis for testing with a software watchpoint, and
	another for testing with the signal handler set to SIG_IGN.
	* gdb.base/step-sw-breakpoint-adjust-pc.c: New file.
	* gdb.base/step-sw-breakpoint-adjust-pc.exp: New file.
 2014-10-28 16:00:06 +00:00
Pedro Alves
e5f8a7cc2d stepi/nexti: skip signal handler if "handle nostop" signal arrives 
I noticed that "si" behaves differently when a "handle nostop" signal
arrives while the step is in progress, depending on whether the
program was stopped at a breakpoint when "si" was entered.
Specifically, in case GDB needs to step off a breakpoint, the handler
is skipped and the program stops in the next "mainline" instruction.
Otherwise, the "si" stops in the first instruction of the signal
handler.

I was surprised the testsuite doesn't catch this difference.  Turns
out gdb.base/sigstep.exp covers a bunch of cases related to stepping
and signal handlers, but does not test stepi nor nexti, only
step/next/continue.

My first reaction was that stopping in the signal handler was the
correct thing to do, as it's where the next user-visible instruction
that is executed is.  I considered then "nexti" -- a signal handler
could be reasonably considered a subroutine call to step over, it'd
seem intuitive to me that "nexti" would skip it.

But then, I realized that signals that arrive while a plain/line
"step" is in progress _also_ have their handler skipped.  A user might
well be excused for being confused by this, given:

  (gdb) help step
  Step program until it reaches a different source line.

And the signal handler's sources will be in different source lines,
after all.

I think that having to explain that "stepi" steps into handlers, (and
that "nexti" wouldn't according to my reasoning above), while "step"
does not, is a sign of an awkward interface.

E.g., if a user truly is interested in stepping into signal handlers,
then it's odd that she has to either force the signal to "handle
stop", or recall to do "stepi" whenever such a signal might be
delivered.  For that use case, it'd seem nicer to me if "step" also
stepped into handlers.

This suggests to me that we either need a global "step-into-handlers"
setting, or perhaps better, make "handle pass/nopass stop/nostop
print/noprint" have have an additional axis - "handle
stepinto/nostepinto", so that the user could configure whether
handlers for specific signals should be stepped into.

In any case, I think it's simpler (and thus better) for all step
commands to behave the same.  This commit thus makes "si/ni" skip
handlers for "handle nostop" signals that arrive while the command was
already in progress, like step/next do.

To be clear, nothing changes if the program was stopped for a signal,
and the user enters a stepping command _then_ -- GDB still steps into
the handler.  The change concerns signals that don't cause a stop and
that arrive while the step is in progress.

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/
2014-10-27  Pedro Alves  <palves@redhat.com>

	* infrun.c (handle_signal_stop): Also skip handlers when a random
	signal arrives while handling a "stepi" or a "nexti".  Set the
	thread's 'step_after_step_resume_breakpoint' flag.

gdb/doc/
2014-10-27  Pedro Alves  <palves@redhat.com>

	* gdb.texinfo (Continuing and Stepping): Add cross reference to
	info on stepping and signal handlers.
	(Signals): Explain stepping and signal handlers.  Add context
	index entry, and cross references.

gdb/testsuite/
2014-10-27  Pedro Alves  <palves@redhat.com>

	* gdb.base/sigstep.c (dummy): New global.
	(main): Issue a couple writes to the new global.
	* gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New
	procedures.
	(skip_over_handler): Use test_skip_handler.
	(top level): Call skip_over_handler for stepi and nexti too.
	(breakpoint_over_handler): Use test_skip_handler.
	(top level): Call breakpoint_over_handler for stepi and nexti too.
 2014-10-27 20:26:12 +00:00
Don Breazeal
6f259a235d Follow-fork message printing improvements 
This commit modifies the code that prints attach and detach messages
related to following fork and vfork.  The changes include using
target_terminal_ours_for_output instead of target_terminal_ours,
printing "vfork" instead of "fork" for all vfork-related messages,
and using _() for the format strings of all of the messages.

We also add a "detach" message for when a fork parent is detached.
Previously in this case the only message was notification of attaching
to the child.  We still do not print any messages when following the
parent and detaching the child (the default).  The rationale for this
is that from the user's perspective the new child was never attached.

Note that all of these messages are only printed when 'verbose' is set
or when debugging is turned on.

The tests gdb.base/foll-fork.exp and gdb.base/foll-vfork.exp were
modified to check for the new message.

Tested on x64 Ubuntu Lucid, native only.

gdb/ChangeLog:

	* infrun.c (follow_fork_inferior): Update fork message printing
	to use target_terminal_ours_for_output instead of
	target_terminal_ours, to use _() for all format strings, to print
	"vfork" instead of "fork" for vforks, and to add a detach message.
	(handle_vfork_child_exec_or_exit): Update message printing to use
	target_terminal_ours_for_output instead of target_terminal_ours, to
	use _() for all format strings, and to fix some formatting.

gdb/testsuite/ChangeLog:

	* gdb.base/foll-fork.exp (test_follow_fork,
	catch_fork_child_follow): Check for updated fork messages emitted
	from infrun.c.
	* gdb.base/foll-vfork.exp (vfork_parent_follow_through_step,
	vfork_parent_follow_to_bp, vfork_and_exec_child_follow_to_main_bp,
	vfork_and_exec_child_follow_through_step): Check for updated vfork
	messages emitted from infrun.c.
 2014-10-24 11:36:06 -07:00
Pedro Alves
36728e82bd Non-stop + software single-step archs: don't force displaced-stepping for all single-steps 
This finally reverts this bit of commit 929dfd4f:

  2009-07-31  Pedro Alves  <pedro@codesourcery.com>
	      Julian Brown  <julian@codesourcery.com>

	 ...
	 (resume): If this is a software single-stepping arch, and
	 displaced-stepping is enabled, use it for all single-step
	 requests.
	 ...

That means that in non-stop (or really displaced-stepping) mode, on
software single-step archs - even those that only use sss breakpoints
to deal with atomic sequences, like PPC - if we have more than one
thread single-stepping, we'll always serialize the threads'
single-steps, as only one thread may be displaced stepping at a given
time, because there's only one scratch pad.

We originally did that because GDB didn't support having multiple
threads software-single-stepping simultaneously.  The previous patches
fixed that limitation, so we can now finally revert this too.

Tested on:

  - x86_64 Fedora 20, on top of the 'software single-step on x86'
    series.

gdb/
2014-10-15  Pedro Alves  <palves@redhat.com>

	* infrun.c (resume): Don't force displaced-stepping for all
	single-steps on software single-stepping archs.
 2014-10-15 20:18:32 +01:00
Pedro Alves
34b7e8a6ad Make single-step breakpoints be per-thread 
This patch finally makes each thread have its own set of single-step
breakpoints.  This paves the way to have multiple threads software
single-stepping, though this patch doesn't flip that switch on yet.
That'll be done on a subsequent patch.

gdb/
2014-10-15  Pedro Alves  <palves@redhat.com>

	* breakpoint.c (single_step_breakpoints): Delete global.
	(insert_single_step_breakpoint): Adjust to store the breakpoint
	pointer in the current thread.
	(single_step_breakpoints_inserted, remove_single_step_breakpoints)
	(cancel_single_step_breakpoints): Delete functions.
	(breakpoint_has_location_inserted_here): Make extern.
	(single_step_breakpoint_inserted_here_p): Adjust to walk the
	breakpoint list.
	* breakpoint.h (breakpoint_has_location_inserted_here): New
	declaration.
	(single_step_breakpoints_inserted, remove_single_step_breakpoints)
	(cancel_single_step_breakpoints): Remove declarations.
	* gdbthread.h (struct thread_control_state)
	<single_step_breakpoints>: New field.
	(delete_single_step_breakpoints)
	(thread_has_single_step_breakpoints_set)
	(thread_has_single_step_breakpoint_here): New declarations.
	* infrun.c (follow_exec): Also clear the single-step breakpoints.
	(singlestep_breakpoints_inserted_p, singlestep_ptid)
	(singlestep_pc): Delete globals.
	(infrun_thread_ptid_changed): Remove references to removed
	globals.
	(resume_cleanups): Delete the current thread's single-step
	breakpoints.
	(maybe_software_singlestep): Remove references to removed globals.
	(resume): Adjust to use thread_has_single_step_breakpoints_set and
	delete_single_step_breakpoints.
	(init_wait_for_inferior): Remove references to removed globals.
	(delete_thread_infrun_breakpoints): Delete the thread's
	single-step breakpoints too.
	(delete_just_stopped_threads_infrun_breakpoints): Don't delete
	single-step breakpoints here.
	(delete_stopped_threads_single_step_breakpoints): New function.
	(adjust_pc_after_break): Adjust to use
	thread_has_single_step_breakpoints_set.
	(handle_inferior_event): Remove references to removed globals.
	Use delete_stopped_threads_single_step_breakpoints.
	(handle_signal_stop): Adjust to per-thread single-step
	breakpoints.  Swap test order to do cheaper tests first.
	(switch_back_to_stepped_thread): Extend debug output.  Remove
	references to removed globals.
	* record-full.c (record_full_wait_1): Adjust to per-thread
	single-step breakpoints.
	* thread.c (delete_single_step_breakpoints)
	(thread_has_single_step_breakpoints_set)
	(thread_has_single_step_breakpoint_here): New functions.
	(clear_thread_inferior_resources): Also delete the thread's
	single-step breakpoints.
 2014-10-15 20:18:32 +01:00
Pedro Alves
7c16b83e05 Put single-step breakpoints on the bp_location chain 
This patch makes single-step breakpoints "real" breakpoints on the
global location list.

There are several benefits to this:

- It removes the currently limitation that only 2 single-step
  breakpoints can be inserted.  See an example here of a discussion
  around a case that wants more than 2, possibly unbounded:

  https://sourceware.org/ml/gdb-patches/2014-03/msg00663.html

- makes software single-step work on read-only code regions.

  The logic to convert a software breakpoint to a hardware breakpoint
  if the memory map says the breakpoint address is in read only memory
  is in insert_bp_location.  Because software single-step breakpoints
  bypass all that go and straight to target_insert_breakpoint, we
  can't software single-step over read only memory.  This patch
  removes that limitation, and adds a test that makes sure that works,
  by forcing a code region to read-only with "mem LOW HIGH ro" and
  then stepping through that.

- Fixes PR breakpoints/9649

  This is an assertion failure in insert_single_step_breakpoint in
  breakpoint.c, because we may leave stale single-step breakpoints
  behind on error.

  The tests for stepping through read-only regions exercise the root
  cause of the bug, which is that we leave single-step breakpoints
  behind if we fail to insert any single-step breakpoint.  Deleting
  the single-step breakpoints in resume_cleanups,
  delete_just_stopped_threads_infrun_breakpoints, and
  fetch_inferior_event fixes this.  Without that, we'd no longer hit
  the assertion, as that code is deleted, but we'd instead run into
  errors/warnings trying to insert/remove the stale breakpoints on
  next resume.

- Paves the way to have multiple threads software single-stepping at
  the same time, leaving update_global_location_list to worry about
  duplicate locations.

- Makes the moribund location machinery aware of software single-step
  breakpoints, paving the way to enable software single-step on
  non-stop, instead of forcing serialized displaced stepping for all
  single steps.

- It's generaly cleaner.

  We no longer have to play games with single-step breakpoints
  inserted at the same address as regular breakpoints, like we
  recently had to do for 7.8.  See this discussion:

  https://sourceware.org/ml/gdb-patches/2014-06/msg00052.html.

Tested on x86_64 Fedora 20, on top of my 'single-step breakpoints on
x86' series.

gdb/
2014-10-15  Pedro Alves  <palves@redhat.com>

	PR breakpoints/9649
	* breakpoint.c (single_step_breakpoints, single_step_gdbarch):
	Delete array globals.
	(single_step_breakpoints): New global.
	(breakpoint_xfer_memory): Remove special handling for single-step
	breakpoints.
	(update_breakpoints_after_exec): Delete bp_single_step
	breakpoints.
	(detach_breakpoints): Remove special handling for single-step
	breakpoints.
	(breakpoint_init_inferior): Delete bp_single_step breakpoints.
	(bpstat_stop_status): Add comment.
	(bpstat_what, bptype_string, print_one_breakpoint_location)
	(adjust_breakpoint_address, init_bp_location): Handle
	bp_single_step.
	(new_single_step_breakpoint): New function.
	(set_momentary_breakpoint, bkpt_remove_location): Remove special
	handling for single-step breakpoints.
	(insert_single_step_breakpoint, single_step_breakpoints_inserted)
	(remove_single_step_breakpoints, cancel_single_step_breakpoints):
	Rewrite.
	(detach_single_step_breakpoints, find_single_step_breakpoint):
	Delete functions.
	(breakpoint_has_location_inserted_here): New function.
	(single_step_breakpoint_inserted_here_p): Rewrite.
	* breakpoint.h: Remove FIXME.
	(enum bptype) <bp_single_step>: New enum value.
	(insert_single_step_breakpoint): Update comment.
	* infrun.c (resume_cleanups)
	(delete_step_thread_step_resume_breakpoint): Remove single-step
	breakpoints.
	(fetch_inferior_event): Install a cleanup that removes infrun
	breakpoints.
	(switch_back_to_stepped_thread) <expect thread advanced also>:
	Clear step-over info.

gdb/testsuite/
2014-10-15  Pedro Alves  <palves@redhat.com>

	PR breakpoints/9649
	* gdb.base/breakpoint-in-ro-region.c (main): Add more instructions.
	* gdb.base/breakpoint-in-ro-region.exp
	(probe_target_hardware_step): New procedure.
	(top level): Probe hardware stepping and hardware breakpoint
	support.  Test stepping through a read-only region, with both
	"breakpoint auto-hw" on and off and both "always-inserted" on and
	off.
 2014-10-15 20:18:31 +01:00
Pedro Alves
0cbcdb96ea infrun.c: add for_each_just_stopped_thread 
This is a preparatory/cleanup patch that does two things:

- Renames 'delete_step_thread_step_resume_breakpoint'.  The
  "step_resume" part is misnomer these days, as the function deletes
  other kinds of breakpoints, not just the step-resume breakpoint.  A
  following patch will want to make it delete yet another kind of
  breakpoint, even.

- Splits out the logic of which threads get those breakpoints deleted
  to a separate "for_each"-style function, so that the same following
  patch may use it with a different callback.

Tested on x86_64 Fedora 20.

gdb/
2014-10-15  Pedro Alves  <palves@redhat.com>

	* infrun.c (delete_step_resume_breakpoint_callback): Delete.
	(delete_thread_infrun_breakpoints): New function, with parts
	salvaged from delete_step_resume_breakpoint_callback.
	(delete_step_thread_step_resume_breakpoint): Delete.
	(for_each_just_stopped_thread_callback_func): New typedef.
	(for_each_just_stopped_thread): New function.
	(delete_just_stopped_threads_infrun_breakpoints): New function.
	(delete_step_thread_step_resume_breakpoint_cleanup): Rename to ...
	(delete_just_stopped_threads_infrun_breakpoints_cleanup):
	... this.  Adjust.
	(wait_for_inferior, fetch_inferior_event): Adjust to renames.
 2014-10-15 20:18:30 +01:00
Pedro Alves
963f9c80cb Rewrite non-continuable watchpoints handling 
When GDB finds out the target triggered a watchpoint, and the target
has non-continuable watchpoints, GDB sets things up to step past the
instruction that triggered the watchpoint.  This is just like stepping
past a breakpoint, but goes through a different mechanism - it resumes
only the thread that needs to step past the watchpoint, but also
switches a "infwait state" global, that has the effect that the next
target_wait only wait for events only from that thread.

This forcing of a ptid to pass to target_wait obviously becomes a
bottleneck if we ever support stepping past different watchpoints
simultaneously (in separate processes).

It's also unnecessary -- the target should only return events for
threads that have been resumed; if no other thread than the one we're
stepping past the watchpoint has been resumed, then those other
threads should not report events.  If we couldn't assume that, then
stepping past regular breakpoints would be broken for not likewise
forcing a similar infwait_state.

So this patch eliminates infwait_state, and instead teaches keep_going
to mark step_over_info in a way that has the breakpoints module skip
inserting watchpoints (because we're stepping past one), like it skips
breakpoints when we're stepping past one.

Tested on:

 - x86_64 Fedora 20 (continuable watchpoints)
 - PPC64 Fedora 18  (non-steppable watchpoints)

gdb/
2014-10-15  Pedro Alves  <palves@redhat.com>

	* breakpoint.c (should_be_inserted): Don't insert watchpoints if
	trying to step past a non-steppable watchpoint.
	* gdbthread.h (struct thread_info) <stepping_over_watchpoint>: New
	field.
	* infrun.c (struct step_over_info): Add new field
	'nonsteppable_watchpoint_p' and adjust comments.
	(set_step_over_info): New 'nonsteppable_watchpoint_p' parameter.
	Adjust.
	(clear_step_over_info): Clear nonsteppable_watchpoint_p as well.
	(stepping_past_nonsteppable_watchpoint): New function.
	(step_over_info_valid_p): Also return true if stepping past a
	nonsteppable watchpoint.
	(proceed): Adjust call to set_step_over_info.  Remove reference to
	init_infwait_state.
	(init_wait_for_inferior): Remove reference to init_infwait_state.
	(waiton_ptid): Delete global.
	(struct execution_control_state)
	<stepped_after_stopped_by_watchpoint>: Delete field.
	(wait_for_inferior, fetch_inferior_event): Always pass
	minus_one_ptid to target_wait.
	(init_thread_stepping_state): Clear 'stepping_over_watchpoint'
	field.
	(init_infwait_state): Delete function.
	(handle_inferior_event): Remove infwait_state handling.
	(handle_signal_stop) <watchpoints handling>: Adjust after
	stepped_after_stopped_by_watchpoint removal.  Don't remove
	breakpoints here nor set infwait_state.  Set the thread's
	stepping_over_watchpoint flag, and call keep_going instead.
	(keep_going): Handle stepping_over_watchpoint.  Adjust
	set_step_over_info calls.
	* infrun.h (stepping_past_nonsteppable_watchpoint): Declare
	function.
 2014-10-15 20:18:30 +01:00
Pedro Alves
6cc83d2a40 Decide whether we may have removed breakpoints based on step_over_info 
... instead of trap_expected.

Gets rid of one singlestep_breakpoints_inserted_p reference, and is
generally more to the point.

gdb/
2014-10-15  Pedro Alves  <palves@redhat.com>

	* infrun.c (step_over_info_valid_p): New function.
	(resume): Use step_over_info_valid_p instead of checking the
	threads's trap_expected flag.
 2014-10-15 20:18:29 +01:00
Andreas Arnez
8fa0c4f8ed Remove non-address bits for longjmp resume breakpoint 
On 32-bit S390 targets the longjmp target address "naturally" has the
most significant bit set.  That bit indicates the addressing mode and
is not part of the address itself.  Thus, in analogy with similar
cases (like when computing the caller PC in
insert_step_resume_breakpoint_at_caller), this change removes
non-address bits from the longjmp target address before using it as a
breakpoint address.

Note that there are two ways for determining the longjmp target
address: via a probe or via a gdbarch method.  This change only
affects the probe method, because it is assumed that the address
returned by the gdbarch method is usable as-is.

This change was tested together with a patch that enables longjmp
probes in glibc for S/390:

  https://sourceware.org/ml/libc-alpha/2014-10/msg00277.html

gdb/ChangeLog:

	* gdb/infrun.c (process_event_stop_test): Apply
	gdbarch_addr_bits_remove to longjmp resume address.
 2014-10-15 17:32:38 +02:00
Pedro Alves
31cc0b807b infrun.c:normal_stop: Fix typo in comment 
gdb/
2014-10-10  Pedro Alves  <palves@redhat.com>

	* infrun.c (normal_stop): Fix typo in comment.
 2014-10-10 13:50:05 +01:00
Yao Qi
fcbdedf866 Remove unused local variable 
As a result of commit b57bacec, local variable 'printed' is no longer
used.  This patch is to remove it.

gdb:

2014-10-09  Yao Qi  <yao@codesourcery.com>

	* infrun.c (handle_signal_stop): Remove local variable 'printed'.
 2014-10-09 09:48:42 +08:00
Gary Benson
c765fdb902 Remove spurious exceptions.h inclusions 
defs.h includes utils.h, and utils.h includes exceptions.h.  All GDB
.c files include defs.h as their first line, so no file other than
utils.h needs to include exceptions.h.  This commit removes all such
inclusions.

gdb/ChangeLog:

	* ada-lang.c: Do not include exceptions.h.
	* ada-valprint.c: Likewise.
	* amd64-tdep.c: Likewise.
	* auto-load.c: Likewise.
	* block.c: Likewise.
	* break-catch-throw.c: Likewise.
	* breakpoint.c: Likewise.
	* btrace.c: Likewise.
	* c-lang.c: Likewise.
	* cli/cli-cmds.c: Likewise.
	* cli/cli-interp.c: Likewise.
	* cli/cli-script.c: Likewise.
	* completer.c: Likewise.
	* corefile.c: Likewise.
	* corelow.c: Likewise.
	* cp-abi.c: Likewise.
	* cp-support.c: Likewise.
	* cp-valprint.c: Likewise.
	* darwin-nat.c: Likewise.
	* dwarf2-frame-tailcall.c: Likewise.
	* dwarf2-frame.c: Likewise.
	* dwarf2loc.c: Likewise.
	* dwarf2read.c: Likewise.
	* eval.c: Likewise.
	* event-loop.c: Likewise.
	* event-top.c: Likewise.
	* f-valprint.c: Likewise.
	* frame-unwind.c: Likewise.
	* frame.c: Likewise.
	* gdbtypes.c: Likewise.
	* gnu-v2-abi.c: Likewise.
	* gnu-v3-abi.c: Likewise.
	* guile/scm-auto-load.c: Likewise.
	* guile/scm-breakpoint.c: Likewise.
	* guile/scm-cmd.c: Likewise.
	* guile/scm-frame.c: Likewise.
	* guile/scm-lazy-string.c: Likewise.
	* guile/scm-param.c: Likewise.
	* guile/scm-symbol.c: Likewise.
	* guile/scm-type.c: Likewise.
	* hppa-hpux-tdep.c: Likewise.
	* i386-tdep.c: Likewise.
	* inf-loop.c: Likewise.
	* infcall.c: Likewise.
	* infcmd.c: Likewise.
	* infrun.c: Likewise.
	* interps.c: Likewise.
	* interps.h: Likewise.
	* jit.c: Likewise.
	* linespec.c: Likewise.
	* linux-nat.c: Likewise.
	* linux-thread-db.c: Likewise.
	* m32r-rom.c: Likewise.
	* main.c: Likewise.
	* memory-map.c: Likewise.
	* mi/mi-cmd-break.c: Likewise.
	* mi/mi-cmd-stack.c: Likewise.
	* mi/mi-interp.c: Likewise.
	* mi/mi-main.c: Likewise.
	* monitor.c: Likewise.
	* nto-procfs.c: Likewise.
	* objc-lang.c: Likewise.
	* p-valprint.c: Likewise.
	* parse.c: Likewise.
	* ppc-linux-tdep.c: Likewise.
	* printcmd.c: Likewise.
	* probe.c: Likewise.
	* python/py-auto-load.c: Likewise.
	* python/py-breakpoint.c: Likewise.
	* python/py-cmd.c: Likewise.
	* python/py-finishbreakpoint.c: Likewise.
	* python/py-frame.c: Likewise.
	* python/py-framefilter.c: Likewise.
	* python/py-function.c: Likewise.
	* python/py-gdb-readline.c: Likewise.
	* python/py-inferior.c: Likewise.
	* python/py-infthread.c: Likewise.
	* python/py-lazy-string.c: Likewise.
	* python/py-linetable.c: Likewise.
	* python/py-param.c: Likewise.
	* python/py-prettyprint.c: Likewise.
	* python/py-symbol.c: Likewise.
	* python/py-type.c: Likewise.
	* python/py-value.c: Likewise.
	* python/python-internal.h: Likewise.
	* python/python.c: Likewise.
	* record-btrace.c: Likewise.
	* record-full.c: Likewise.
	* regcache.c: Likewise.
	* remote-fileio.c: Likewise.
	* remote-mips.c: Likewise.
	* remote.c: Likewise.
	* rs6000-aix-tdep.c: Likewise.
	* rs6000-nat.c: Likewise.
	* skip.c: Likewise.
	* solib-darwin.c: Likewise.
	* solib-dsbt.c: Likewise.
	* solib-frv.c: Likewise.
	* solib-ia64-hpux.c: Likewise.
	* solib-spu.c: Likewise.
	* solib-svr4.c: Likewise.
	* solib.c: Likewise.
	* spu-tdep.c: Likewise.
	* stack.c: Likewise.
	* stap-probe.c: Likewise.
	* symfile-mem.c: Likewise.
	* symmisc.c: Likewise.
	* target.c: Likewise.
	* thread.c: Likewise.
	* top.c: Likewise.
	* tracepoint.c: Likewise.
	* tui/tui-interp.c: Likewise.
	* typeprint.c: Likewise.
	* utils.c: Likewise.
	* valarith.c: Likewise.
	* valops.c: Likewise.
	* valprint.c: Likewise.
	* value.c: Likewise.
	* varobj.c: Likewise.
	* windows-nat.c: Likewise.
	* xml-support.c: Likewise.
 2014-10-08 09:33:22 +01:00
Pedro Alves
b57bacecd5 Fix non-stop regressions caused by "breakpoints always-inserted off" changes 
Commit a25a5a45 (Fix "breakpoint always-inserted off"; remove
"breakpoint always-inserted auto") regressed non-stop remote
debugging.

This was exposed by mi-nsintrall.exp intermittently failing with a
spurious SIGTRAP.

The problem is that when debugging with "target remote", new threads
the target has spawned but have never reported a stop aren't visible
to GDB until it explicitly resyncs its thread list with the target's.

For example, in a program like this:

 int
 main (void)
 {
   pthread_t child_thread;
   pthread_create (&child_thread, NULL, child_function, NULL);
   return 0;  <<<< set breakpoint here
 }

If the user sets a breakpoint at the "return" statement, and runs the
program, when that breakpoint hit is reported, GDB is only aware of
the main thread.  So if we base the decision to remove or insert
breakpoints from the target based on whether all the threads we know
about are stopped, we'll miss that child_thread is running, and thus
we'll remove breakpoints from the target, even through they should
still remain inserted, otherwise child_thread will miss them.

The break-while-running.exp test actually should also be exposing this
thread-list-out-of-synch problem.  That test sets a breakpoint while
the main thread is stopped, but other threads are running.  Because
other threads are running, the breakpoint is supposed to be inserted
immediately.  But, unless something forces a refetch of the thread
list, like, e.g., "info threads", GDB won't be aware of the other
threads that had been spawned by the main thread, and so won't insert
new or old breakpoints in the target.  And it turns out that the test
is exactly doing an explicit "info threads", masking out the
problem...  This commit adjust the test to exercise the case of not
issuing "info threads".  The test then fails without the GDB fix.

In the ni-nsintrall.exp case, what happens is that several threads hit
the same breakpoint, and when the first thread reports the stop,
because GDB wasn't aware other threads exist, all threads known to GDB
are found stopped, so GDB removes the breakpoints from the target.
The other threads follow up with SIGTRAPs too for that same
breakpoint, which has already been removed.  For the first few
threads, the moribund breakpoints machinery suppresses the SIGTRAPs,
but after a few events (precisely '3 * thread_count () + 1' at the
time the breakpoint was removed, see update_global_location_list), the
moribund breakpoint machinery is no longer aware of the removed
breakpoint, and the SIGTRAP is reported as a spurious stop.

The fix is naturally then to stop assuming that if no thread in the
list is executing, then the target is fully stopped.  We can't know
that until we fully sync the thread list.  Because updating the thread
list on every stop would be too much RSP traffic, I chose instead to
update it whenever we're about to present a stop to the user.

Actually updating the thread list at that point happens to be an item
I had added to the local/remote parity wiki page a while ago:

  Native GNU/Linux debugging adds new threads to the thread list as
  the program creates them "The [New Thread foo] messages". Remote
  debugging can't do that, and it's arguable whether we shouldn't even
  stop native debugging from doing that, as it hinders inferior
  performance. However, a related issue is that with remote targets
  (and gdbserver), even after the program stops, the user still needs
  to do "info threads" to pull an updated thread list. This, should
  most likely be addressed, so that GDB pulls the list itself, perhaps
  just before presenting a stop to the user.

With that in place, the need to delay "Program received signal FOO"
was actually caught by the manythreads.exp test.  Without that bit, I
was getting:

  [Thread 0x7ffff7f13700 (LWP 4499) exited]
  [New Thread 0x7ffff7f0b700 (LWP 4500)]
  ^C
  Program received signal SIGINT, Interrupt.
  [New Thread 0x7ffff7f03700 (LWP 4501)]           <<< new output
  [Switching to Thread 0x7ffff7f0b700 (LWP 4500)]
  __GI___nptl_death_event () at events.c:31
  31      {
  (gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1

That is, I was now getting "New Thread" lines after the "Program
received signal" line, and the test doesn't expect them.  As the
number of new threads discovered before and after the "Program
received signal" output is unbounded, it's much nicer to defer
"Program received signal" until after synching the thread list, thus
close to the "switching to thread" output and "current frame/source"
info:

  [Thread 0x7ffff7863700 (LWP 7647) exited]
  ^C[New Thread 0x7ffff786b700 (LWP 7648)]

  Program received signal SIGINT, Interrupt.
  [Switching to Thread 0x7ffff7fc4740 (LWP 6243)]
  __GI___nptl_create_event () at events.c:25
  25      {
  (gdb) PASS: gdb.threads/manythreads.exp: stop threads 1

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/
2014-10-02  Pedro Alves  <palves@redhat.com>

	* breakpoint.c (breakpoints_should_be_inserted_now): Use
	threads_are_executing.
	* breakpoint.h (breakpoints_should_be_inserted_now): Add
	describing comment.
	* gdbthread.h (threads_are_executing): Declare.
	(handle_signal_stop) <random signals>: Don't print about the
	signal here if stopping.
	(end_stepping_range): Don't notify observers here.
	(normal_stop): Update the thread list.  If stopped by a random
	signal or a stepping range ended, notify observers.
	* thread.c (threads_executing): New global.
	(init_thread_list): Clear 'threads_executing'.
	(set_executing): Set or clear 'threads_executing'.
	(threads_are_executing): New function.
	(update_threads_executing): New function.
	(update_thread_list): Use it.

gdb/testsuite/
2014-10-02  Pedro Alves  <palves@redhat.com>

	* gdb.threads/break-while-running.exp (test): Add new
	'update_thread_list' argument.  Skip "info threads" if false.
	(top level): Add new 'update_thread_list' axis.
 2014-10-02 10:08:00 +01:00
Don Breazeal
d83ad864a2 Refactor native follow-fork. 
This patch reorganizes the code that implements follow-fork and
detach-on-fork in preparation for implementation of those features for the
extended-remote target.  The function linux-nat.c:linux_child_follow_fork
contained target-independent code mixed in with target-dependent code.  The
target-independent pieces need to be accessible for the host-side
implementation of follow-fork for extended-remote Linux targets.

The changes are fairly mechanical.  A new routine, follow_fork_inferior,
is implemented in infrun.c, containing those parts of
linux_child_follow_fork that manage inferiors and the inferior list.  The
parts of linux_child_follow_fork that deal with LWPs and target-specifics
were left in-place.  Although the order of some operations was changed, the
resulting functionality was not.

Modifications were made to the other native target follow-fork functions,
inf_ttrace_follow_fork and inf_ptrace_follow_fork, that should allow them
to work with follow_fork_inferior.  Some other adjustments were necessary
in inf-ttrace.c.  The changes to inf-ttrace.c and inf-ptrace.c were not
tested.

gdb/ChangeLog:

	* inf-ptrace.c (inf_ptrace_follow_fork): Remove target-independent
	code so as to work with follow_fork_inferior.
	* inf-ttrace.c (inf_ttrace_follow_fork): Ditto.
	(inf_ttrace_create_inferior): Remove reference to
	inf_ttrace_vfork_ppid.
	(inf_ttrace_attach): Ditto.
	(inf_ttrace_detach): Ditto.
	(inf_ttrace_kill): Use current_inferior instead of
	inf_ttrace_vfork_ppid.
	(inf_ttrace_wait): Eliminate use of inf_ttrace_vfork_ppid, report
	TARGET_WAITKIND_VFORK_DONE event, delete HACK that switched the
	inferior away from the parent.
	* infrun.c (follow_fork): Call follow_fork_inferior instead of
	target_follow_fork.
	(follow_fork_inferior): New function.
	(follow_inferior_reset_breakpoints): Make function static.
	* infrun.h (follow_inferior_reset_breakpoints): Remove declaration.
	* linux-nat.c (linux_child_follow_fork): Move target-independent
	code to infrun.c:follow_fork_inferior.
 2014-09-30 11:01:57 -07:00
Pedro Alves
03d4695724 infrun.c:user_visible_resume_ptid: Don't check singlestep_breakpoints_inserted_p 
What matters for this function, is whether the user requested a
"step", for "set scheduler-locking step", not whether GDB is doing an
internal step for some reason.

 /* Return a ptid representing the set of threads that we will proceed,
    in the perspective of the user/frontend.  */
 extern ptid_t user_visible_resume_ptid (int step);

Therefore, the check for singlestep_breakpoints_inserted_p is actually
incorrect, and we end up applying schedlock more often on sss targets
than on non-sss targets.

Found by inspection while working on a patch that eliminates the
singlestep_breakpoints_inserted_p global.

Tested on x86_64 Fedora 20 on top of my 'software single-step on x86'
series.

gdb/
2014-09-25  Pedro Alves  <palves@redhat.com>

	* infrun.c (user_visible_resume_ptid): Don't check
	singlestep_breakpoints_inserted_p.
 2014-09-25 16:56:00 +01:00
Pedro Alves
7f89fd6519 infrun.c: comment/typo fixes 
gdb/
2014-09-25  Pedro Alves  <palves@redhat.com>

	* infrun.c (stepping_past_instruction_at)
	(clear_exit_convenience_vars): Point at infrun.h instead of
	inferior.h.
	(handle_signal_stop): Fix typo.
 2014-09-25 16:31:04 +01:00
Pedro Alves
a25a5a45ef Fix "breakpoint always-inserted off"; remove "breakpoint always-inserted auto" 
By default, GDB removes all breakpoints from the target when the
target stops and the prompt is given back to the user.  This is useful
in case GDB crashes while the user is interacting, as otherwise,
there's a higher chance breakpoints would be left planted on the
target.

But, as long as any thread is running free, we need to make sure to
keep breakpoints inserted, lest a thread misses a breakpoint.  With
that in mind, in preparation for non-stop mode, we added a "breakpoint
always-inserted on" mode.  This traded off the extra crash protection
for never having threads miss breakpoints, and in addition is more
efficient if there's a ton of breakpoints to remove/insert at each
user command (e.g., at each "step").

When we added non-stop mode, and for a period, we required users to
manually set "always-inserted on" when they enabled non-stop mode, as
otherwise GDB removes all breakpoints from the target as soon as any
thread stops, which means the other threads still running will miss
breakpoints.  The test added by this patch exercises this.

That soon revealed a nuisance, and so later we added an extra
"breakpoint always-inserted auto" mode, that made GDB behave like
"always-inserted on" when non-stop was enabled, and "always-inserted
off" when non-stop was disabled.  "auto" was made the default at the
same time.

In hindsight, this "auto" setting was unnecessary, and not the ideal
solution.  Non-stop mode does depends on breakpoints always-inserted
mode, but only as long as any thread is running.  If no thread is
running, no breakpoint can be missed.  The same is true for all-stop
too.  E.g., if, in all-stop mode, and the user does:

 (gdb) c&
 (gdb) b foo

That breakpoint at "foo" should be inserted immediately, but it
currently isn't -- currently it'll end up inserted only if the target
happens to trip on some event, and is re-resumed, e.g., an internal
breakpoint triggers that doesn't cause a user-visible stop, and so we
end up in keep_going calling insert_breakpoints.  The test added by
this patch also covers this.

IOW, no matter whether in non-stop or all-stop, if the target fully
stops, we can remove breakpoints.  And no matter whether in all-stop
or non-stop, if any thread is running in the target, then we need
breakpoints to be immediately inserted.  And then, if the target has
global breakpoints, we need to keep breakpoints even when the target
is stopped.

So with that in mind, and aiming at reducing all-stop vs non-stop
differences for all-stop-on-stop-of-non-stop, this patch fixes
"breakpoint always-inserted off" to not remove breakpoints from the
target until it fully stops, and then removes the "auto" setting as
unnecessary.  I propose removing it straight away rather than keeping
it as an alias, unless someone complains they have scripts that need
it and that can't adjust.

Tested on x86_64 Fedora 20.

gdb/
2014-09-22  Pedro Alves  <palves@redhat.com>

	* NEWS: Mention merge of "breakpoint always-inserted" modes "off"
	and "auto" merged.
	* breakpoint.c (enum ugll_insert_mode): New enum.
	(always_inserted_mode): Now a plain boolean.
	(show_always_inserted_mode): No longer handle AUTO_BOOLEAN_AUTO.
	(breakpoints_always_inserted_mode): Delete.
	(breakpoints_should_be_inserted_now): New function.
	(insert_breakpoints): Pass UGLL_INSERT to
	update_global_location_list instead of calling
	insert_breakpoint_locations manually.
	(create_solib_event_breakpoint_1): New, factored out from ...
	(create_solib_event_breakpoint): ... this.
	(create_and_insert_solib_event_breakpoint): Use
	create_solib_event_breakpoint_1 instead of calling
	insert_breakpoint_locations manually.
	(update_global_location_list): Change parameter type from boolean
	to enum ugll_insert_mode.  All callers adjusted.  Adjust to use
	breakpoints_should_be_inserted_now and handle UGLL_INSERT.
	(update_global_location_list_nothrow): Change parameter type from
	boolean to enum ugll_insert_mode.
	(_initialize_breakpoint): "breakpoint always-inserted" option is
	now a boolean command.  Update help text.
	* breakpoint.h (breakpoints_always_inserted_mode): Delete declaration.
	(breakpoints_should_be_inserted_now): New declaration.
	* infrun.c (handle_inferior_event) <TARGET_WAITKIND_LOADED>:
	Remove breakpoints_always_inserted_mode check.
	(normal_stop): Adjust to use breakpoints_should_be_inserted_now.
	* remote.c (remote_start_remote): Likewise.

gdb/doc/
2014-09-22  Pedro Alves  <palves@redhat.com>

	* gdb.texinfo (Set Breaks): Document that "set breakpoint
	always-inserted off" is the default mode now.  Delete
	documentation of "set breakpoint always-inserted auto".

gdb/testsuite/
2014-09-22  Pedro Alves  <palves@redhat.com>

	* gdb.threads/break-while-running.exp: New file.
	* gdb.threads/break-while-running.c: New file.
 2014-09-22 10:07:04 +01:00
Gary Benson
6d3d12ebef Include string.h in common-defs.h 
This commit includes string.h in common-defs.h and removes all other
inclusions.

gdb/
2014-08-07  Gary Benson  <gbenson@redhat.com>

	* common/common-defs.h: Include string.h.
	* aarch64-tdep.c: Do not include string.h.
	* ada-exp.y: Likewise.
	* ada-lang.c: Likewise.
	* ada-lex.l: Likewise.
	* ada-typeprint.c: Likewise.
	* ada-valprint.c: Likewise.
	* aix-thread.c: Likewise.
	* alpha-linux-tdep.c: Likewise.
	* alpha-mdebug-tdep.c: Likewise.
	* alpha-nat.c: Likewise.
	* alpha-osf1-tdep.c: Likewise.
	* alpha-tdep.c: Likewise.
	* alphanbsd-tdep.c: Likewise.
	* amd64-dicos-tdep.c: Likewise.
	* amd64-linux-tdep.c: Likewise.
	* amd64-nat.c: Likewise.
	* amd64-sol2-tdep.c: Likewise.
	* amd64fbsd-tdep.c: Likewise.
	* amd64obsd-tdep.c: Likewise.
	* arch-utils.c: Likewise.
	* arm-linux-nat.c: Likewise.
	* arm-linux-tdep.c: Likewise.
	* arm-tdep.c: Likewise.
	* arm-wince-tdep.c: Likewise.
	* armbsd-tdep.c: Likewise.
	* armnbsd-nat.c: Likewise.
	* armnbsd-tdep.c: Likewise.
	* armobsd-tdep.c: Likewise.
	* avr-tdep.c: Likewise.
	* ax-gdb.c: Likewise.
	* ax-general.c: Likewise.
	* bcache.c: Likewise.
	* bfin-tdep.c: Likewise.
	* breakpoint.c: Likewise.
	* build-id.c: Likewise.
	* buildsym.c: Likewise.
	* c-exp.y: Likewise.
	* c-lang.c: Likewise.
	* c-typeprint.c: Likewise.
	* c-valprint.c: Likewise.
	* charset.c: Likewise.
	* cli-out.c: Likewise.
	* cli/cli-cmds.c: Likewise.
	* cli/cli-decode.c: Likewise.
	* cli/cli-dump.c: Likewise.
	* cli/cli-interp.c: Likewise.
	* cli/cli-logging.c: Likewise.
	* cli/cli-script.c: Likewise.
	* cli/cli-setshow.c: Likewise.
	* cli/cli-utils.c: Likewise.
	* coffread.c: Likewise.
	* common/agent.c: Likewise.
	* common/buffer.c: Likewise.
	* common/buffer.h: Likewise.
	* common/common-utils.c: Likewise.
	* common/filestuff.c: Likewise.
	* common/filestuff.c: Likewise.
	* common/format.c: Likewise.
	* common/print-utils.c: Likewise.
	* common/rsp-low.c: Likewise.
	* common/signals.c: Likewise.
	* common/vec.h: Likewise.
	* common/xml-utils.c: Likewise.
	* core-regset.c: Likewise.
	* corefile.c: Likewise.
	* corelow.c: Likewise.
	* cp-abi.c: Likewise.
	* cp-name-parser.y: Likewise.
	* cp-support.c: Likewise.
	* cp-valprint.c: Likewise.
	* cris-tdep.c: Likewise.
	* d-exp.y: Likewise.
	* darwin-nat.c: Likewise.
	* dbxread.c: Likewise.
	* dcache.c: Likewise.
	* demangle.c: Likewise.
	* dicos-tdep.c: Likewise.
	* disasm.c: Likewise.
	* doublest.c: Likewise.
	* dsrec.c: Likewise.
	* dummy-frame.c: Likewise.
	* dwarf2-frame.c: Likewise.
	* dwarf2loc.c: Likewise.
	* dwarf2read.c: Likewise.
	* elfread.c: Likewise.
	* environ.c: Likewise.
	* eval.c: Likewise.
	* event-loop.c: Likewise.
	* exceptions.c: Likewise.
	* exec.c: Likewise.
	* expprint.c: Likewise.
	* f-exp.y: Likewise.
	* f-lang.c: Likewise.
	* f-typeprint.c: Likewise.
	* f-valprint.c: Likewise.
	* fbsd-nat.c: Likewise.
	* findcmd.c: Likewise.
	* findvar.c: Likewise.
	* fork-child.c: Likewise.
	* frame.c: Likewise.
	* frv-linux-tdep.c: Likewise.
	* frv-tdep.c: Likewise.
	* gdb.c: Likewise.
	* gdb_bfd.c: Likewise.
	* gdbarch.c: Likewise.
	* gdbarch.sh: Likewise.
	* gdbtypes.c: Likewise.
	* gnu-nat.c: Likewise.
	* gnu-v2-abi.c: Likewise.
	* gnu-v3-abi.c: Likewise.
	* go-exp.y: Likewise.
	* go-lang.c: Likewise.
	* go32-nat.c: Likewise.
	* guile/guile.c: Likewise.
	* guile/scm-auto-load.c: Likewise.
	* hppa-hpux-tdep.c: Likewise.
	* hppa-linux-nat.c: Likewise.
	* hppanbsd-tdep.c: Likewise.
	* hppaobsd-tdep.c: Likewise.
	* i386-cygwin-tdep.c: Likewise.
	* i386-dicos-tdep.c: Likewise.
	* i386-linux-tdep.c: Likewise.
	* i386-nto-tdep.c: Likewise.
	* i386-sol2-tdep.c: Likewise.
	* i386-tdep.c: Likewise.
	* i386bsd-tdep.c: Likewise.
	* i386gnu-nat.c: Likewise.
	* i386nbsd-tdep.c: Likewise.
	* i386obsd-tdep.c: Likewise.
	* i387-tdep.c: Likewise.
	* ia64-libunwind-tdep.c: Likewise.
	* ia64-linux-nat.c: Likewise.
	* inf-child.c: Likewise.
	* inf-ptrace.c: Likewise.
	* inf-ttrace.c: Likewise.
	* infcall.c: Likewise.
	* infcmd.c: Likewise.
	* inflow.c: Likewise.
	* infrun.c: Likewise.
	* interps.c: Likewise.
	* iq2000-tdep.c: Likewise.
	* irix5-nat.c: Likewise.
	* jv-exp.y: Likewise.
	* jv-lang.c: Likewise.
	* jv-typeprint.c: Likewise.
	* jv-valprint.c: Likewise.
	* language.c: Likewise.
	* linux-fork.c: Likewise.
	* linux-nat.c: Likewise.
	* lm32-tdep.c: Likewise.
	* m2-exp.y: Likewise.
	* m2-typeprint.c: Likewise.
	* m32c-tdep.c: Likewise.
	* m32r-linux-nat.c: Likewise.
	* m32r-linux-tdep.c: Likewise.
	* m32r-rom.c: Likewise.
	* m32r-tdep.c: Likewise.
	* m68hc11-tdep.c: Likewise.
	* m68k-tdep.c: Likewise.
	* m68kbsd-tdep.c: Likewise.
	* m68klinux-nat.c: Likewise.
	* m68klinux-tdep.c: Likewise.
	* m88k-tdep.c: Likewise.
	* machoread.c: Likewise.
	* macrocmd.c: Likewise.
	* main.c: Likewise.
	* mdebugread.c: Likewise.
	* mem-break.c: Likewise.
	* memattr.c: Likewise.
	* memory-map.c: Likewise.
	* mep-tdep.c: Likewise.
	* mi/mi-cmd-break.c: Likewise.
	* mi/mi-cmd-disas.c: Likewise.
	* mi/mi-cmd-env.c: Likewise.
	* mi/mi-cmd-stack.c: Likewise.
	* mi/mi-cmd-var.c: Likewise.
	* mi/mi-cmds.c: Likewise.
	* mi/mi-console.c: Likewise.
	* mi/mi-getopt.c: Likewise.
	* mi/mi-interp.c: Likewise.
	* mi/mi-main.c: Likewise.
	* mi/mi-parse.c: Likewise.
	* microblaze-rom.c: Likewise.
	* microblaze-tdep.c: Likewise.
	* mingw-hdep.c: Likewise.
	* minidebug.c: Likewise.
	* minsyms.c: Likewise.
	* mips-irix-tdep.c: Likewise.
	* mips-linux-tdep.c: Likewise.
	* mips-tdep.c: Likewise.
	* mips64obsd-tdep.c: Likewise.
	* mipsnbsd-tdep.c: Likewise.
	* mipsread.c: Likewise.
	* mn10300-linux-tdep.c: Likewise.
	* mn10300-tdep.c: Likewise.
	* monitor.c: Likewise.
	* moxie-tdep.c: Likewise.
	* mt-tdep.c: Likewise.
	* nat/linux-btrace.c: Likewise.
	* nat/linux-osdata.c: Likewise.
	* nat/linux-procfs.c: Likewise.
	* nat/linux-ptrace.c: Likewise.
	* nat/linux-waitpid.c: Likewise.
	* nbsd-tdep.c: Likewise.
	* nios2-linux-tdep.c: Likewise.
	* nto-procfs.c: Likewise.
	* nto-tdep.c: Likewise.
	* objc-lang.c: Likewise.
	* objfiles.c: Likewise.
	* opencl-lang.c: Likewise.
	* osabi.c: Likewise.
	* osdata.c: Likewise.
	* p-exp.y: Likewise.
	* p-lang.c: Likewise.
	* p-typeprint.c: Likewise.
	* parse.c: Likewise.
	* posix-hdep.c: Likewise.
	* ppc-linux-nat.c: Likewise.
	* ppc-sysv-tdep.c: Likewise.
	* ppcfbsd-tdep.c: Likewise.
	* ppcnbsd-tdep.c: Likewise.
	* ppcobsd-tdep.c: Likewise.
	* printcmd.c: Likewise.
	* procfs.c: Likewise.
	* prologue-value.c: Likewise.
	* python/py-auto-load.c: Likewise.
	* python/py-gdb-readline.c: Likewise.
	* ravenscar-thread.c: Likewise.
	* regcache.c: Likewise.
	* registry.c: Likewise.
	* remote-fileio.c: Likewise.
	* remote-m32r-sdi.c: Likewise.
	* remote-mips.c: Likewise.
	* remote-notif.c: Likewise.
	* remote-sim.c: Likewise.
	* remote.c: Likewise.
	* reverse.c: Likewise.
	* rs6000-aix-tdep.c: Likewise.
	* ser-base.c: Likewise.
	* ser-go32.c: Likewise.
	* ser-mingw.c: Likewise.
	* ser-pipe.c: Likewise.
	* ser-tcp.c: Likewise.
	* ser-unix.c: Likewise.
	* serial.c: Likewise.
	* sh-tdep.c: Likewise.
	* sh64-tdep.c: Likewise.
	* shnbsd-tdep.c: Likewise.
	* skip.c: Likewise.
	* sol-thread.c: Likewise.
	* solib-dsbt.c: Likewise.
	* solib-frv.c: Likewise.
	* solib-osf.c: Likewise.
	* solib-som.c: Likewise.
	* solib-spu.c: Likewise.
	* solib-target.c: Likewise.
	* solib.c: Likewise.
	* somread.c: Likewise.
	* source.c: Likewise.
	* sparc-nat.c: Likewise.
	* sparc-sol2-tdep.c: Likewise.
	* sparc-tdep.c: Likewise.
	* sparc64-tdep.c: Likewise.
	* sparc64fbsd-tdep.c: Likewise.
	* sparc64nbsd-tdep.c: Likewise.
	* sparcnbsd-tdep.c: Likewise.
	* spu-linux-nat.c: Likewise.
	* spu-multiarch.c: Likewise.
	* spu-tdep.c: Likewise.
	* stabsread.c: Likewise.
	* stack.c: Likewise.
	* std-regs.c: Likewise.
	* symfile.c: Likewise.
	* symmisc.c: Likewise.
	* symtab.c: Likewise.
	* target.c: Likewise.
	* thread.c: Likewise.
	* tilegx-linux-nat.c: Likewise.
	* tilegx-tdep.c: Likewise.
	* top.c: Likewise.
	* tracepoint.c: Likewise.
	* tui/tui-command.c: Likewise.
	* tui/tui-data.c: Likewise.
	* tui/tui-disasm.c: Likewise.
	* tui/tui-file.c: Likewise.
	* tui/tui-layout.c: Likewise.
	* tui/tui-out.c: Likewise.
	* tui/tui-regs.c: Likewise.
	* tui/tui-source.c: Likewise.
	* tui/tui-stack.c: Likewise.
	* tui/tui-win.c: Likewise.
	* tui/tui-windata.c: Likewise.
	* tui/tui-winsource.c: Likewise.
	* typeprint.c: Likewise.
	* ui-file.c: Likewise.
	* ui-out.c: Likewise.
	* user-regs.c: Likewise.
	* utils.c: Likewise.
	* v850-tdep.c: Likewise.
	* valarith.c: Likewise.
	* valops.c: Likewise.
	* valprint.c: Likewise.
	* value.c: Likewise.
	* varobj.c: Likewise.
	* vax-tdep.c: Likewise.
	* vaxnbsd-tdep.c: Likewise.
	* vaxobsd-tdep.c: Likewise.
	* windows-nat.c: Likewise.
	* xcoffread.c: Likewise.
	* xml-support.c: Likewise.
	* xstormy16-tdep.c: Likewise.
	* xtensa-linux-nat.c: Likewise.

gdb/gdbserver/
2014-08-07  Gary Benson  <gbenson@redhat.com>

	* server.h: Do not include string.h.
	* event-loop.c: Likewise.
	* linux-low.c: Likewise.
	* regcache.c: Likewise.
	* remote-utils.c: Likewise.
	* spu-low.c: Likewise.
	* utils.c: Likewise.
 2014-08-07 09:06:47 +01:00
Gary Benson
dccbb60975 Include gdb_assert.h in common-defs.h 
This commit includes gdb_assert.h in common-defs.h and removes all
other inclusions.

gdb/
2014-08-07  Gary Benson  <gbenson@redhat.com>

	* common/common-defs.h: Include gdb_assert.h.
	* aarch64-tdep.c: Do not include gdb_assert.h.
	* addrmap.c: Likewise.
	* aix-thread.c: Likewise.
	* alpha-linux-tdep.c: Likewise.
	* alpha-mdebug-tdep.c: Likewise.
	* alphanbsd-tdep.c: Likewise.
	* amd64-nat.c: Likewise.
	* amd64-tdep.c: Likewise.
	* amd64bsd-nat.c: Likewise.
	* amd64fbsd-nat.c: Likewise.
	* amd64fbsd-tdep.c: Likewise.
	* amd64nbsd-nat.c: Likewise.
	* amd64nbsd-tdep.c: Likewise.
	* amd64obsd-nat.c: Likewise.
	* amd64obsd-tdep.c: Likewise.
	* arch-utils.c: Likewise.
	* arm-tdep.c: Likewise.
	* armbsd-tdep.c: Likewise.
	* auxv.c: Likewise.
	* bcache.c: Likewise.
	* bfin-tdep.c: Likewise.
	* blockframe.c: Likewise.
	* breakpoint.c: Likewise.
	* bsd-kvm.c: Likewise.
	* bsd-uthread.c: Likewise.
	* buildsym.c: Likewise.
	* c-exp.y: Likewise.
	* c-lang.c: Likewise.
	* charset.c: Likewise.
	* cleanups.c: Likewise.
	* cli-out.c: Likewise.
	* cli/cli-decode.c: Likewise.
	* cli/cli-dump.c: Likewise.
	* cli/cli-logging.c: Likewise.
	* cli/cli-script.c: Likewise.
	* cli/cli-utils.c: Likewise.
	* coffread.c: Likewise.
	* common/common-utils.c: Likewise.
	* common/queue.h: Likewise.
	* common/signals.c: Likewise.
	* common/vec.h: Likewise.
	* complaints.c: Likewise.
	* completer.c: Likewise.
	* corelow.c: Likewise.
	* cp-abi.c: Likewise.
	* cp-name-parser.y: Likewise.
	* cp-namespace.c: Likewise.
	* cp-support.c: Likewise.
	* cris-tdep.c: Likewise.
	* dbxread.c: Likewise.
	* dictionary.c: Likewise.
	* doublest.c: Likewise.
	* dsrec.c: Likewise.
	* dummy-frame.c: Likewise.
	* dwarf2-frame-tailcall.c: Likewise.
	* dwarf2-frame.c: Likewise.
	* dwarf2expr.c: Likewise.
	* dwarf2loc.c: Likewise.
	* dwarf2read.c: Likewise.
	* eval.c: Likewise.
	* event-loop.c: Likewise.
	* exceptions.c: Likewise.
	* expprint.c: Likewise.
	* f-valprint.c: Likewise.
	* fbsd-nat.c: Likewise.
	* findvar.c: Likewise.
	* frame-unwind.c: Likewise.
	* frame.c: Likewise.
	* frv-tdep.c: Likewise.
	* gcore.c: Likewise.
	* gdb-dlfcn.c: Likewise.
	* gdb_bfd.c: Likewise.
	* gdbarch.c: Likewise.
	* gdbarch.sh: Likewise.
	* gdbtypes.c: Likewise.
	* gnu-nat.c: Likewise.
	* gnu-v3-abi.c: Likewise.
	* go-lang.c: Likewise.
	* guile/scm-exception.c: Likewise.
	* guile/scm-gsmob.c: Likewise.
	* guile/scm-lazy-string.c: Likewise.
	* guile/scm-math.c: Likewise.
	* guile/scm-pretty-print.c: Likewise.
	* guile/scm-safe-call.c: Likewise.
	* guile/scm-utils.c: Likewise.
	* guile/scm-value.c: Likewise.
	* h8300-tdep.c: Likewise.
	* hppa-hpux-nat.c: Likewise.
	* hppa-tdep.c: Likewise.
	* hppanbsd-tdep.c: Likewise.
	* hppaobsd-tdep.c: Likewise.
	* i386-darwin-nat.c: Likewise.
	* i386-darwin-tdep.c: Likewise.
	* i386-nto-tdep.c: Likewise.
	* i386-tdep.c: Likewise.
	* i386bsd-nat.c: Likewise.
	* i386fbsd-tdep.c: Likewise.
	* i386gnu-nat.c: Likewise.
	* i386nbsd-tdep.c: Likewise.
	* i386obsd-tdep.c: Likewise.
	* i387-tdep.c: Likewise.
	* ia64-libunwind-tdep.c: Likewise.
	* ia64-tdep.c: Likewise.
	* inf-ptrace.c: Likewise.
	* inf-ttrace.c: Likewise.
	* infcall.c: Likewise.
	* infcmd.c: Likewise.
	* infrun.c: Likewise.
	* inline-frame.c: Likewise.
	* interps.c: Likewise.
	* jv-lang.c: Likewise.
	* jv-typeprint.c: Likewise.
	* linux-fork.c: Likewise.
	* linux-nat.c: Likewise.
	* linux-thread-db.c: Likewise.
	* m32c-tdep.c: Likewise.
	* m32r-linux-nat.c: Likewise.
	* m32r-tdep.c: Likewise.
	* m68k-tdep.c: Likewise.
	* m68kbsd-nat.c: Likewise.
	* m68kbsd-tdep.c: Likewise.
	* m88k-tdep.c: Likewise.
	* machoread.c: Likewise.
	* macroexp.c: Likewise.
	* macrotab.c: Likewise.
	* maint.c: Likewise.
	* mdebugread.c: Likewise.
	* memory-map.c: Likewise.
	* mep-tdep.c: Likewise.
	* mi/mi-common.c: Likewise.
	* microblaze-tdep.c: Likewise.
	* mingw-hdep.c: Likewise.
	* mips-linux-nat.c: Likewise.
	* mips-linux-tdep.c: Likewise.
	* mips-tdep.c: Likewise.
	* mips64obsd-tdep.c: Likewise.
	* mipsnbsd-tdep.c: Likewise.
	* mn10300-linux-tdep.c: Likewise.
	* mn10300-tdep.c: Likewise.
	* moxie-tdep.c: Likewise.
	* mt-tdep.c: Likewise.
	* nat/linux-btrace.c: Likewise.
	* nat/linux-osdata.c: Likewise.
	* nat/linux-ptrace.c: Likewise.
	* nat/mips-linux-watch.c: Likewise.
	* nios2-linux-tdep.c: Likewise.
	* nios2-tdep.c: Likewise.
	* objc-lang.c: Likewise.
	* objfiles.c: Likewise.
	* obsd-nat.c: Likewise.
	* opencl-lang.c: Likewise.
	* osabi.c: Likewise.
	* parse.c: Likewise.
	* ppc-linux-nat.c: Likewise.
	* ppc-sysv-tdep.c: Likewise.
	* ppcfbsd-nat.c: Likewise.
	* ppcfbsd-tdep.c: Likewise.
	* ppcnbsd-nat.c: Likewise.
	* ppcnbsd-tdep.c: Likewise.
	* ppcobsd-nat.c: Likewise.
	* ppcobsd-tdep.c: Likewise.
	* printcmd.c: Likewise.
	* procfs.c: Likewise.
	* prologue-value.c: Likewise.
	* psymtab.c: Likewise.
	* python/py-lazy-string.c: Likewise.
	* python/py-value.c: Likewise.
	* regcache.c: Likewise.
	* reggroups.c: Likewise.
	* registry.c: Likewise.
	* remote-sim.c: Likewise.
	* remote.c: Likewise.
	* rs6000-aix-tdep.c: Likewise.
	* rs6000-tdep.c: Likewise.
	* s390-linux-tdep.c: Likewise.
	* score-tdep.c: Likewise.
	* ser-base.c: Likewise.
	* ser-mingw.c: Likewise.
	* sh-tdep.c: Likewise.
	* sh64-tdep.c: Likewise.
	* solib-darwin.c: Likewise.
	* solib-spu.c: Likewise.
	* solib-svr4.c: Likewise.
	* source.c: Likewise.
	* sparc-nat.c: Likewise.
	* sparc-sol2-tdep.c: Likewise.
	* sparc-tdep.c: Likewise.
	* sparc64-sol2-tdep.c: Likewise.
	* sparc64-tdep.c: Likewise.
	* sparc64fbsd-tdep.c: Likewise.
	* sparc64nbsd-tdep.c: Likewise.
	* sparc64obsd-tdep.c: Likewise.
	* sparcnbsd-tdep.c: Likewise.
	* sparcobsd-tdep.c: Likewise.
	* spu-multiarch.c: Likewise.
	* spu-tdep.c: Likewise.
	* stabsread.c: Likewise.
	* stack.c: Likewise.
	* symfile.c: Likewise.
	* symtab.c: Likewise.
	* target-descriptions.c: Likewise.
	* target-memory.c: Likewise.
	* target.c: Likewise.
	* tic6x-linux-tdep.c: Likewise.
	* tic6x-tdep.c: Likewise.
	* tilegx-linux-nat.c: Likewise.
	* tilegx-tdep.c: Likewise.
	* top.c: Likewise.
	* tramp-frame.c: Likewise.
	* tui/tui-out.c: Likewise.
	* tui/tui-winsource.c: Likewise.
	* ui-out.c: Likewise.
	* user-regs.c: Likewise.
	* utils.c: Likewise.
	* v850-tdep.c: Likewise.
	* valops.c: Likewise.
	* value.c: Likewise.
	* varobj.c: Likewise.
	* vax-nat.c: Likewise.
	* xml-syscall.c: Likewise.
	* xml-tdesc.c: Likewise.
	* xstormy16-tdep.c: Likewise.
	* xtensa-linux-nat.c: Likewise.
	* xtensa-tdep.c: Likewise.

gdb/gdbserver/
2014-08-07  Gary Benson  <gbenson@redhat.com>

	* server.h: Do not include gdb_assert.h.
 2014-08-07 09:06:45 +01:00
Pedro Alves
705096250d Always pass signals to the right thread 
Currently, GDB can pass a signal to the wrong thread in several
different but related scenarios.

E.g., if thread 1 stops for signal SIGFOO, the user switches to thread
2, and then issues "continue", SIGFOO is actually delivered to thread
2, not thread 1.  This obviously messes up programs that use
pthread_kill to send signals to specific threads.

This has been a known issue for a long while.  Back in 2008 when I
made stop_signal be per-thread (2020b7ab), I kept the behavior -- see
code in 'proceed' being removed -- wanting to come back to it later.
The time has finally come now.

The patch fixes this -- on resumption, intercepted signals are always
delivered to the thread that had intercepted them.

Another example: if thread 1 stops for a breakpoint, the user switches
to thread 2, and then issues "signal SIGFOO", SIGFOO is actually
delivered to thread 1, not thread 2, because 'proceed' first switches
to thread 1 to step over its breakpoint...  If the user deletes the
breakpoint before issuing "signal FOO", then the signal is delivered
to thread 2 (the current thread).

"signal SIGFOO" can be used for two things: inject a signal in the
program while the program/thread had stopped for none, bypassing
"handle nopass"; or changing/suppressing a signal the program had
stopped for.  These scenarios are really two faces of the same coin,
and GDB can't really guess what the user is trying to do.  GDB might
have intercepted signals in more than one thread even (see the new
signal-command-multiple-signals-pending.exp test).  At least in the
inject case, it's obviously clear to me that the user means to deliver
the signal to the currently selected thread, so best is to make the
command's behavior consistent and easy to explain.

Then, if the user is trying to suppress/change a signal the program
had stopped for instead of injecting a new signal, but, the user had
changed threads meanwhile, then she will be surprised that with:

  (gdb) continue
  Thread 1 stopped for signal SIGFOO.
  (gdb) thread 2
  (gdb) signal SIGBAR

... GDB actually delivers SIGFOO to thread 1, and SIGBAR to thread 2
(with scheduler-locking off, which is the default, because then
"signal" or any other resumption command resumes all threads).

So the patch makes GDB detect that, and ask for confirmation:

  (gdb) thread 1
  [Switching to thread 1 (Thread 10979)]
  (gdb) signal SIGUSR2
  Note:
    Thread 3 previously stopped with signal SIGUSR2, User defined signal 2.
    Thread 2 previously stopped with signal SIGUSR1, User defined signal 1.
  Continuing thread 1 (the current thread) with specified signal will
  still deliver the signals noted above to their respective threads.
  Continue anyway? (y or n)

All these scenarios are covered by the new tests.

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/
2014-07-25  Pedro Alves  <palves@redhat.com>

	* NEWS: Mention signal passing and "signal" command changes.
	* gdbthread.h (struct thread_suspend_state) <stop_signal>: Extend
	comment.
	* breakpoint.c (until_break_command): Adjust clear_proceed_status
	call.
	* infcall.c (run_inferior_call): Adjust clear_proceed_status call.
	* infcmd.c (proceed_thread_callback, continue_1, step_once)
	(jump_command): Adjust clear_proceed_status call.
	(signal_command): Warn if other thread that are resumed have
	signals that will be delivered.  Adjust clear_proceed_status call.
	(until_next_command, finish_command)
	(proceed_after_attach_callback, attach_command_post_wait)
	(attach_command): Adjust clear_proceed_status call.
	* infrun.c (proceed_after_vfork_done): Likewise.
	(proceed_after_attach_callback): Adjust comment.
	(clear_proceed_status_thread): Clear stop_signal if not in pass
	state.
	(clear_proceed_status_callback): Delete.
	(clear_proceed_status): New 'step' parameter.  Only clear the
	proceed status of threads the command being prepared is about to
	resume.
	(proceed): If passed in an explicit signal, override stop_signal
	with it.  Don't pass the last stop signal to the thread we're
	resuming.
	(init_wait_for_inferior): Adjust clear_proceed_status call.
	(switch_back_to_stepped_thread): Clear the signal if it should not
	be passed.
	* infrun.h (clear_proceed_status): New 'step' parameter.
	(user_visible_resume_ptid): Add comment.
	* linux-nat.c (linux_nat_resume_callback): Don't check whether the
	signal is in pass state.
	* remote.c (append_pending_thread_resumptions): Likewise.
	* mi/mi-main.c (proceed_thread): Adjust clear_proceed_status call.

gdb/doc/
2014-07-25  Pedro Alves  <palves@redhat.com>
	    Eli Zaretskii  <eliz@gnu.org>

	* gdb.texinfo (Signaling) <signal command>: Explain what happens
	with multi-threaded programs.

gdb/testsuite/
2014-07-25  Pedro Alves  <palves@redhat.com>

	* gdb.threads/signal-command-handle-nopass.c: New file.
	* gdb.threads/signal-command-handle-nopass.exp: New file.
	* gdb.threads/signal-command-multiple-signals-pending.c: New file.
	* gdb.threads/signal-command-multiple-signals-pending.exp: New file.
	* gdb.threads/signal-delivered-right-thread.c: New file.
	* gdb.threads/signal-delivered-right-thread.exp: New file.
 2014-07-25 16:57:31 +01:00
Yao Qi
b67a2c6fd4 Associate dummy_frame with ptid 
This patch is to add ptid into dummy_frame and extend frame_id to
dummy_frame_id (which has a ptid field).  With this change, GDB uses
dummy_frame_id (thread ptid and frame_id) to find the dummy frames.

Currently, dummy frames are looked up by frame_id, which isn't
accurate in non-stop or multi-process mode.  The test case
gdb.multi/dummy-frame-restore.exp shows the problem and this patch can
fix it.

Test dummy-frame-restore.exp makes two inferiors stop at
different functions, say, inferior 1 stops at f1 while inferior 2
stops at f2.  Set a breakpoint to a function, do the inferior call
in two inferiors, and GDB has two dummy frames of the same frame_id.
When the inferior call is finished, GDB will look up a dummy frame
from its stack/list and restore the inferior's regcache.  Two
inferiors are finished in different orders, the inferiors' states are
restored differently, which is wrong.  Running dummy-frame-restore.exp
under un-patched GDB, we'll get two fails:

FAIL: gdb.multi/dummy-frame-restore.exp: inf 2 first: after infcall: bt in inferior 2
FAIL: gdb.multi/dummy-frame-restore.exp: inf 2 first: after infcall: bt in inferior 1

With this patch applied, GDB will choose the correct dummy_frame to
restore for a given inferior, because ptid is considered when looking up
dummy frames.  Two fails above are fixed.

Regression tested on x86_64-linux, both native and gdbserver.

gdb:

2014-06-27  Yao Qi  <yao@codesourcery.com>

	* breakpoint.c (check_longjmp_breakpoint_for_call_dummy):
	Change parameter type to 'struct thread_info *'.  Caller
	updated.
	* breakpoint.h (check_longjmp_breakpoint_for_call_dummy):
	Update declaration.
	* dummy-frame.c (struct dummy_frame_id): New.
	(dummy_frame_id_eq): New function.
	(struct dummy_frame) <id>: Change its type to 'struct
	dummy_frame_id'.
	(dummy_frame_push): Add parameter ptid and save it in
	dummy_frame_id.
	(pop_dummy_frame_bpt): Use ptid of dummy_frame instead of
	inferior_ptid.
	(pop_dummy_frame): Assert that the ptid of dummy_frame equals
	to inferior_ptid.
	(lookup_dummy_frame): Change parameter type to 'struct
	dummy_frame_id *'.  Callers updated.  Call dummy_frame_id_eq
	instead of frame_id_eq.
	(dummy_frame_pop): Add parameter ptid.  Callers updated.
	Update comments.  Compose dummy_frame_id and pass it to
	lookup_dummy_frame.
	(dummy_frame_discard): Add parameter ptid.
	(dummy_frame_sniffer): Compose dummy_frame_id and call
	dummy_frame_id_eq instead of frame_id_eq.
	(fprint_dummy_frames): Print ptid.
	* dummy-frame.h: Remove comments.
	(dummy_frame_push): Add ptid in declaration.
	(dummy_frame_pop, dummy_frame_discard): Likewise.

gdb/testsuite:

2014-06-27  Yao Qi  <yao@codesourcery.com>

	* gdb.multi/dummy-frame-restore.exp: New.
	* gdb.multi/dummy-frame-restore.c: New.

gdb/doc:

2014-06-27  Yao Qi  <yao@codesourcery.com>

	* gdb.texinfo (Maintenance Commands): Update the output of
	'maint print dummy-frames' command.
 2014-06-27 20:06:56 +08:00
Yao Qi
4395285e33 Typo fix in signal_pass initialization 
When I read the code, I happen to see this:

   signal_pass = (unsigned char *)
     xmalloc (sizeof (signal_program[0]) * numsigs);
                      ^^^^^^^^^^^^^^
It is a typo, and this patch is to fix it.

gdb:

2014-06-26  Yao Qi  <yao@codesourcery.com>

	* infrun.c (_initialize_infrun): Replace "signal_program[0]"
	with "signal_pass[0]" in the initialization of signal_pass.
 2014-06-26 16:00:17 +08:00
Pedro Alves
034f788c5e Fix next over threaded execl with "set scheduler-locking step". 
Running gdb.threads/thread-execl.exp with scheduler-locking set to
"step" reveals a problem:

 (gdb) next^M
 [Thread 0x7ffff7fda700 (LWP 27168) exited]^M
 [New LWP 27168]^M
 [Thread 0x7ffff74ee700 (LWP 27174) exited]^M
 process 27168 is executing new program: /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.threads/thread-execl^M
 [Thread debugging using libthread_db enabled]^M
 Using host libthread_db library "/lib64/libthread_db.so.1".^M
 infrun.c:5225: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed.^M
 A problem internal to GDB has been detected,^M
 further debugging may prove unreliable.^M
 Quit this debugging session? (y or n) FAIL: gdb.threads/thread-execl.exp: schedlock step: get to main in new image (GDB internal error)

The assertion is correct.  The issue is that GDB is mistakenly trying
to switch back to an exited thread, that was previously stepping when
it exited.  This is exactly the sort of thing the test wants to make
sure doesn't happen:

	# Now set a breakpoint at `main', and step over the execl call.  The
	# breakpoint at main should be reached.  GDB should not try to revert
	# back to the old thread from the old image and resume stepping it

We don't see this bug with schedlock off only because a different
sequence of events makes GDB manage to delete the thread instead of
marking it exited.

This particular internal error can be fixed by making the loop over
all threads in switch_back_to_stepped_thread skip exited threads.
But, looking over other ALL_THREADS users, all either can or should be
skipping exited threads too.  So for simplicity, this patch replaces
ALL_THREADS with a new macro that skips exited threads itself, and
updates everything to use it.

Tested on x86_64 Fedora 20.

gdb/
2014-06-19  Pedro Alves  <palves@redhat.com>

	* gdbthread.h (ALL_THREADS): Delete.
	(ALL_NON_EXITED_THREADS): New macro.
	* btrace.c (btrace_free_objfile): Use ALL_NON_EXITED_THREADS
	instead of ALL_THREADS.
	* infrun.c (find_thread_needs_step_over)
	(switch_back_to_stepped_thread): Use ALL_NON_EXITED_THREADS
	instead of ALL_THREADS.
	* record-btrace.c (record_btrace_open)
	(record_btrace_stop_recording, record_btrace_close)
	(record_btrace_is_replaying, record_btrace_resume)
	(record_btrace_find_thread_to_move, record_btrace_wait): Likewise.
	* remote.c (append_pending_thread_resumptions): Likewise.
	* thread.c (thread_apply_all_command): Likewise.

gdb/testsuite/
2014-06-19  Pedro Alves  <palves@redhat.com>

	* gdb.threads/thread-execl.exp (do_test): New procedure, factored
	out from ...
	(top level): ... here.  Iterate running tests under different
	scheduler-locking settings.
 2014-06-19 11:59:03 +01:00
Tom Tromey
3977b71f1d constify struct block in some places 
This makes some spots in gdb, particularly general_symbol_info, use a
"const struct block", then fixes the fallout.

The justification is that, ordinarily, blocks ought to be readonly.
Note though that we can't add "const" in the blockvector due to block
relocation.  This can be done once blocks are made independent of the
program space.

2014-06-18  Tom Tromey  <tromey@redhat.com>

	* varobj.c (varobj_create): Update.
	* valops.c (value_of_this): Update.
	* tracepoint.c (add_local_symbols, scope_info): Update.
	* symtab.h (struct general_symbol_info) <block>: Now const.
	* symtab.c (skip_prologue_sal)
	(default_make_symbol_completion_list_break_on)
	(skip_prologue_using_sal): Update.
	* stack.h (iterate_over_block_locals)
	(iterate_over_block_local_vars): Update.
	* stack.c (print_frame_args): Update.
	(iterate_over_block_locals, iterate_over_block_local_vars): Make
	parameter const.
	(get_selected_block): Make return type const.
	* python/py-frame.c (frapy_block): Update.
	* python/py-block.c (gdbpy_block_for_pc): Update.
	* p-exp.y (%union) <bval>: Now const.
	* mi/mi-cmd-stack.c (list_args_or_locals): Update.
	* mdebugread.c (mylookup_symbol, parse_procedure): Update.
	* m2-exp.y (%union) <bval>: Now const.
	* linespec.c (get_current_search_block): Make return type const.
	(create_sals_line_offset, find_label_symbols): Update.
	* inline-frame.c (inline_frame_sniffer, skip_inline_frames):
	Update.
	(block_starting_point_at): Make "block" const.
	* infrun.c (insert_exception_resume_breakpoint): Make "b" const.
	(check_exception_resume): Update.
	* guile/scm-frame.c (gdbscm_frame_block): Update.
	* guile/scm-block.c (gdbscm_lookup_block): Update.
	* frame.h (get_frame_block): Update.
	(get_selected_block): Make return type const.
	* frame.c (frame_id_inner): Update.
	* f-valprint.c (info_common_command_for_block)
	(info_common_command): Update.
	* dwarf2loc.c (dwarf2_find_location_expression)
	(dwarf_expr_frame_base, dwarf2_compile_expr_to_ax)
	(locexpr_describe_location_piece): Update.
	* c-exp.y (%union) <bval>: Now const.
	* breakpoint.c (resolve_sal_pc): Update.
	* blockframe.c (get_frame_block):Make return type const.
	(get_pc_function_start, get_frame_function, find_pc_sect_function)
	(block_innermost_frame): Update.
	* block.h (blockvector_for_pc, blockvector_for_pc_sect)
	(block_for_pc, block_for_pc_sect): Update.
	* block.c (blockvector_for_pc_sect, blockvector_for_pc): Make
	'pblock' const.
	(block_for_pc_sect, block_for_pc): Make return type const.
	* ax-gdb.c (gen_expr): Update.
	* alpha-mdebug-tdep.c (find_proc_desc): Update.
	* ada-lang.c (ada_read_renaming_var_value): Make 'block' const.
	(ada_make_symbol_completion_list, ada_add_exceptions_from_frame)
	(ada_read_var_value): Update.
	* ada-exp.y (struct name_info) <block>: Now const.
	(%union): Likewise.
	(block_lookup): Constify.
 2014-06-18 08:16:52 -06:00
Luis Machado
a1aa2221cb Symptom: 
Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to
"child" and detach-on-fork set to "off", stepping or running past the fork
call results in the child process running to completion, when it should
just finish the single step.  In addition, the breakpoint is not removed
from the parent process, so if it is resumed it receives a SIGTRAP.

Cause:

No matter what the setting for detach-on-fork, when stepping past a fork,
the single-step breakpoint (step_resume_breakpoint) is not handled
correctly in the parent.  The SR breakpoint is cloned for the child
process, but before the clone is associated with the child it is treated as
a duplicate of the original, associated wth the parent.  This results in
the insertion state of the original SR breakpoint and the clone being
"swapped" by breakpoint.c:update_global_location_list, so that the clone is
marked as inserted.

In the case where the parent is not detached, the two breakpoints remain in
that state.  The breakpoint is never inserted in the child, because
although the cloned SR breakpoint is associated with the child, it is
marked as inserted.  When the child is resumed, it runs to completion.  The
breakpoint is never removed from the parent, so that if it is resumed after
the child exits, it gets a SIGTRAP.

Here is the sequence of events:

1) handle_inferior_event: FORK event is recognized.

2) handle_inferior_event: detach_breakpoints removes all breakpoints
from the child.

3) follow_fork: the parent SR breakpoint is cloned.  Part of this procedure
is to call update_global_location_list, which swaps the insertion state of
the original and cloned SR breakpoints as part of ensuring that duplicate
breakpoints are only inserted once.  At this point the original SR
breakpoint is not marked as inserted, and the clone is.  The breakpoint is
actually inserted in the parent but not the child.

4) follow_fork: the original breakpoint is deleted by calling
delete_step_resume_breakpoint.  Since the original is not marked as
inserted, the actual breakpoint remains in the parent process.
update_global_location_list is called again as part of the deletion.  The
clone is still associated with the parent, but since it is marked as
enabled and inserted, the breakpoint is left in the parent.

5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be
removed from the parent in target_detach, based on the cloned breakpoint
still associated with the parent.  Then the clone is no longer marked as
inserted.  In follow_inferior_reset_breakpoints the clone is associated
with the child, and can be inserted.

If detach-on-fork is 'off', the actual breakpoint in the parent is never
removed (although the breakpoint had been deleted from the list).  Since
the clone continues to be marked 'inserted', the SR breakpoint is never
inserted in the child.

Fix:

Set the cloned breakpoint as disabled from the moment it is created.  This
is done by modifying clone_momentary_breakpoint to take an additional
argument, LOC_ENABLED, which is used as the value of the
bp_location->enabled member.  The clone must be disabled at that point
because clone_momentary_breakpoint calls update_global_location_list, which
will swap treat the clone as a duplicate of the original breakpoint if it
is enabled.

All the calls to clone_momentary_breakpoint had to be modified to pass '1'
or '0'.  I looked at implementing an enum for the enabled member, but
concluded that readability would suffer because there are so many places it
is used as a boolean, e.g. "if (bl->enabled)".

In follow_inferior_reset_breakpoints the clone is set to enabled once it
has been associated with the child process.  With this, the bp_location
'inserted' member is maintained correctly throughout the follow-fork
procedure and the behavior is as expected.

The same treatment is given to the exception_resume_breakpoint when
following a fork.

Testing:

Ran 'make check' on Linux x64.

Along with the fix above, the coverage of the follow-fork test
gdb.base/foll-fork.exp was expanded to:

1) cover all the combinations of values for
   follow-fork-mode and detach-on-fork

2) make sure that both user breakpoints and
   single-step breakpoints are propagated
   correctly to the child

3) check that the inferior list has the
   expected contents after following the fork.

4) check that unfollowed, undetached inferiors
   can be resumed.

gdb/

2014-06-18  Don Breazeal  <donb@codesourcery.com>

	* breakpoint.c (set_longjmp_breakpoint): Call
	momentary_breakpoint_from_master with additional argument.
	(set_longjmp_breakpoint_for_call_dummy): Call
	momentary_breakpoint_from_master with additional argument.
	(set_std_terminate_breakpoint): Call
	momentary_breakpoint_from_master with additional argument.
	(momentary_breakpoint_from_master): Add argument to function
	definition and use it to initialize structure member flag.
	(clone_momentary_breakpoint): Call
	momentary_breakpoint_from_master with additional argument.
	* infrun.c (follow_inferior_reset_breakpoints): Clear structure
	member flags set in momentary_breakpoint_from_master.

gdb/testsuite/

2014-06-18  Don Breazeal  <donb@codesourcery.com>

	* gdb.base/foll-fork.exp (default_fork_parent_follow):
	Deleted procedure.
	(explicit_fork_parent_follow): Deleted procedure.
	(explicit_fork_child_follow): Deleted procedure.
	(test_follow_fork): New procedure.
	(do_fork_tests): Replace calls to deleted procedures with
	calls to test_follow_fork and reset GDB for subsequent
	procedure calls.
 2014-06-18 10:25:47 +01:00
Pedro Alves
a09dd4413d Running the current tree against my software-single-step-on-x86_64 
branch showed some extra assertions I have in place triggering.  Turns
out my previous change to 'resume' was incomplete, and we mishandle
the 'hw_step' / 'step' variable pair.  (I swear I had fixed this, but
I guess I lost that in some local branch...)

Tested on x86_64 Fedora 20.

gdb/
2014-05-29  Pedro Alves  <palves@redhat.com>

	* infrun.c (resume): Rename local 'hw_step' to 'entry_step'
	and make it const.  When a single-step decays to a continue,
	clear 'step', not 'hw_step'.  Pass whether the caller wanted
	to step to user_visible_resume_ptid, not what we ask the
	target to do.
 2014-05-29 22:17:20 +01:00
Pedro Alves
bdc36728ee infrun.c: simplify "end stepping range" code a bit. 
- all end_stepping_range callers also set stop_step.

 - all places that set stop_step call end_stepping_range and
   stop_waiting too.

IOW, all places where we handle "end stepping range" do:

      ecs->event_thread->control.stop_step = 1;
      end_stepping_range ();
      stop_waiting (ecs);

Factor that out into end_stepping_range itself.

Tested on x86_64 Fedora 20.

gdb/
2014-05-29  Pedro Alves  <palves@redhat.com>

	* infrun.c (process_event_stop_test, handle_step_into_function)
	(handle_step_into_function_backward): Adjust.
	Don't set the even thread's stop_step and call stop_waiting before
	calling end_stepping_range.  Instead do that ...
	(end_stepping_range): ... here.  Take an ecs pointer parameter.
 2014-05-29 18:16:06 +01:00
Pedro Alves
22bcd14b34 infrun.c: stop_stepping -> stop_waiting. 
stop_stepping is called even when we weren't stepping.  It's job really is:

  static void
  stop_waiting (struct execution_control_state *ecs)
  {
  ...
    /* Let callers know we don't want to wait for the inferior anymore.  */
    ecs->wait_some_more = 0;
  }

So rename it for clarity.

gdb/
2014-05-29  Pedro Alves  <palves@redhat.com>

	* infrun.c (stop_stepping): Rename to ...
	(stop_waiting): ... this.
	(proceed): Update comment.
	(process_event_stop_test, handle_inferior_event)
	(handle_signal_stop, handle_step_into_function)
	(handle_step_into_function_backward): Update.
 2014-05-29 18:08:11 +01:00
Pedro Alves
329ea57934 enable target async by default; separate MI and target notions of async 
This finally makes background execution commands possible by default.

However, in order to do that, there's one last thing we need to do --
we need to separate the MI and target notions of "async".  Unlike the
CLI, where the user explicitly requests foreground vs background
execution in the execution command itself (c vs c&), MI chose to treat
"set target-async" specially -- setting it changes the default
behavior of execution commands.

So, we can't simply "set target-async" default to on, as that would
affect MI frontends.  Instead we have to make the setting MI-specific,
and teach MI about sync commands on top of an async target.

Because the "target" word in "set target-async" ends up as a potential
source of confusion, the patch adds a "set mi-async" option, and makes
"set target-async" a deprecated alias.

Rather than make the targets always async, this patch introduces a new
"maint set target-async" option so that the GDB developer can control
whether the target is async.  This makes it simpler to debug issues
arising only in the synchronous mode; important because sync mode
seems unlikely to go away.

Unlike in previous revisions, "set target-async" does not affect this
new maint parameter.  The rationale for this is that then one can
easily run the test suite in the "maint set target-async off" mode and
have tests that enable mi-async fail just like they fail on
non-async-capable targets.  This emulation is exactly the point of the
maint option.

I had asked Tom in a previous iteration to split the actual change of
the target async default to a separate patch, but it turns out that
that is quite awkward in this version of the patch, because with MI
async and target async decoupled (unlike in previous versions), if we
don't flip the default at the same time, then just "set target-async
on" alone never actually manages to do anything.  It's best to not
have that transitory state in the tree.

Given "set target-async on" now only has effect for MI, the patch goes
through the testsuite removing it from non-MI tests.  MI tests are
adjusted to use the new and less confusing "mi-async" spelling.

2014-05-29  Pedro Alves  <palves@redhat.com>
	    Tom Tromey  <tromey@redhat.com>

	* NEWS: Mention "maint set target-async", "set mi-async", and that
	background execution commands are now always available.
	* target.h (target_async_permitted): Update comment.
	* target.c (target_async_permitted, target_async_permitted_1):
	Default to 1.
	(set_target_async_command): Rename to ...
	(maint_set_target_async_command): ... this.
	(show_target_async_command): Rename to ...
	(maint_show_target_async_command): ... this.
	(_initialize_target): Adjust.
	* infcmd.c (prepare_execution_command): Make extern.
	* inferior.h (prepare_execution_command): Declare.
	* infrun.c (set_observer_mode): Leave target async alone.
	* mi/mi-interp.c (mi_interpreter_init): Install
	mi_on_sync_execution_done as sync_execution_done observer.
	(mi_on_sync_execution_done): New function.
	(mi_execute_command_input_handler): Don't print the prompt if we
	just started a synchronous command with an async target.
	(mi_on_resume): Check sync_execution before printing prompt.
	* mi/mi-main.h (mi_async_p): Declare.
	* mi/mi-main.c: Include gdbcmd.h.
	(mi_async_p): New function.
	(mi_async, mi_async_1): New globals.
	(set_mi_async_command, show_mi_async_command, mi_async): New
	functions.
	(exec_continue): Call prepare_execution_command.
	(run_one_inferior, mi_cmd_exec_run, mi_cmd_list_target_features)
	(mi_execute_async_cli_command): Use mi_async_p.
	(_initialize_mi_main): Install "set mi-async".  Make
	"target-async" a deprecated alias.

2014-05-29  Pedro Alves  <palves@redhat.com>
	    Tom Tromey  <tromey@redhat.com>

	* gdb.texinfo (Non-Stop Mode): Remove "set target-async 1"
	from example.
	(Asynchronous and non-stop modes): Document '-gdb-set mi-async'.
	Mention that target-async is now deprecated.
	(Maintenance Commands): Document maint set/show target-async.

2014-05-29  Pedro Alves  <palves@redhat.com>
	    Tom Tromey  <tromey@redhat.com>

	* gdb.base/async-shell.exp: Don't enable target-async.
	* gdb.base/async.exp
	* gdb.base/corefile.exp (corefile_test_attach): Remove 'async'
	parameter.  Adjust.
	(top level): Don't test with "target-async".
	* gdb.base/dprintf-non-stop.exp: Don't enable target-async.
	* gdb.base/gdb-sigterm.exp: Don't test with "target-async".
	* gdb.base/inferior-died.exp: Don't enable target-async.
	* gdb.base/interrupt-noterm.exp: Likewise.
	* gdb.mi/mi-async.exp: Use "mi-async" instead of "target-async".
	* gdb.mi/mi-nonstop-exit.exp: Likewise.
	* gdb.mi/mi-nonstop.exp: Likewise.
	* gdb.mi/mi-ns-stale-regcache.exp: Likewise.
	* gdb.mi/mi-nsintrall.exp: Likewise.
	* gdb.mi/mi-nsmoribund.exp: Likewise.
	* gdb.mi/mi-nsthrexec.exp: Likewise.
	* gdb.mi/mi-watch-nonstop.exp: Likewise.
	* gdb.multi/watchpoint-multi.exp: Adjust comment.
	* gdb.python/py-evsignal.exp: Don't enable target-async.
	* gdb.python/py-evthreads.exp: Likewise.
	* gdb.python/py-prompt.exp: Likewise.
	* gdb.reverse/break-precsave.exp: Don't test with "target-async".
	* gdb.server/solib-list.exp: Don't enable target-async.
	* gdb.threads/thread-specific-bp.exp: Likewise.
	* lib/mi-support.exp: Adjust to use mi-async.
 2014-05-29 14:38:02 +01:00
Pedro Alves
92bcb5f949 Make display_gdb_prompt CLI-only. 
Enabling target-async by default will require implementing sync
execution on top of an async target, much like foreground command are
implemented on the CLI in async mode.

In order to do that, we will need better control of when to print the
MI prompt.  Currently the interp->display_prompt_p hook is all we
have, and MI just always returns false, meaning, make
display_gdb_prompt a no-op.  We'll need to be able to know to print
the MI prompt in some of the conditions that display_gdb_prompt is
called from the core, but not all.

This is all a litte twisted currently.  As we can see,
display_gdb_prompt is really CLI specific, so make the console
interpreters (console/tui) themselves call it.  To be able to do that,
and add a few different observers that the interpreters can use to
distinguish when or why the the prompt is being printed:

#1 - one called whenever a command is cancelled due to an error.
#2 - another for when a foreground command just finished.

In both cases, CLI wants to print the prompt, while MI doesn't.

MI will want to print the prompt in the second case when in a special
MI mode.

The display_gdb_prompt call in interp_set made me pause.  The comment
there reads:

  /* Finally, put up the new prompt to show that we are indeed here.
     Also, display_gdb_prompt for the console does some readline magic
     which is needed for the console interpreter, at least...  */

But, that looks very much like a no-op to me currently:

 - the MI interpreter always return false in the prompt hook, meaning
   actually display no prompt.

 - the interpreter used at that point is still quiet.  And the
   console/tui interpreters return false in the prompt hook if they're
   quiet, meaning actually display no prompt.

The only remaining possible use would then be the readline magic.  But
whatever that might have been, it's not reacheable today either,
because display_gdb_prompt returns early, before touching readline if
the interpreter returns false in the display_prompt_p hook.

Tested on x86_64 Fedora 20, sync and async modes.

gdb/
2014-05-29  Pedro Alves  <palves@redhat.com>

	* cli/cli-interp.c (cli_interpreter_display_prompt_p): Delete.
	(_initialize_cli_interp): Adjust.
	* event-loop.c: Include "observer.h".
	(start_event_loop): Notify 'command_error' observers instead of
	calling display_gdb_prompt.  Remove FIXME comment.
	* event-top.c (display_gdb_prompt): Remove call into the
	interpreters.
	* inf-loop.c: Include "observer.h".
	(inferior_event_handler): Notify 'command_error' observers instead
	of calling display_gdb_prompt.
	* infrun.c (fetch_inferior_event): Notify 'sync_execution_done'
	observers instead of calling display_gdb_prompt.
	* interps.c (interp_set): Don't call display_gdb_prompt.
	(current_interp_display_prompt_p): Delete.
	* interps.h (interp_prompt_p): Delete declaration.
	(interp_prompt_p_ftype): Delete.
	(struct interp_procs) <prompt_proc_p>: Delete field.
	(current_interp_display_prompt_p): Delete declaration.
	* mi-interp.c (mi_interpreter_prompt_p): Delete.
	(_initialize_mi_interp): Adjust.
	* tui-interp.c (tui_init): Install 'sync_execution_done' and
	'command_error' observers.
	(tui_on_sync_execution_done, tui_on_command_error): New
	functions.
	(tui_display_prompt_p): Delete.
	(_initialize_tui_interp): Adjust.

gdb/doc/
2014-05-29  Pedro Alves  <palves@redhat.com>

	* observer.texi (sync_execution_done, command_error): New
	subjects.
 2014-05-29 13:47:09 +01:00
Pedro Alves
fd664c9176 PR gdb/13860 - Make MI sync vs async output (closer to) the same. 
Ignoring expected and desired differences like whether the prompt is
output after *stoppped records, GDB MI output is still different in
sync and async modes.

In sync mode, when a CLI execution command is entered, the "reason"
field is missing in the *stopped async record.  And in async mode, for
some events, like program exits, the corresponding CLI output is
missing in the CLI channel.

Vis, diff between sync vs async modes:

   run
   ^running
   *running,thread-id="1"
   (gdb)
   ...
 - ~"[Inferior 1 (process 15882) exited normally]\n"
   =thread-exited,id="1",group-id="i1"
   =thread-group-exited,id="i1",exit-code="0"
 - *stopped
 + *stopped,reason="exited-normally"

   si
   ...
   (gdb)
   ~"0x000000000045e033\t29\t  memset (&args, 0, sizeof args);\n"
 - *stopped,frame=...,thread-id="1",stopped-threads="all",core="0"
 + *stopped,reason="end-stepping-range",frame=...,thread-id="1",stopped-threads="all",core="0"
   (gdb)

In addition, in both cases, when a MI execution command is entered,
and a breakpoint triggers, the event is sent to the console too.  But
some events like program exits have the CLI output missing in the CLI
channel:

   -exec-run
   ^running
   *running,thread-id="1"
   (gdb)
   ...
   =thread-exited,id="1",group-id="i1"
   =thread-group-exited,id="i1",exit-code="0"
 - *stopped
 + *stopped,reason="exited-normally"

We'll want to make background commands always possible by default.
IOW, make target-async be the default.  But, in order to do that,
we'll need to emulate MI sync on top of an async target.  That means
we'll have yet another combination to care for in the testsuite.

Rather than making the testsuite cope with all these differences, I
thought it better to just fix GDB to always have the complete output,
no matter whether it's in sync or async mode.

This is all related to interpreter-exec, and the corresponding uiout
switching.  (Typing a CLI command directly in MI is shorthand for
running it through -interpreter-exec console.)

In sync mode, when a CLI command is active, normal_stop is called when
the current interpreter and uiout are CLI's.  So print_XXX_reason
prints the stop reason to CLI uiout (only), and we don't show it in
MI.

In async mode the stop event is processed when we're back in the MI
interpreter, so the stop reason is printed directly to the MI uiout.

Fix this by making run control event printing roughly independent of
whatever is the current interpreter or uiout.  That is, move these
prints to interpreter observers, that know whether to print or be
quiet, and if printing, which uiout to print to.  In the case of the
console/tui interpreters, only print if the top interpreter.  For MI,
always print.

Breakpoint hits / normal stops are already handled similarly -- MI has
a normal_stop observer that prints the event to both MI and the CLI,
though that could be cleaned up further in the direction of this
patch.

This also makes all of:

 (gdb) foo
and
 (gdb) interpreter-exec MI "-exec-foo"
and
 (gdb)
 -exec-foo
and
 (gdb)
 -interpreter-exec console "foo"

print as expected.

Tested on x86_64 Fedora 20, sync and async modes.

gdb/
2014-05-29  Pedro Alves  <palves@redhat.com>

	PR gdb/13860
	* cli/cli-interp.c: Include infrun.h and observer.h.
	(cli_uiout, cli_interp): New globals.
	(cli_on_signal_received, cli_on_end_stepping_range)
	(cli_on_signal_exited, cli_on_exited, cli_on_no_history): New
	functions.
	(cli_interpreter_init): Install them as 'end_stepping_range',
	'signal_received' 'signal_exited', 'exited' and 'no_history'
	observers.
	(_initialize_cli_interp): Remove cli_interp local.
	* infrun.c (handle_inferior_event): Call the several stop reason
	observers instead of printing the stop reason directly.
	(end_stepping_range): New function.
	(print_end_stepping_range_reason, print_signal_exited_reason)
	(print_exited_reason, print_signal_received_reason)
	(print_no_history_reason): Make static, and add an uiout
	parameter.  Print to that instead of to CURRENT_UIOUT.
	* infrun.h (print_end_stepping_range_reason)
	(print_signal_exited_reason, print_exited_reason)
	(print_signal_received_reason print_no_history_reason): New
	declarations.
	* mi/mi-common.h (struct mi_interp): Rename 'uiout' field to
	'mi_uiout'.
	<cli_uiout>: New field.
	* mi/mi-interp.c (mi_interpreter_init): Adjust.  Create the new
	uiout for CLI output.  Install 'signal_received',
	'end_stepping_range', 'signal_exited', 'exited' and 'no_history'
	observers.
	(find_mi_interpreter, mi_interp_data, mi_on_signal_received)
	(mi_on_end_stepping_range, mi_on_signal_exited, mi_on_exited)
	(mi_on_no_history): New functions.
	(ui_out_free_cleanup): Delete function.
	(mi_on_normal_stop): Don't allocate a new uiout for CLI output,
	instead use the one already stored in the MI interpreter data.
	(mi_ui_out): Adjust.
	* tui/tui-interp.c: Include infrun.h and observer.h.
	(tui_interp): New global.
	(tui_on_signal_received, tui_on_end_stepping_range)
	(tui_on_signal_exited, tui_on_exited)
	(tui_on_no_history): New functions.
	(tui_init): Install them as 'end_stepping_range',
	'signal_received' 'signal_exited', 'exited' and 'no_history'
	observers.
	(_initialize_tui_interp): Delete tui_interp local.

gdb/doc/
2014-05-29  Pedro Alves  <palves@redhat.com>

	PR gdb/13860
	* observer.texi (signal_received, end_stepping_range)
	(signal_exited, exited, no_history): New observer subjects.

gdb/testsuite/
2014-05-29  Pedro Alves  <palves@redhat.com>

	PR gdb/13860
	* gdb.mi/mi-cli.exp: Always expect "end-stepping-range" stop
	reason, even in sync mode.
 2014-05-29 13:09:45 +01:00