This patch fixes a flaw in the SREC parser which could cause a stack overflow
and potential secuiryt breach.

	PR binutils/17510
	* srec.c (srec_bad_byte): Increase size of buf to allow for
	negative values.
	(srec_scan): Use an unsigned char buffer to hold header bytes.
Workaround remote targets that report an empty list to qfThreadInfo

In https://sourceware.org/ml/gdb-patches/2014-10/msg00652.html, Sandra
shows a target that was broken by the recent update_thread_list
optimization:

 (gdb) target remote qa8-centos32-cs:10514
 ...
 (gdb) continue
 Continuing.
 Cannot execute this command without a live selected thread.
 (gdb)

The error means that the current thread is in "exited" state when the
continue command is processed.  The root of the problem was found
here:

 > Sending packet: $Hg0#df...Packet received:
 ...
 > Sending packet: $?#3f...Packet received: S00
 > Sending packet: $qfThreadInfo#bb...Packet received: l
 > Sending packet: $Hc-1#09...Packet received:
 > Sending packet: $qC#b4...Packet received: unset

This target doesn't really support threads (no thread indication in
stop reply packets; no support for qC), but then supports
qfThreadInfo, and returns an empty thread list to GDB.

See https://sourceware.org/ml/gdb-patches/2014-10/msg00665.html for
why the target does that.

As remote_update_thread_list deletes threads from GDB's list that are
not found in the thread list that the target reports, the result is
that GDB deletes the "fake" main thread that GDB added itself.  (As
that thread is currently selected, it is marked "exited" instead of
being deleted straight away.)

This commit avoids deleting the main thread in this scenario.

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

	* remote.c (remote_thread_alive): New, factored out from ...
	(remote_thread_alive): ... this.
	(remote_update_thread_list): Bail out before deleting threads if
	the target returned an empty list, and, the current thread has a
	magic/fake ptid.
update bug numbers (GNATS -> Bugzilla) in a few signal related tests

This makes it easier to find the bugs in Bugzilla.

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

	* gdb.base/sigaltstack.exp: Update to use Bugzilla bug numbers
	instead of GNATS numbers.
	* gdb.base/sigbpt.exp: Likewise.
	* gdb.base/siginfo.exp: Likewise.
	* gdb.base/sigstep.exp: Likewise.
gdb.base/sigstep.exp: cleanup and make it easier to extend

Hacking on sigstep.exp, I found it harder to understand and extend
than ideal.

 - GDB is currently not restarted between the different
   tests/combinations in the file, and some parts of the tests' setup
   are done on the top level, and shared between tests.  It's not
   trivial to understand which breakpoints each test procedure expects
   to be set or not set.  And it's not trivial to disable parts of the
   test if you want quickly try out just a subset of the tests
   (running the whole file takes a bit).

 - Because GDB is currently not restarted between tests, if some test
   triggers a ptrace/kernel bug, the following tests may end up with
   cascading fails.  That makes it hard to add a test to cover a
   kernel bug that isn't fixed yet, with a xfail/kfail.  E.g,. note
   how with kernels with bug gdb/8744 (stepi over sigreturn syscall
   exits program) the test program exits, and nothing restarts it
   afterwards...

 - The manual test message prefix management gets a bit in the way.
   Nowadays, we have with_test_prefix which makes it simpler.

 - 'i' is used as parameter name in the various procedures, meaning
   'the command the test', which isn't as obvious as it could.

This commit addresses all that.

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

	* gdb.base/sigstep.exp: Use build_executable instead of
	prepare_for_testing.
	(top level): Move code that starts GDB, runs to main and creates a
	display to ...
	(restart): ... this new procedure.
	(top level): Move backtrace from signal handler test to ...
	(validate_backtrace): ... this new procedure.
	(advance, advancei): Rename parameter from 'i' to 'cmd'.  Use
	with_test_prefix.  Always restart GDB.
	(skip_to_handler): Rename parameter from 'i' to 'cmd'.  Use
	with_test_prefix.  Always restart GDB.  No need to delete
	breakpoints after the test.
	(test_skip_handler): Remove prefix parameter.
	(skip_over_handler, breakpoint_to_handler)
	(breakpoint_to_handler_entry, breakpoint_over_handler): Rename
	parameter from 'i' to 'cmd'.  Use with_test_prefix.  Always
	restart GDB.  No need to delete breakpoints after the test.
	(top level): Use foreach to call the test procedures with
	different commands.
