unpush the remote target if serial_write fails.

PR gdb/15275 notes that when debugging with a remote connection over a
serial link and the link is disconnected, say by disconnecting USB
serial port, the GDB quit command no longer works:

 (gdb)
 tar ext /dev/ttyACM0
 &"tar ext /dev/ttyACM0\n"
 ~"Remote debugging using /dev/ttyACM0\n"
 ^done
 (gdb)
 set debug remote 1
 &"set debug remote 1\n"
 ^done
 (gdb)
 quit
 &"quit\n"
 &"Sending packet: $qTStatus#49..."
 &"putpkt: write failed: Input/output error.\n"
 ^error,msg="putpkt: write failed: Input/output error."
 (gdb)
 (gdb)
 quit
 &"quit\n"
 &"Sending packet: $qTStatus#49..."
 &"putpkt: write failed: Input/output error.\n"
 ^error,msg="putpkt: write failed: Input/output error."

This is not reproducible with TCP connections, as with that, sending
doesn't error out, but instead the error is detected on the subsequent
readchar.  When that read fails, we unpush the remote target, and
throw TARGET_CLOSE_ERROR.  To address PR gdb/15275, instead of
catching the error in remote_get_trace_status as presently done (which
leaves this same issue latent for another packet to trip on), or of
making ser-unix.c fake success too on failed writes, so we'd get to
readchar detecting the error on serial ports too, better let the error
propagate out of serial_write, and catch it at the remote.c level,
throwing away the target if writing fails too, instead of delaying
that until the next read.

gdb/
2013-04-02  Pedro Alves  <palves@redhat.com>

	PR gdb/15275

	* remote.c (send_interrupt_sequence): Use remote_serial_write.
	(remote_serial_write): New function.
	(putpkt_binary, getpkt_or_notif_sane_1): Use remote_serial_write.
gdb/
	Revert this patch:
	PR gdb/15275
	* remote.c (remote_get_trace_status): Include putpkt in TRY_CATCH.
NEWS: Move "set debug notification" and "set trace-buffer-size" under "New options".

The "New commands" section reads:

 "New commands (for set/show, see "New options" below)"

gdb/
2013-04-02  Pedro Alves  <palves@redhat.com>

	* NEWS: Move "set debug notification" and "set trace-buffer-size"
	under "New options".
Fix list of files used to produce TAGS.

	* Makefile.in (HFILES_NO_SRCDIR): Remove call-cmds.h.
	gdb_string.h is now in common/.
Add missing NEWS and manual bits for "set trace-buffer-size".

Add missing mention of the QTBuffer::size packet configuration
command, in both NEWS and manual.

gdb/
2013-04-02  Pedro Alves  <palves@redhat.com>

	* NEWS: Mention "set/show remote trace-buffer-size-packet".

gdb/doc/
2013-04-02  Pedro Alves  <palves@redhat.com>

	* gdb.texinfo (Remote Configuration) <set remote @var{name}-packet
	table>: Add entry for "trace-buffer-size".
NEWS/manual: Missing documentation for new commands in 7.6.

I hacked "apropos" to dump the whole set of commands (just make it
accept the entry string as regex), and then diffed the output of 7.5
vs 7.6, --enable-targets=all builds.  That allowed then checking
whether some commands had not been mentioned in NEWS or the manual.
These are what I found missing.  We've been a bit negligent in
requiring documentation bits for debug commands.

gdb/
2013-04-02  Pedro Alves  <palves@redhat.com>

	* NEWS: Mention "set/show debug aarch64", "set/show debug
	coff-pe-read" and "set/show debug mach-o".

gdb/doc/
2013-04-02  Pedro Alves  <palves@redhat.com>

	* gdb.texinfo (Debugging Output): Document "set/show debug
	aarch64", "set/show debug coff-pe-read" and "set/show debug
	mach-o".
*** empty log message ***
NEWS: Mention x86_64/Cygwin as new native configuration too.

x86_64/Cygwin is only mentioned as a new target, but we gained support
for building a native x86_64/Cygwin debugger too.

gdb/
2013-04-03  Pedro Alves  <palves@redhat.com>

	* NEWS: Mention x86_64/Cygwin as new native configuration.
gdb/
	* NEWS (Changes in GDB 7.6): Update the data-disassemble for "fullname".
	New entry about "fullname" presence.
	* contrib/cc-with-tweaks.sh: Check exit code of dwp.
*** empty log message ***
gdb/testsuite/

	* gdb.server/server-kill.exp: Use command 'tstatus' instead of
	'step'.
tracepoint->step_count fixes

