testsuite: Fix runaway attach processes

I have started seeing occasional runaway 'attach' processes these days.
I cannot be certain it is really caused by this patch, for example
grep 'FAIL.*cmdline attach run' does not show anything in my logs.

But as I remember this 'attach' runaway process always happened in GDB (but
I do not remember it in the past months) I think it would be most safe to just
solve it forever by [attached].

gdb/testsuite/ChangeLog
2014-09-12  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* gdb.base/attach.c: Include unistd.h.
	(main): Call alarm.  Add label postloop.
	* gdb.base/attach.exp (do_attach_tests): Use gdb_get_line_number,
	gdb_breakpoint, gdb_continue_to_breakpoint.
	(test_command_line_attach_run): Kill ${testpid} in one exit path.
PR tdep/17379: Fix internal-error when stack pointer is invalid.

The problem is that rs6000_frame_cache attempts to read the stack backchain via
read_memory_unsigned_integer, which throws an exception if the stack pointer is
invalid.  With this patch, it calls safe_read_memory_integer instead, which
doesn't throw an exception and allows for safe handling of that situation.

gdb/ChangeLog
2014-09-12  Edjunior Barbosa Machado  <emachado@linux.vnet.ibm.com>
	    Ulrich Weigand  <uweigand@de.ibm.com>

	PR tdep/17379
	* rs6000-tdep.c (rs6000_frame_cache): Use safe_read_memory_integer
	instead of read_memory_unsigned_integer.

gdb/testcase/ChangeLog
2014-09-12  Edjunior Barbosa Machado  <emachado@linux.vnet.ibm.com>

	PR tdep/17379
	* gdb.arch/powerpc-stackless.S: New file.
	* gdb.arch/powerpc-stackless.exp: New file.
Add mips*-img-elf* target triple.

/
	* configure.ac: Add mips*-img-elf* target triple.
	* configure: Regenerate.

bfd/
	* config.bfd: Add mips*-img-elf* target triple.

gas/
	* configure.tgt: Add mips*-img-elf* target triple.

gas/testsuite/
	* gas/mips/mips.exp: Add mips*-img-elf* target triple.

binutils/testsuite/
	* binutils-all/objcopy.exp: Add mips*-img-elf* target triple.
	* binutils-all/readelf.exp: Likewise.

ld/
	* configure.tgt: Add mips*-img-elf* target triple.

ld/testsuite/
	* ld-mips-elf/mips-elf.exp: Add support for mips*-img-elf* target
	triple.
gas: fix bumping to architectures >v9 in sparc64-* targets.

This patch fixes two related problems:

- By default gas is supposed to bump the current architecture
  (starting with v6) as it finds "higher" instructions as the
  assembling progresses.  There are four possible cases depending on
  the usage of the -A and -bump options:

  (a) No -A and -bump are specified.  In this case max_architecture
      must be the highest architecture not conflicting with the
      default architecture.  The default opcode architecture is
      indirectly set in configure.tgt and is "v9" in sparc64 systems
      (from "v9-64").  Thus the maximum architecture in sparc64
      systems must be "v9b".  No warnings are echoed when the assembly
      of an instruction bumps the current architecture.

  (b) Only -bump is specified.  This is like (a) but warnings are
      always issued when the assembly of an instruction bumps the
      current architecture.

  (c) Only -A is specified.  In this case bumping to a new
      architecture is an error.

  (d) Both -A and -bump are specified.  In this case max_architecture
      must be the highest architecture not conflicting with the
      default architecture, but warnings are only to be issued when
      bumping to an architecture higher than the architecture selected
      in the -A option.

  `max_architecture' is a global variable defined in tc-sparc.c which
  is initialized to the opcode architecture corresponding to the
  default architecture ("sparclite" for sparc-* targets and "v9" for
  sparc64-* targets).  Then in `md_begin' it is set to the highest
  non-conflicting architecture, but only when both -A and -bump are
  specified.

  Thus (a) does not work:

    $ echo "fzero %f0" | as
    {standard input}: Assembler messages:
    {standard input}:1: Error: Architecture mismatch on "fzero".
    {standard input}:1:  (Requires v9a|v9b; requested architecture is v9.)

  Neither (b):

    $ echo "fzero %f0" | as -bump
    {standard input}: Assembler messages:
    {standard input}:1: Error: Architecture mismatch on "fzero".
    {standard input}:1:  (Requires v9a|v9b; requested architecture is v9.)

  Only (d) does:

    $ echo "fzero %f0" | as -Av9 -bump
    {standard input}: Assembler messages:
    {standard input}:1: Warning: architecture bumped from "v6" to "v9a" on "fzero"

  This patch fixes that function to "upgrade" `max_architecture' also
  in the (a) and (b) cases.

  Note that this problem becomes apparent only in sparc64-* targets
  because in sparc-* targets the default architecture is the "higher"
  among the 32bit architectures ("sparclite").

- Gas maintains a set of hardware capabilities associated with each
  gas architecture, in `sparc_arch_table'.  On the other hand
  libopcodes maintains a set of hardware capabilities needed by each
  individual sparc instruction.

  When an instruction is assembled in `sparc_ip' gas checks for the
  presence of the hardware capabilities required by the instruction,
  emitting an error if some capability is missing.

  However, this mechanism does not work properly if the current
  architecture is bumped due to an instruction requiring new hw
  capabilities not present on either the default architecture or an
  architecture specified with -A:

  $ echo "fzero %f0" | as -bump
  {standard input}: Assembler messages:
  {standard input}:1: Warning: architecture bumped from "v6" to "v9a" on "fzero"
  {standard input}:1: Error: Hardware capability "vis" not enabled for "fzero".

  This patch fixes this by adding the set of required hw caps of an
  instruction if it triggers an architecture bump.

The patch has been tested in sparc64-unknown-linux-gnu.

gas/ChangeLog:

2014-09-12  Jose E. Marchesi  <jose.marchesi@oracle.com>

	* config/tc-sparc.c (sparc_ip): Update the set of allowed hwcaps
	when bumping the current architecture.
	(md_begin): Adjust the highetst architecture level also when a
	specific architecture is not requested.
[IRIX] eliminate deprecated_insert_raw_breakpoint uses

The IRIX support wants to set a breakpoint to be hit when the startup
phase is complete, which is where shared libraries have been mapped
in.  AFAIU, for most IRIX ports, that location is the entry point.

For MIPS IRIX however, GDB needs to set a breakpoint earlier, in
__dbx_link, as explained by:

 #ifdef SYS_syssgi
   /* On mips-irix, we need to stop the inferior early enough during
      the startup phase in order to be able to load the shared library
      symbols and insert the breakpoints that are located in these shared
      libraries.  Stopping at the program entry point is not good enough
      because the -init code is executed before the execution reaches
      that point.

      So what we need to do is to insert a breakpoint in the runtime
      loader (rld), more precisely in __dbx_link().  This procedure is
      called by rld once all shared libraries have been mapped, but before
      the -init code is executed.  Unfortuantely, this is not straightforward,
      as rld is not part of the executable we are running, and thus we need
      the inferior to run until rld itself has been mapped in memory.

      For this, we trace all syssgi() syscall exit events.  Each time
      we detect such an event, we iterate over each text memory maps,
      get its associated fd, and scan the symbol table for __dbx_link().
      When found, we know that rld has been mapped, and that we can insert
      the breakpoint at the symbol address.  Once the dbx_link() breakpoint
      has been inserted, the syssgi() notifications are no longer necessary,
      so they should be canceled.  */
   proc_trace_syscalls_1 (pi, SYS_syssgi, PR_SYSEXIT, FLAG_SET, 0);
 #endif

The loop in irix_solib_create_inferior_hook then runs until whichever
breakpoint is hit first, the one set by solib-irix.c or the one set by
procfs.c.

Note the comment in disable_break talks about __dbx_init, but I think
that's a typo for __dbx_link:

 -  /* Note that it is possible that we have stopped at a location that
 -     is different from the location where we inserted our breakpoint.
 -     On mips-irix, we can actually land in __dbx_init(), so we should
 -     not check the PC against our breakpoint address here.  See procfs.c
 -     for more details.  */

This looks very much like referring to the loop in
irix_solib_create_inferior_hook stopping at __dbx_link instead of at
the entry point.

What this patch does is convert these deprecated raw breakpoints to
standard solib_event breakpoints.  When the first solib-event
breakpoint is hit, we delete all solib-event breakpoints.  We do that
in the so_ops->handle_event hook.

This allows getting rid of the loop in irix_solib_create_inferior_hook
completely, which should allow properly handling signals and other
events in the early startup phase, like in SVR4.

Built on x86_64 Fedora 20 with --enable-targets=all (builds
solib-irix.c).

Joel tested that with an earlier version of this patch "info shared"
after starting a program gave the same list of shared libraries as
before.

gdb/ChangeLog:
2014-09-12  Pedro Alves  <palves@redhat.com>

	* breakpoint.c (remove_solib_event_breakpoints_at_next_stop)
	(create_and_insert_solib_event_breakpoint): New functions.
	* breakpoint.h (create_and_insert_solib_event_breakpoint)
	(remove_solib_event_breakpoints_at_next_stop): New declarations.
	* procfs.c (dbx_link_bpt_addr, dbx_link_bpt): Delete globals.
	(remove_dbx_link_breakpoint): Delete function.
	(insert_dbx_link_bpt_in_file): Use
	create_and_insert_solib_event_breakpoint instead of
	deprecated_insert_raw_breakpoint.
	(procfs_wait): Don't check whether we hit __dbx_link here.
	(procfs_mourn_inferior): Don't delete the __dbx_link breakpoint
	here.
	* solib-irix.c (base_breakpoint): Delete global.
	(disable_break): Delete function.
	(enable_break): Use create_solib_event_breakpoint
	instead of deprecated_insert_raw_breakpoint.
	(irix_solib_handle_event): New function.
	(irix_solib_create_inferior_hook): Don't run the target or disable
	the mapping-complete breakpoint here.
	(_initialize_irix_solib): Install irix_solib_handle_event as
	so_ops->handle_event hook.
after gdb_run_cmd, gdb_expect -> gdb_test_multiple/gdb_test

See:
  https://sourceware.org/ml/gdb-patches/2014-09/msg00404.html

We have a number of places that do gdb_run_cmd followed by gdb_expect,
when it would be better to use gdb_test_multiple or gdb_test.

This converts all that "grep gdb_run_cmd -A 2 | grep gdb_expect"
found.

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/testsuite/
2014-09-12  Pedro Alves  <palves@redhat.com>

	* gdb.arch/gdb1558.exp: Replace uses of gdb_expect after
	gdb_run_cmd with gdb_test_multiple or gdb_test throughout.
	* gdb.arch/i386-size-overlap.exp: Likewise.
	* gdb.arch/i386-size.exp: Likewise.
	* gdb.arch/i386-unwind.exp: Likewise.
	* gdb.base/a2-run.exp: Likewise.
	* gdb.base/break.exp: Likewise.
	* gdb.base/charset.exp: Likewise.
	* gdb.base/chng-syms.exp: Likewise.
	* gdb.base/commands.exp: Likewise.
	* gdb.base/dbx.exp: Likewise.
	* gdb.base/find.exp: Likewise.
	* gdb.base/funcargs.exp: Likewise.
	* gdb.base/jit-simple.exp: Likewise.
	* gdb.base/reread.exp: Likewise.
	* gdb.base/sepdebug.exp: Likewise.
	* gdb.base/step-bt.exp: Likewise.
	* gdb.cp/mb-inline.exp: Likewise.
	* gdb.cp/mb-templates.exp: Likewise.
	* gdb.objc/basicclass.exp: Likewise.
	* gdb.threads/killed.exp: Likewise.
daily update
Fix some ChangeLog typos
Pass plain-text prompt to with_gdb_prompt.

I had occasion to use with_gdb_prompt in a test for the patch for PR 17314
and was passing the plain text prompt as the value, "(top-gdb)",
instead of a regexp, "\(top-gdb\)" (expressed as "\\(top-gdb\\)" in TCL).

I then discovered that in order to restore the prompt gdb passes the
original value of $gdb_prompt to "set prompt", which works because
"set prompt \(gdb\) " is equivalent to "set prompt (gdb) ".
Perhaps I'm being overly cautious but this feels a bit subtle,
but at any rate as an API choice I'd much rather pass the plain text
form to with_gdb_prompt.

I also discovered that the initial value of gdb_prompt is set in
two places to two different values.
At the global level gdb.exp sets it to "\[(\]gdb\[)\]"
and default_gdb_init sets it to "\\(gdb\\)".
The former form is undesirable as an argument to "set prompt",
but it's not clear to me that just deleting this code won't break
anything.  Thus I just changed the value to be consistent and added
a comment.

gdb/testsuite/ChangeLog:

	* lib/gdb.exp (gdb_prompt): Add comment and change initial value to
	be consistent with what default_gdb_init uses.
	(with_gdb_prompt): Change form of PROMPT argument from a regexp to
	the plain text of the prompt.  Add some logging printfs.
	* gdb.perf/disassemble.exp: Update call to with_gdb_prompt.
	* linux-nat.c (wait_lwp): Add debugging printf.
	(linux_nat_wait_1): Ditto.
daily update
New command queue-signal.

If I want to change the signalled state of multiple threads
it's a bit cumbersome to do with the "signal" command.
What you really want is a way to set the signal state of the
desired threads and then just do "continue".

This patch adds a new command, queue-signal, to accomplish this.
Basically "signal N" == "queue-signal N" + "continue".
That's not precisely true in that "signal" can be used to inject
any signal, including signals set to "nopass"; whereas "queue-signal"
just queues the signal as if the thread stopped because of it.
"nopass" handling is done when the thread is resumed which
"queue-signal" doesn't do.

One could add extra complexity to allow queue-signal to be used to
deliver "nopass" signals like the "signal" command.  I have no current
need for it so in the interests of incremental complexity, I have
left such support out and just have the code flag an error if one
tries to queue a nopass signal.

gdb/ChangeLog:

	* NEWS: Mention new "queue-signal" command.
	* infcmd.c (queue_signal_command): New function.
	(_initialize_infcmd): Add new queue-signal command.

gdb/doc/ChangeLog:

	* gdb.texinfo (Signaling): Document new queue-signal command.

gdb/testsuite/ChangeLog:

	* gdb.threads/queue-signal.c: New file.
	* gdb.threads/queue-signal.exp: New file.
Fix set up of queue-signal.exp test.

The test does a backtrace to see which thread (#2 or #3) is assigned
to which SIGUSR (1 or 2).  If the main thread gets to all_threads_running
before the sigusr threads get to their entry point, then the function
name isn't in the backtrace and the test fails.

Alas this version of the code is within epsilon of what I started with,
and then over-simplified things.
daily update