More fixes for corrupt binaries crashing the binutils.

	PR binutils/17512
	* elf.c (bfd_section_from_shdr): Allocate and free the recursion
	detection table on a per-bfd basis.
	* peXXigen.c (pe_print_edata): Handle binaries with a truncated
	export table.
Test for PR gdb/17511, spurious SIGTRAP after stepping into+in signal handler

I noticed that when I single-step into a signal handler with a
pending/queued signal, the following single-steps while the program is
in the signal handler leave $eflags.TF set.  That means subsequent
continues will trap after one instruction, resulting in a spurious
SIGTRAP being reported to the user.

This is a kernel bug; I've reported it to kernel devs (turned out to
be a known bug).  I'm seeing it on x86_64 Fedora 20 (Linux
3.16.4-200.fc20.x86_64), and I was told it's still not fixed upstream.

This commit extends gdb.base/sigstep.exp to cover this use case,
xfailed.

Here's what the bug looks like:

 (gdb) start
 Temporary breakpoint 1, main () at si-handler.c:48
 48        setup ();
 (gdb) next
 50        global = 0; /* set break here */

Let's queue a signal, so we can step into the handler:

 (gdb) handle SIGUSR1
 Signal        Stop      Print   Pass to program Description
 SIGUSR1       Yes       Yes     Yes             User defined signal 1
 (gdb) queue-signal SIGUSR1

TF is not set:

 (gdb) display $eflags
 1: $eflags = [ PF ZF IF ]

Now step into the handler -- "si" does PTRACE_SINGLESTEP+SIGUSR1:

 (gdb) si
 sigusr1_handler (sig=0) at si-handler.c:31
 31      {
 1: $eflags = [ PF ZF IF ]

No TF yet.  But another single-step...

 (gdb) si
 0x0000000000400621      31      {
 1: $eflags = [ PF ZF TF IF ]

... ends up with TF left set.  This results in PTRACE_CONTINUE
trapping after each instruction is executed:

 (gdb) c
 Continuing.

 Program received signal SIGTRAP, Trace/breakpoint trap.
 0x0000000000400624 in sigusr1_handler (sig=0) at si-handler.c:31
 31      {
 1: $eflags = [ PF ZF TF IF ]

 (gdb) c
 Continuing.

 Program received signal SIGTRAP, Trace/breakpoint trap.
 sigusr1_handler (sig=10) at si-handler.c:32
 32        global = 0;
 1: $eflags = [ PF ZF TF IF ]
 (gdb)

Note that even another PTRACE_SINGLESTEP does not fix it:

 (gdb) si
 33      }
 1: $eflags = [ PF ZF TF IF ]
 (gdb)

Eventually, it gets "fixed" by the rt_sigreturn syscall, when
returning out of the handler:

 (gdb) bt
 #0  sigusr1_handler (sig=10) at si-handler.c:33
 #1  <signal handler called>
 #2  main () at si-handler.c:50
 (gdb) set disassemble-next-line on
 (gdb) si
 0x0000000000400632      33      }
    0x0000000000400631 <sigusr1_handler+17>:     5d      pop    %rbp
 => 0x0000000000400632 <sigusr1_handler+18>:     c3      retq
 1: $eflags = [ PF ZF TF IF ]
 (gdb)
 <signal handler called>
 => 0x0000003b36a358f0 <__restore_rt+0>: 48 c7 c0 0f 00 00 00    mov    $0xf,%rax
 1: $eflags = [ PF ZF TF IF ]
 (gdb) si
 <signal handler called>
 => 0x0000003b36a358f7 <__restore_rt+7>: 0f 05   syscall
 1: $eflags = [ PF ZF TF IF ]
 (gdb)
 main () at si-handler.c:50
 50        global = 0; /* set break here */
 => 0x000000000040066b <main+9>: c7 05 cb 09 20 00 00 00 00 00   movl   $0x0,0x2009cb(%rip)        # 0x601040 <global>
 1: $eflags = [ PF ZF IF ]
 (gdb)

The bug doesn't happen if we instead PTRACE_CONTINUE into the signal
handler -- e.g., set a breakpoint in the handler, queue a signal, and
"continue".

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

	PR gdb/17511
	* gdb.base/sigstep.c (handler): Add a few more writes to 'done'.
	* gdb.base/sigstep.exp (other_handler_location): New global.
	(advance): Support stepping into the signal handler, and running
	commands while in the handler.
	(in_handler_map): New global.
	(top level): In the advance test, add combinations for getting
	into the handler with stepping commands, and for running commands
	in the handler.  Add comment descripting the advancei tests.
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.
daily update