Fix paginate-*.exp races

Jan pointed out in
<https://sourceware.org/ml/gdb-patches/2014-07/msg00553.html> that
these testcases have racy results:

  gdb.base/double-prompt-target-event-error.exp
  gdb.base/paginate-after-ctrl-c-running.exp
  gdb.base/paginate-bg-execution.exp
  gdb.base/paginate-execution-startup.exp
  gdb.base/paginate-inferior-exit.exp

This is easily reproducible with "read1" from:

  [reproducer for races of expect incomplete reads]
  http://sourceware.org/bugzilla/show_bug.cgi?id=12649

The '-notransfer -re "<return>" { exp_continue }' trick in the current
tests doesn't actually work.

The issue that led to the -notransfer trick was that

  "---Type <return> to continue, or q <return> to quit---"

has two "<return>"s.  If one wants gdb_test_multiple to not hit the
built-in "<return>" match that results in FAIL, one has to expect the
pagination prompt in chunks, first up to the first "<return>", then
again, up to the second.  Something around these lines:

  gdb_test_multiple "" $test {
      -re "<return>" {
	  exp_continue
      }
      -re "to quit ---" {
	  pass $test
      }
  }

The intent was for -notransfer+exp_continue to make expect fetch more
input, and rerun the matches against the now potentially fuller
buffer, and then eventually the -re that includes the full pagination
prompt regex would match instead (because it's listed higher up, it
would match first).  But, once that "<return>" -notransfer -re
matches, it keeps re-matching forever.  It seems like with
exp_continue, expect immediately retries matching, instead of first
reading in more data into the buffer, if available.

Fix this like I should have done in the first place.  There's actually
no good reason for gdb_test_multiple to only match "<return>".  We can
make gdb_test_multiple expect the whole pagination prompt text
instead, which is store in the 'pagination_prompt' global (similar to
'gdb_prompt').  Then a gdb_test_multiple caller that doesn't want the
default match to trigger, because it wants to see one pagination
prompt, does simply:

  gdb_test_multiple "" $test {
      -re "$pagination_prompt$" {
	  pass $test
      }
  }

which is just like when we don't want the default $gdb_prompt match
within gdb_test_multiple to trigger, like:

  gdb_test_multiple "" $test {
      -re "$gdb_prompt $" {
	  pass $test
      }
  }

Tested on x86_64 Fedora 20.  In addition, I've let the racy tests run
all in parallel in a loop for 30 minutes, and they never failed.

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

	* gdb.base/double-prompt-target-event-error.exp
	(cancel_pagination_in_target_event): Remove '-notransfer <return>'
	match.
	(cancel_pagination_in_target_event): Rework double prompt
	detection.
	* gdb.base/paginate-after-ctrl-c-running.exp
	(test_ctrlc_while_target_running_paginates): Remove '-notransfer
	<return>' match.
	* gdb.base/paginate-bg-execution.exp
	(test_bg_execution_pagination_return)
	(test_bg_execution_pagination_cancel): Remove '-notransfer
	<return>' matches.
	* gdb.base/paginate-execution-startup.exp
	(test_fg_execution_pagination_return)
	(test_fg_execution_pagination_cancel): Remove '-notransfer
	<return>' matches.
	* gdb.base/paginate-inferior-exit.exp
	(test_paginate_inferior_exited): Remove '-notransfer <return>'
	match.
	* lib/gdb-utils.exp (string_to_regexp): Move here from lib/gdb.exp.
	* lib/gdb.exp (pagination_prompt): Run text through
	string_to_regexp.
	(gdb_test_multiple): Match $pagination_prompt instead of
	"<return>".
	(string_to_regexp): Move to lib/gdb-utils.exp.
Clarify the address and pointer conversions on AVR.

This patch adds additional comments about the conversion of addresses to
pointers and vice-versa on AVR.

Special conversion needs to be done when dealing with an address in the
flash address space, where both code and read-only data can be stored.
Code and data pointers to flash are not addressed the same way:

A code pointer is 16 bit addressed.  A data pointer is 8 bit addressed,
even if the data is in flash.