If a tracepoint's actions list includes a while-stepping action, and
then the actions are changed to a list without any while-stepping
action, the tracepoint's step_count will be left with a stale value.
For example:

 (gdb) trace subr
 Tracepoint 1 at 0x4004d9: file ../../../src/gdb/testsuite//actions-changed.c, line 31.
 (gdb) actions
 Enter actions for tracepoint 1, one per line.
 End with a line saying just "end".
 >collect $reg
 >end
 (gdb) set debug remote 1
 (gdb) tstart
 Sending packet: $QTinit#59...Packet received: OK
 Sending packet: $QTDP:1:00000000004004d9:E:0:0-#a3...Packet received: OK
 Sending packet: $QTDP:-1:00000000004004d9:R03FFFFFFFFFFFFFFFFFF#2b...Packet received: OK
 (gdb) tstop
 Sending packet: $QTStop#4b...Packet received: OK
 Sending packet: $QTNotes:#e8...Packet received: OK
 (gdb) actions
 Enter actions for tracepoint 1, one per line.
 End with a line saying just "end".
 >collect $reg
 >while-stepping 1
   >collect $reg
   >end
 >end
 (gdb) tstart
 Sending packet: $QTinit#59...Packet received: OK
 Sending packet: $QTDP:1:00000000004004d9:E:1:0-#a4...Packet received: OK
 Sending packet: $QTDP:-1:00000000004004d9:R03FFFFFFFFFFFFFFFFFF-#58...Packet received: OK
 Sending packet: $QTDP:-1:00000000004004d9:SR03FFFFFFFFFFFFFFFFFF#7e...Packet received: OK
 (gdb) tstop
 Sending packet: $QTStop#4b...Packet received: OK
 Sending packet: $QTNotes:#e8...Packet received: OK
 (gdb) actions
 Enter actions for tracepoint 1, one per line.
 End with a line saying just "end".
 >collect $regs
 >end
 (gdb) tstart
 Sending packet: $QTinit#59...Packet received: OK
 Sending packet: $QTDP:1:00000000004004d9:E:1:0-#a4...Packet received: OK
 Sending packet: $QTDP:-1:00000000004004d9:R03FFFFFFFFFFFFFFFFFF#2b...Packet received: OK

The last "$QTDP:1:00000000004004d9:E:1:0-#a4" should be "$QTDP:1:00000000004004d9:E:0:0-#a3".
In pseudo-diff:

  -$QTDP:1:00000000004004d9:E:1:0-#a4
  +$QTDP:1:00000000004004d9:E:0:0-#a3

A related issue is that the "commands" command actually supports
setting commands to a range of breakpoints/tracepoints at once.  But,
hacking "maint info breakpoints" to print t->step_count, reveals:

 (gdb) trace main
 Tracepoint 5 at 0x45a2ab: file ../../src/gdb/gdb.c, line 29.
 (gdb) trace main
 Note: breakpoint 5 also set at pc 0x45a2ab.
 Tracepoint 6 at 0x45a2ab: file ../../src/gdb/gdb.c, line 29.
 (gdb) commands 5-6
 Type commands for breakpoint(s) 5-6, one per line.
 End with a line saying just "end".
 > while-stepping 5
  >end
 > end
 (gdb) maint info breakpoints 5
 Num     Type           Disp Enb Address            What
 5       tracepoint     keep y   0x000000000045a2ab in main at ../../src/gdb/gdb.c:29 inf 1
         step_count=5
         ^^^^^^^^^^^^
         while-stepping 5
         end
         not installed on target
 (gdb) maint info breakpoints 6
 Num     Type           Disp Enb Address            What
 6       tracepoint     keep y   0x000000000045a2ab in main at ../../src/gdb/gdb.c:29 inf 1
         step_count=0
         ^^^^^^^^^^^^
         while-stepping 5
         end
         not installed on target
 (gdb)

that tracepoint 6 doesn't end up with the correct step_count.

