Unify ctf_fetch_registers and tfile_fetch_registers

Functions ctf_fetch_registers and tfile_fetch_registers have some
duplicated code about guessing the PC in regcache.  Sometimes, we
may change one function and forget to update the other one, like this
https://www.sourceware.org/ml/gdb-patches/2014-01/msg00292.html

This patch is to move the duplicated code into a new function
tracefile_fetch_registers, and let both ctf_fetch_registers and
tfile_fetch_registers call it.

gdb:

2014-04-22  Yao Qi  <yao@codesourcery.com>

	* tracefile-tfile.c (tfile_fetch_registers): Move the bottom to ...
	* tracefile.c (tracefile_fetch_registers): ... it.  New function.
	* tracefile.h (tracefile_fetch_registers): Declare.
	* ctf.c (ctf_fetch_registers): Remove the bottom.  Call
	tracefile_fetch_registers.
Check tracefile is generated by binary execution

In gdb.trace/tfile.exp, we execute binary to generate tracefile,

  remote_exec target "$binfile"

however, this fails on bare metal target.  This patch is to
handle binary execution failure by running binary in GDB.
The binary will do some io operation to generate tracefile, so
we need a check 'target_info exists gdb,nofileio'.

This patch is to check whether tracefile is generated.  tfile.exp can
be skipped if generation is failed, while test_tfind_tfile in
mi-traceframe-changed.exp is skipped if generated failed.  The rest of
the mi-traceframe-changed.exp can still be executed, because on some
bare metal targets, the remote stub supports tracepoint but doesn't
support fileio.

gdb/testsuite:

2014-04-22  Yao Qi  <yao@codesourcery.com>

	* lib/trace-support.exp (generate_tracefile): New procedure.
	* gdb.trace/tfile.exp: Skip the test if generate_tracefile
	return 0.
	* gdb.trace/mi-traceframe-changed.exp: Invoke test_tfind_tfile
	if generate_tracefile returns 1.
bfd/elfnn-aarch64.c: Remove elfNN_aarch64_section_flags

This function seems to be a left over from some previous
functionality that no longer exists - the comment above seems to
make no sense with the current code. Remove the function as it
breaks handling of SystemTap static probe note sections.

bfd/ChangeLog:

2014-04-22  Will Newton  <will.newton@linaro.org>

	* elfnn-aarch64.c (elfNN_aarch64_section_flags): Remove
	function.  (elf_backend_section_flags): Remove define.
Fix build problem on 32-bit hosts with the recent patch for PR 16821.

	PR ld/16821
	* peXXigen.c (abs_finder): Fix for 32-bit host builds.
Add a note to the GDB/NEWS file mentioning that the ARM simulator now
supports instruction tracing with or without disassembly alongside.

	* NEWS: Mention that ARM sim now supports tracing.
Remove support for the (deprecated) openrisc and or32 configurations and replace
with support for the new or1k configuration.
Another fix for building on a 32-bit host.

	PR ld/16821
	* peXXigen.c (_bfd_XXi_swap_sym_out): Fix for 32-bit hosts.
Add tests for PR ld/16846

	PR ld/16846
	* ld-plugin/lto.exp (lto_link_tests): Add tests for PR ld/16846.
	* ld-plugin/pr16846a.c: New file.
	* ld-plugin/pr16846b.c: Likewise.
	* ld-plugin/pr16846c.c: Likewise.
Fix Nios II assembler self-test mode.

2014-04-22  Sandra Loosemore  <sandra@codesourcery.com>

	gas/
	* config/tc-nios2.c (nios2_consume_arg): Add case for 'E' to
	unbreak self-test mode.

	gas/testsuite/
	* gas/nios2/selftest.s: New.
	* gas/nios2/selftest.d: New.
Make gdb_continue_to_breakpoint fail quickly on internal errors.

This switches the gdb_continue_to_breakpoint routine to use
gdb_test_multiple instead of send_gdb/gdb_expect, so that an internal
error is detected immediately, instead of failing on timeout.

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

	* lib/gdb.exp (gdb_continue_to_breakpoint): Use gdb_test_multiple
	instead of send_gdb/gdb_expect.
Consecutive step-overs trigger internal error.

