Fix info mem command for 32 bits host/64 bits target

When running gdb on 32 bits host for 64 bits target, info mem command
truncates the target address to 32 bits, like in the example below
	(gdb) set architecture powerpc:common64
	(gdb) mem 0x100000000 0x200000000 rw
	(gdb) info mem
	1   y  	0x0000000000000000 0x0000000000000000 rw nocache

gdb/ChangeLog:

        PR gdb/15684
        * memattr.c (mem_info_command): Remove "unsigned long" casts.

Signed-off-by: Catalin Udma <catalin.udma@freescale.com>
Use PTRACE_SINGLESTEP_ONE when single-stepping one thread.

Currently, when we receive a request to single-step one single thread
(Eg, when single-stepping out of a breakpoint), we use the
PTRACE_SINGLESTEP pthread request, which does single-step
the corresponding thread, but also resumes execution of all
other threads in the inferior.

This causes problems when debugging programs where another thread
receives multiple debug events while trying to single-step a specific
thread out of a breakpoint (with infrun traces turned on):

    (gdb) continue
    Continuing.
    infrun: clear_proceed_status_thread (Thread 126)
    [...]
    infrun: clear_proceed_status_thread (Thread 142)
    [...]
    infrun: clear_proceed_status_thread (Thread 146)
    infrun: clear_proceed_status_thread (Thread 125)
    infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT, step=0)
    infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 142] at 0x10684838
    infrun: wait_for_inferior ()
    infrun: target_wait (-1, status) =
    infrun:   42000 [Thread 146],
    infrun:   status->kind = stopped, signal = GDB_SIGNAL_REALTIME_34
    infrun: infwait_normal_state
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x10a187f4
    infrun: context switch
    infrun: Switching context from Thread 142 to Thread 146
    infrun: random signal (GDB_SIGNAL_REALTIME_34)
    infrun: switching back to stepped thread
    infrun: Switching context from Thread 146 to Thread 142
    infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 142] at 0x10684838
    infrun: prepare_to_wait
    [...handling of similar events for threads 145, 144 and 143 snipped...]
    infrun: prepare_to_wait
    infrun: target_wait (-1, status) =
    infrun:   42000 [Thread 146],
    infrun:   status->kind = stopped, signal = GDB_SIGNAL_REALTIME_34
    infrun: infwait_normal_state
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x10a187f4
    infrun: context switch
    infrun: Switching context from Thread 142 to Thread 146
    ../../src/gdb/inline-frame.c:339: internal-error: skip_inline_frames: Assertion `find_inline_frame_state (ptid) == NULL' failed.

What happens is that GDB keeps sending requests to resume one specific
thread, and keeps receiving debugging events for other threads.
Things break down when the one of the other threads receives a debug
event for the second time (thread 146 in the example above).

This patch fixes the problem by making sure that only one thread
gets resumed, thus preventing the other threads from generating
an unexpected event.

gdb/gdbserver/ChangeLog:

        * lynx-low.c (lynx_resume): Use PTRACE_SINGLESTEP_ONE if N == 1.
        Remove FIXME comment about assumption about N.
	* Makefile.in (check-gdb.%): Restore.
	* README: Mention it.
Check corrupt input

	PR ld/17713
	* elflink.c (_bfd_elf_gc_mark_rsec): Check corrupt input.
python extended prompt: Use os.getcwd() instead of os.getcwdu()

It seems like using os.getcwdu() here is wrong both for Python 2 and Python 3.

For Python 2, this returns a 'unicode' object, which tries to get concatenated
to a 'str' object in substitute_prompt. The implicit conversion works when the
unicode string contains no accent. When it does contain an accent though,
displaying the prompt results in the following error:

(gdb) set extended-prompt \w
...
  File "/home/simark/build/binutils-gdb-python2/gdb/data-directory/python/gdb/prompt.py", line 138, in substitute_prompt
    result += str(cmd(arg))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 49: ordinal not in range(128)

When using os.getcwd() instead, it works correctly. I suppose that Python does
the necessary decoding internally.

For Python 3, this method simply does not exist. It works fine with os.getcwd().

gdb/ChangeLog:

	* python/lib/gdb/prompt.py (_prompt_pwd): Use os.getcwd() instead of
	os.getcwdu().
Fix build with Python 3.4 (PR python/16784)

The type of the function pointer PyOS_ReadlineFunctionPointer (part of the
Python C API), which we use, slightly changed starting with Python 3.4. The
signature went from

PyAPI_DATA(char) *(*PyOS_ReadlineFunctionPointer)(FILE *, FILE *, char *);

to

PyAPI_DATA(char) *(*PyOS_ReadlineFunctionPointer)(FILE *, FILE *, const char *);

The parameter that changed is the prompt text.

This commits adjust gdb accordingly by making the prompt_arg parameter
const, as well as the fallouts of that. I needed to rework how
annotations are added to the prompt, since the it is now const. If
annotations are enabled, it will make a copy of the prompt overwrite the
prompt variable that is used throughout the function. Otherwise, no copy
is done and the original prompt_arg value is passed.

I changed the signature of deprecated_readline_hook. I would've changed any
user of it, but it seems like nothing is using it,

Built-tested with python 2.7.x, 3.3.y and 3.4.z.

gdb/ChangeLog:

	* defs.h (gdb_readline): Constify argument.
	(gdb_readline_wrapper): Same.
	(command_line_input): Same.
	(deprecated_readline_hook): Same.
	* top.c (deprecated_readline_hook): Same.
	(gdb_readline): Same.
	(gdb_readline_wrapper): Same.
	(command_line_input): Constify argument. Pass prompt to
	called functions instead of local_prompt, overwriting prompt
	if using annotations.
	* event-top.h (display_gdb_prompt): Constify argument.
	* event-top.c (display_gdb_prompt): Same.
	* python/py-gdb-readline.c (gdbpy_readline_wrapper): Constify
	argument if building with Python 3.4 and up.

Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
testsuite: expect possible pagination when starting gdb

When gdb starts, the lines that appear before the first prompt may get
paginated if the terminal in which the tests are ran is too small (in
terms of rows). These lines include the welcome/license message and
possibly more, such as "Reading symbols from...". Pagination is disabled
right after gdb is started (with "set height 0"), but this output happens
before we are able to set height.

If these lines get paginated, gdb waits for the user to press enter and
the test harness waits for gdb to print its prompt, resulting in a
deadlock.

My first idea was to launch gdb with --quiet. However, some lines are
still printed ("Reading symbols from...", some more stuff when attaching
with --pid, etc).

The proposed solution simply expects that pagination can occur after
starting gdb. If this is the case, it sends a "\n" and loops.

gdb/testsuite/Changelog:

	* lib/gdb.exp (default_gdb_start): After starting gdb, loop
	as long as we get pagination notifications.
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.
Automatic date update in version.in
Merge dg-extract-results.{sh,py} from GCC upstream

It has been a while since we don't sync this file with GCC upstream,
and in the meantime some interesting things have happened.  The most
interesting is the inclusion of a new dg-extract-results.py which is
apparently faster than its shell equivalent.

This merge will probably fix the bug described in

  <https://sourceware.org/ml/gdb-patches/2014-12/msg00421.html>

Though I am still proposing the patch for upstream GCC.  Once it gets
accepted, I will merge it too.

OK to apply?

gdb/testsuite/ChangeLog:
2014-12-15  Sergio Durigan Junior  <sergiodj@redhat.com>

	Merge dg-extract-results.{sh,py} from GCC upstream (r210243,
	r210637, r210913, r211666, r215400, r215817).

	2014-05-08  Richard Sandiford  <rdsandiford@googlemail.com>
		* dg-extract-results.py: New file.
		* dg-extract-results.sh: Use it if the environment seems
		suitable.

	2014-05-20  Richard Sandiford  <rdsandiford@googlemail.com>

		* dg-extract-results.py (parse_run): Handle warnings that
		are printed before a test harness is run.

	2014-05-25  Richard Sandiford  <rdsandiford@googlemail.com>

		* dg-extract-results.py (Named): Remove __cmp__ method.
		(output_variation): Use a key to sort variation.harnesses.

	2014-06-14  Richard Sandiford  <rdsandiford@googlemail.com>

		* dg-extract-results.py: For Python 3, force sys.stdout to
		handle surrogate escape sequences.
		(safe_open): New function.
		(output_segment, main): Use it.

	2014-09-19  Segher Boessenkool  <segher@kernel.crashing.org>

		* dg-extract-results.py (Prog.result_re): Include options
		in test name.

	2014-10-02  Segher Boessenkool  <segher@kernel.crashing.org>

		* dg-extract-results.py (output_variation): Always sort if
		do_sum.