The issue is that here:

 static void
 do_map_commands_command (struct breakpoint *b, void *data)
 {
  struct commands_info *info = data;

  if (info->cmd == NULL)
    {
      struct command_line *l;

      if (info->control != NULL)
	l = copy_command_lines (info->control->body_list[0]);
      else
	{
	  struct cleanup *old_chain;
	  char *str;

	  str = xstrprintf (_("Type commands for breakpoint(s) "
			      "%s, one per line."),
			    info->arg);

	  old_chain = make_cleanup (xfree, str);

	  l = read_command_lines (str,
				  info->from_tty, 1,
				  (is_tracepoint (b)
				   ? check_tracepoint_command : 0),
				  b);

	  do_cleanups (old_chain);
	}

      info->cmd = alloc_counted_command_line (l);
    }

validate_actionline is never called for tracepoints other than the
first (the copy_command_lines path).  Right below, we have:

  /* If a breakpoint was on the list more than once, we don't need to
     do anything.  */
  if (b->commands != info->cmd)
    {
      validate_commands_for_breakpoint (b, info->cmd->commands);
      incref_counted_command_line (info->cmd);
      decref_counted_command_line (&b->commands);
      b->commands = info->cmd;
      observer_notify_breakpoint_modified (b);
    }

And validate_commands_for_breakpoint looks like the right place to put
a call; if we reset step_count there too, we have a nice central fix
for the first issue as well, because trace_actions_command calls
breakpoint_set_commands that also calls
validate_commands_for_breakpoint.

We end up calling validate_actionline twice for the first tracepoint,
since read_command_lines calls it too, through
check_tracepoint_command, but that should be harmless.

2013-04-04  Pedro Alves  <palves@redhat.com>
	    Hui Zhu  <hui@codesourcery.com>

	* breakpoint.c (validate_commands_for_breakpoint): If validating a
	tracepoint, reset its STEP_COUNT and call validate_actionline.

2013-04-04  Stan Shebs  <stan@codesourcery.com>
	    Pedro Alves  <palves@redhat.com>

	* gdb.trace/Makefile.in (PROGS): Add actions-changed.
	* gdb.trace/actions-changed.c: New file.
	* gdb.trace/actions-changed.exp: New file.
	* lib/trace-support.exp (gdb_trace_setactions): Rename to ...
	(gdb_trace_setactions_command): ... this.  Add "actions_command"
	parameter, and handle it.
	(gdb_trace_setactions, gdb_trace_setcommands): New procedures.
tracepoint->step_count fixes

If a tracepoint's actions list includes a while-stepping action, and
then the actions are changed to a list without any while-stepping
action, the tracepoint's step_count will be left with a stale value.
For example:

 (gdb) trace subr
 Tracepoint 1 at 0x4004d9: file ../../../src/gdb/testsuite//actions-changed.c, line 31.
 (gdb) actions
 Enter actions for tracepoint 1, one per line.
 End with a line saying just "end".
 >collect $reg
 >end
 (gdb) set debug remote 1
 (gdb) tstart
 Sending packet: $QTinit#59...Packet received: OK
 Sending packet: $QTDP:1:00000000004004d9:E:0:0-#a3...Packet received: OK
 Sending packet: $QTDP:-1:00000000004004d9:R03FFFFFFFFFFFFFFFFFF#2b...Packet received: OK
 (gdb) tstop
 Sending packet: $QTStop#4b...Packet received: OK
 Sending packet: $QTNotes:#e8...Packet received: OK
 (gdb) actions
 Enter actions for tracepoint 1, one per line.
 End with a line saying just "end".
 >collect $reg
 >while-stepping 1
   >collect $reg
   >end
 >end
 (gdb) tstart
 Sending packet: $QTinit#59...Packet received: OK
 Sending packet: $QTDP:1:00000000004004d9:E:1:0-#a4...Packet received: OK
 Sending packet: $QTDP:-1:00000000004004d9:R03FFFFFFFFFFFFFFFFFF-#58...Packet received: OK
 Sending packet: $QTDP:-1:00000000004004d9:SR03FFFFFFFFFFFFFFFFFF#7e...Packet received: OK
 (gdb) tstop
 Sending packet: $QTStop#4b...Packet received: OK
 Sending packet: $QTNotes:#e8...Packet received: OK
 (gdb) actions
 Enter actions for tracepoint 1, one per line.
 End with a line saying just "end".
 >collect $regs
 >end
 (gdb) tstart
 Sending packet: $QTinit#59...Packet received: OK
 Sending packet: $QTDP:1:00000000004004d9:E:1:0-#a4...Packet received: OK
 Sending packet: $QTDP:-1:00000000004004d9:R03FFFFFFFFFFFFFFFFFF#2b...Packet received: OK

The last "$QTDP:1:00000000004004d9:E:1:0-#a4" should be "$QTDP:1:00000000004004d9:E:0:0-#a3".
In pseudo-diff:

  -$QTDP:1:00000000004004d9:E:1:0-#a4
  +$QTDP:1:00000000004004d9:E:0:0-#a3

A related issue is that the "commands" command actually supports
setting commands to a range of breakpoints/tracepoints at once.  But,
hacking "maint info breakpoints" to print t->step_count, reveals:

 (gdb) trace main
 Tracepoint 5 at 0x45a2ab: file ../../src/gdb/gdb.c, line 29.
 (gdb) trace main
 Note: breakpoint 5 also set at pc 0x45a2ab.
 Tracepoint 6 at 0x45a2ab: file ../../src/gdb/gdb.c, line 29.
 (gdb) commands 5-6
 Type commands for breakpoint(s) 5-6, one per line.
 End with a line saying just "end".
 > while-stepping 5
  >end
 > end
 (gdb) maint info breakpoints 5
 Num     Type           Disp Enb Address            What
 5       tracepoint     keep y   0x000000000045a2ab in main at ../../src/gdb/gdb.c:29 inf 1
         step_count=5
         ^^^^^^^^^^^^
         while-stepping 5
         end
         not installed on target
 (gdb) maint info breakpoints 6
 Num     Type           Disp Enb Address            What
 6       tracepoint     keep y   0x000000000045a2ab in main at ../../src/gdb/gdb.c:29 inf 1
         step_count=0
         ^^^^^^^^^^^^
         while-stepping 5
         end
         not installed on target
 (gdb)

that tracepoint 6 doesn't end up with the correct step_count.

The issue is that here:

 static void
 do_map_commands_command (struct breakpoint *b, void *data)
 {
  struct commands_info *info = data;

  if (info->cmd == NULL)
    {
      struct command_line *l;

      if (info->control != NULL)
	l = copy_command_lines (info->control->body_list[0]);
      else
	{
	  struct cleanup *old_chain;
	  char *str;

	  str = xstrprintf (_("Type commands for breakpoint(s) "
			      "%s, one per line."),
			    info->arg);

	  old_chain = make_cleanup (xfree, str);

	  l = read_command_lines (str,
				  info->from_tty, 1,
				  (is_tracepoint (b)
				   ? check_tracepoint_command : 0),
				  b);

	  do_cleanups (old_chain);
	}

      info->cmd = alloc_counted_command_line (l);
    }

validate_actionline is never called for tracepoints other than the
first (the copy_command_lines path).  Right below, we have:

  /* If a breakpoint was on the list more than once, we don't need to
     do anything.  */
  if (b->commands != info->cmd)
    {
      validate_commands_for_breakpoint (b, info->cmd->commands);
      incref_counted_command_line (info->cmd);
      decref_counted_command_line (&b->commands);
      b->commands = info->cmd;
      observer_notify_breakpoint_modified (b);
    }

And validate_commands_for_breakpoint looks like the right place to put
a call; if we reset step_count there too, we have a nice central fix
for the first issue as well, because trace_actions_command calls
breakpoint_set_commands that also calls
validate_commands_for_breakpoint.

We end up calling validate_actionline twice for the first tracepoint,
since read_command_lines calls it too, through
check_tracepoint_command, but that should be harmless.

2013-04-04  Pedro Alves  <palves@redhat.com>
	    Hui Zhu  <hui@codesourcery.com>

	* breakpoint.c (validate_commands_for_breakpoint): If validating a
	tracepoint, reset its STEP_COUNT and call validate_actionline.

2013-04-04  Stan Shebs  <stan@codesourcery.com>
	    Pedro Alves  <palves@redhat.com>

	* gdb.trace/Makefile.in (PROGS): Add actions-changed.
	* gdb.trace/actions-changed.c: New file.
	* gdb.trace/actions-changed.exp: New file.
	* lib/trace-support.exp (gdb_trace_setactions): Rename to ...
	(gdb_trace_setactions_command): ... this.  Add "actions_command"
	parameter, and handle it.
	(gdb_trace_setactions, gdb_trace_setcommands): New procedures.
	* psymtab.c (read_psymtabs_with_fullname): Don't call
	psymtab_to_fullname if the basenames are different.
*** empty log message ***
gdb/
	Fix variable name shadowing.
	* linux-tdep.c (linux_find_memory_regions_full): Rename outer variable
	filename to mapsfilename and update its uses.
gdb/
	Fix compatibility with Linux kernel 3.8.3.
	* linux-tdep.c (linux_find_memory_regions_full): Move variable number
	to more inner block.  Remove parsing of NUMBER from outer block.
	Parse NUMBER only if KEYWORD has been identified.
*** empty log message ***
Fix GDB relocation on MinGW.

	* mingw-hdep.c (windows_get_absolute_argv0): New function.
	Include main.h.

	* main.h (windows_get_absolute_argv0): Add prototype.

	* main.c (get_init_files): Use filename_ncmp instead of strncmp.
	Use IS_DIR_SEPARATOR instead of looking for a character inside
	SLASH_STRING.  Include filenames.h.
	(captured_main) [__MINGW32__]: Make argv[0] absolute, so that
	relocate_gdb_directory works when passed gdb_program_name.