If a thread trips on a breakpoint that needs stepping over just after
finishing a step over, GDB currently fails an assertion.  This is a
regression caused by the "Handle multiple step-overs." patch
(99619beac6252113fed212fdb9e1ab97bface423) at
https://sourceware.org/ml/gdb-patches/2014-02/msg00765.html.

 (gdb) x /4i $pc
 => 0x400540 <main+4>:   movl   $0x0,0x2003da(%rip)        # 0x600924 <i>
    0x40054a <main+14>:  movl   $0x1,0x2003d0(%rip)        # 0x600924 <i>
    0x400554 <main+24>:  movl   $0x2,0x2003c6(%rip)        # 0x600924 <i>
    0x40055e <main+34>:  movl   $0x3,0x2003bc(%rip)        # 0x600924 <i>
 (gdb) PASS: gdb.base/consecutive-step-over.exp: get breakpoint addresses
 break *0x40054a
 Breakpoint 2 at 0x40054a: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 23.
 (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 1: set breakpoint
 condition $bpnum condition
 (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 1: set condition
 break *0x400554
 Breakpoint 3 at 0x400554: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 24.
 (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 2: set breakpoint
 condition $bpnum condition
 (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 2: set condition
 break *0x40055e
 Breakpoint 4 at 0x40055e: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 25.
 (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 3: set breakpoint
 condition $bpnum condition
 (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 3: set condition
 break 27
 Breakpoint 5 at 0x400568: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 27.
 (gdb) continue
 Continuing.
 ../../src/gdb/infrun.c:5200: internal-error: switch_back_to_stepped_thread: Assertion `!tp->control.trap_expected' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 FAIL: gdb.base/consecutive-step-over.exp: continue to breakpoint: break here (GDB internal error)

The assertion fails, because the code is not expecting that the event
thread itself might need another step over.  IOW, not expecting that
TP in:

     tp = find_thread_needs_step_over (stepping_thread != NULL,
                                      stepping_thread);

could be the event thread.

A small fix for this would be to clear the event thread's
trap_expected earlier, before asserting.  But looking deeper, although
currently_stepping_or_nexting_callback's intention is finding the
thread that is doing a step/next, it also returns the thread that is
doing a step-over dance, with trap_expected set.  If there ever was a
reason for that (it was I who added
currently_stepping_or_nexting_callback , but I can't recall why I put
trap_expected there in the first place), the only remaining reason
nowadays is to aid in implementing switch_back_to_stepped_thread's
assertion that is now triggering, by piggybacking on the walk over all
threads, thus avoiding a separate walk.  This is quite obscure, and I
think we can do even better, by merging the walks that look for the
stepping thread, and the walk that looks for some thread that might
need a step over.

Tested on x86_64 Fedora 17, native and gdbserver, and also native on
top of my "software single-step on x86_64" series.

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

	* infrun.c (schedlock_applies): New function, factored out from
	find_thread_needs_step_over.
	(find_thread_needs_step_over): Use it.
	(switch_back_to_stepped_thread): Always clear trap_expected if the
	step over is finished.  Return early if scheduler locking applies.
	Look for the stepping thread and a potential step-over thread with
	a single loop.
	(currently_stepping_or_nexting_callback): Delete.

2014-04-22  Pedro Alves  <palves@redhat.com>

	* gdb.base/consecutive-step-over.c: New file.
	* gdb.base/consecutive-step-over.exp: New file.
Fix alignment for the first section frag on xtensa

Linking object files produced by partial linking with link-time
relaxation enabled sometimes fails with the following error message:

dangerous relocation: call8: misaligned call target: (.text.unlikely+0x63)

This happens because no basic block with an XTENSA_PROP_ALIGN flag in the
property table is generated for the first basic block, even if the
.align directive is present.
It was believed that the first frag alignment could be derived from the
section alignment, but this was not implemented for the partial linking
case: after partial linking first frag of a section may become not
first, but no additional alignment frag is inserted before it.
Basic block for such frag may be merged with previous basic block into
extended basic block during relaxation pass losing its alignment
restrictions.

Fix this by always recording alignment for the first section frag.

2014-04-22  Max Filippov  <jcmvbkbc@gmail.com>

gas/
    * config/tc-xtensa.c (xtensa_handle_align): record alignment for the
    first section frag.

gas/testsuite/
    * gas/xtensa/all.exp: Add test for the first section frag alignment.
    * gas/xtensa/first_frag_align.d: First section frag alignment expected
    dump.
    * gas/xtensa/first_frag_align.s: First section frag alignment test
    source.
daily update