Fix ARM machine state testcase failures

When running GDB's reverse debugging testsuite against a few ARM
multilibs, i noticed failures in the machinestate* testcases.

Further investigation showed that push and pop instruction encodings
A1 and A2 were not being handled properly, thus we missed saving
important contents from registers and memory. When going backwards,
such contents were not restored and thus we ended up with a corrupted
state that did not correspond to the real values we had at a
particular point in time.

Attached is a patch that fixes around 36 failures for both
gdb.reverse/machinestate.exp and
gdb.reverse/machinestate-precsave.exp testcases, making them fully
pass. This is for both armv7 and armv4. I still see failures for
armv4 thumb though, so it needs a bit more investigation.

I see no regressions due to this patch for armv7, armv7 thumb, armv4
and armv4 thumb.

gdb/ChangeLog:

	* arm-tdep.c (INSN_S_L_BIT_NUM): Document.
	(arm_record_ld_st_imm_offset): Reimplement to cover all
	load/store cases for ARM opcode 010.
	(arm_record_ld_st_multiple): Reimplement to cover all
	load/store cases for ARM opcode 100.
Fix trace file fails on powerpc64

I see the following fails on powerpc64-linux,

(gdb) target tfile tfile-basic.tf^M
warning: Uploaded tracepoint 1 has no source location, using raw address^M
Tracepoint 1 at 0x10012358^M
Created tracepoint 1 for target's tracepoint 1 at 0x10012358.^M
(gdb) PASS: gdb.trace/tfile.exp: target tfile tfile-basic.tf
info trace^M
Num     Type           Disp Enb Address            What^M
1       tracepoint     keep y   0x0000000010012358 <write_basic_trace_file>^M
        installed on target^M
(gdb) FAIL: gdb.trace/tfile.exp: info tracepoints on trace file

-target-select tfile tfile-basic.tf^M
=thread-group-started,id="i1",pid="1"^M
=thread-created,id="1",group-id="i1"^M
&"warning: Uploaded tracepoint 1 has no source location, using raw address\n"^M
=breakpoint-created,bkpt={number="1",type="tracepoint",disp="keep",enabled="y",
addr="0x0000000010012358",at="<write_basic_trace_file>",thread-groups=["i1"],
times="0",installed="y",original-location="*0x10012358"}^M
~"Created tracepoint 1 for target's tracepoint 1 at 0x10012358.\n"^M
^connected^M
(gdb) ^M
FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: select trace file

These fails are caused by writing function descriptor address into trace
file instead of function address.  This patch is to teach tfile.c to
write function address on powerpc64 target.  With this patch applied,
fails in tfile.exp and mi-traceframe-changed.exp are fixed.  Is it
OK?

gdb/testsuite:

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

	* gdb.trace/tfile.c (adjust_function_address)
	[__powerpc64__ && _CALL_ELF != 2]: Get function address from
	function descriptor.
This patch closes a potential security hole in applications that use
the bfd library to parse binaries containing maliciously corrupt section
group headers.

	PR binutils/17510
	* elf.c (setup_group): Improve handling of corrupt group
	sections.
Fix a seg-fault in strings and other binutuils when parsing a corrupt PE
executable with an invalid value in the NumberOfRvaAndSizes field of the
AOUT header.

	PR binutils/17512
	* peXXigen.c (_bfd_XXi_swap_aouthdr_in): Handle corrupt binaries
	with an invalid value for NumberOfRvaAndSizes.
This fixes more seg-faults in tools like "strings" and "objdump" when
presented with corrupt binaries.

	PR binutils/17512
	* elf.c (bfd_section_from_shdr): Detect and warn about ELF
	binaries with a group of sections linked by the string table
	indicies.
	* peXXigen.c (pe_print_edata): Detect out of range rvas and
	entry counts for the Export Address table, Name Pointer table
	 and Ordinal table.
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.
daily update