2014-07-25  Pierre Langlois  <pierre.langlois@embecosm.com>

	* avr-tdep.c (avr_address_to_pointer): Clarify the conversion in the
	comments.
	(avr_pointer_to_address): Likewise.
properly parenthesize two macros

I happened to notice that a couple of macros in target.h weren't
properly using parens and as a result had a strange definition.

This patch adds the parens and then fixes the macros to be written as
must have been intended.

Tested by rebuilding.
I'm pushing this as obvious.

2014-07-25  Tom Tromey  <tromey@redhat.com>

	* target.h (target_stopped_data_address)
	(target_watchpoint_addr_within_range): Use "->", not ".".  Fix
	parentheses.
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.
fix build: update clear_proceed_status callers

A previous patch added a new parameter to clear_proceed_status, but
forgot to update a few callers.

Tested by building on x86_64 Fedora 20, with --enable-targets=all.

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

	* go32-nat.c (go32_create_inferior): Pass 0 to clear_proceed_status.
	* monitor.c (monitor_create_inferior): Likewise.
	* remote-m32r-sdi.c (m32r_create_inferior): Likewise.
	* remote-sim.c (gdbsim_create_inferior): Likewise.
	* solib-irix.c (irix_solib_create_inferior_hook): Likewise.
	* solib-osf.c (osf_solib_create_inferior_hook): Likewise.
	* windows-nat.c (do_initial_windows_stuff): Likewise.
remove using_exec_ops global

This removes the using_exec_ops global from exec.c, in favor of
querying the target stack directly using target_is_pushed.  This is
more in keeping with other code in gdb, and is also more future-proof
as it is more multi-target-ready.

Built and regtested on x86-64 Fedora 20.

2014-07-25  Tom Tromey  <tromey@redhat.com>

	* exec.c (using_exec_ops): Remove.
	(exec_close_1): Update.  Remove extraneous block, reindent.
	(add_target_sections): Use target_is_pushed.
MIPS: Respect the "set mips compression" command

This fixes gdbarch matching, making sure one for the opposite compressed
ISA variation is not chosen.  That in turn makes "set mips compression"
work; right now the setting sticks to the initial value, either inferred
from the ELF header of the binary first loaded or the default value if
no binary has been used.  This only affects debugging with no symbol
table available or no binary chosen at all, as otherwise symbol
annotations determine the compressed ISA variation.

	* mips-tdep.c (mips_gdbarch_init): Also check the compressed ISA
	variation in gdbarch matching.
Add a .gitattributes file for use with git-merge-changelog

Individual users will still have to:

 1. Install git-merge-changelog

 2. Set up the merge driver in their git config

See gnulib's lib/git-merge-changelog.c [1] for details.

For example, I:

 1. Patched Debian's gnulib package to build git-merge-changelog, and
    sent the patch to the Debian maintainer, who then proceeded to not
    only accept my patch but even write a *manpage* for
    git-merge-changelog! (Let's hear it for Ian Beckwith.)

    So now, I can install it simply by running "apt-get install
    git-merge-changelog".  (Except, of course, that I already have it
    installed from when I was testing my patch.)

 2. Did step (2) from .gitattributes

With this patch applied and the above two steps done by whatever means
you deem best, you can say goodbye to merge conflicts in ChangeLog
files -- at least *IF* people stop renaming the danged things, anyway.

If you don't do step 2, you will continue to suffer from ChangeLog
merge conflicts exactly as before, whether or not you did step 1.

If you do step 2 but not step 1, git will likely start complaining
that it can't find any "git-merge-changelog" to run.

[1]: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c

[Note: The docs for git-merge-changelog (the comments at the top) say
that you need a .gitattributes in every directory.  The docs are wrong.
Ignore the docs.  Well, not the whole docs; just that part.

You really only need one at the top level, since .gitattributes uses
the same pattern matching rules as .gitignore, which match files in
any subdirectory unless you prefix the pattern with a "/", as
explained in the gitignore(5) manpage.]
daily update