document "quit" command's argument

2014-04-25  Tom Tromey  <tromey@redhat.com>

	* cli/cli-cmds.c (_initialize_cli_cmds): Document "quit" command's
	argument.
This fixes a compile time warning which is being treated as an error.  Older
versions of gcc complain about part of a conditional expression always
evaluating to false because of the size of the operands involved, even when
the entire expression is already known to be false.

	* peXXigen.c (_bfd_XXi_swap_sym_out): Another fix for building on
	a 342-bit host.  This time for older versions of gcc.
Fix several "set remote foo-packet on/off" commands.

For several RSP packets, there's a corresponding "set remote
foo-packet on/off/auto" command that one can use do bypass
auto-detection of support for the packet or feature.  However, I
noticed that setting several of these commands to 'on' or 'off'
doesn't actually have any effect.  These are, at least:

 set remote breakpoint-commands-packet
 set remote conditional-breakpoints-packet
 set remote fast-tracepoints-packet
 set remote static-tracepoints-packet
 set remote install-in-trace-packet

These are commands that control a remote protocol feature that doesn't
have a corresponding regular packet, and because of that we cache the
knowledge of the remote side support as returned by the qSupported
packet in the remote_state object.

E.g., in the case of the 'set remote breakpoint-commands-packet'
command, whether the feature is supported is recorded in the
'breakpoint_commands' field of the remote_state object.

Whether to bypass packet support auto-detection or not is controlled
by the 'detect' field of the corresponding packet's packet_config
structure.  That field is the variable associated directly with the
"set remote foo-packet" command.  Actual remote stub support for the
packet (or feature) is recorded in the 'support' field of the same
structure.

However, when the user toggles the command, the 'support' field is
also correspondingly updated to PACKET_ENABLE/DISABLE/SUPPORT_UNKNOWN,
discarding the knowledge of whether the target actually supports the
feature.  If one toggles back to 'auto', it's no big issue for real
packets, as they'll just end up re-probed the next time they might be
necessary.  But features whose support is only reported through
qSupported don't get their corresponding (manually added/maintained)
fields in remote_state objected updated.  As we lost the actual status
of the target support for the feature, GDB would need to probe the
qSupported features again, which GDB doesn't do.

But we can avoid that extra traffic, and clean things up, IMO.
Instead of going in that direction, this patch completely decouples
struct packet_config's 'detect' and 'support' fields.  E.g., when the
user does "set remote foo-packet off", instead of setting the packet
config's 'support' field to PACKET_DISABLE, the 'support' field is not
touched at all anymore.  That is, we end up respecting this simple
table:

| packet_config->detect | packet_config->support | should use packet/feature? |
|-----------------------+------------------------+----------------------------|
| auto                  | PACKET_ENABLE          | PACKET_ENABLE              |
| auto                  | PACKET_DISABLE         | PACKET_DISABLE             |
| auto                  | PACKET_UNKNOWN         | PACKET_UNKNOWN             |
| yes                   | don't care             | PACKET_ENABLE              |
| no                    | don't care             | PACKET_DISABLE             |

This is implemented by the new packet_support function.  With that, we
need to update this pattern throughout:

  if (remote_protocol_packets[PACKET_foo].support == PACKET_DISABLE)

to do this instead:

  if (packet_support (PACKET_qAttached) == PACKET_DISABLE)

where as mentioned, the packet_support function takes struct
packet_config's 'detect' field into account, like in the table above.

As when the packet is force-disabled or force-enabled, the 'support'
field is just ignored, if the command is set back to auto, we'll
resume respecting whatever the target said it supports.  IOW, the end
result is that the 'support' field always represents whether the
target actually supports the packet or not.

After all that, the manually maintained breakpoint_commands and
equivalent fields of struct remote_state can then be eliminated, with
references replaced by checking the result of calling the
packet_support function on the corresponding packet or feature.  This
required adding new PACKET_foo enum values for several features that
didn't have it yet.  (The patch does not add corresponding "set remote
foo-packet" style commands though, focusing only on bug fixing and
laying the groundwork).

Tested on x86_64 Fedora 17, native GDBserver.  The new tests all fail
without this patch.

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

	* remote.c (struct remote_state): Remove multi_process_aware,
	non_stop_aware, cond_tracepoints, cond_breakpoints,
	breakpoint_commands, fast_tracepoints, static_tracepoints,
	install_in_trace, disconnected_tracing,
	enable_disable_tracepoints, string_tracing, and
	augmented_libraries_svr4_read fields.
	(remote_multi_process_p): Move further below in the file.
	(struct packet_config): Add comments.
	(update_packet_config): Delete function.
	(show_packet_config_cmd): Use packet_config_support.
	(add_packet_config_cmd): Use NULL as set callback.
	(packet_ok): "set remote foo-packet"-style commands no longer
	change config->supported -- adjust.
	(PACKET_ConditionalTracepoints, PACKET_ConditionalBreakpoints)
	(PACKET_BreakpointCommands, PACKET_FastTracepoints)
	(PACKET_StaticTracepoints, PACKET_InstallInTrace): Add comments.
	(PACKET_QNonStop, PACKET_multiprocess_feature)
	(PACKET_EnableDisableTracepoints_feature, PACKET_tracenz_feature)
	(PACKET_DisconnectedTracing_feature)
	(PACKET_augmented_libraries_svr4_read_feature): New enum values.
	(set_remote_protocol_packet_cmd): Delete function.
	(packet_config_support, packet_support): New functions.
	(set_remote_protocol_Z_packet_cmd): Don't call
	update_packet_config.
	(remote_query_attached, remote_pass_signals)
	(remote_program_signals, remote_threads_info)
	(remote_threads_extra_info, remote_start_remote): Use
	packet_support.
	(remote_start_remote): Use packet_config_support and
	packet_support.
	(init_all_packet_configs): Set all packets to unknown support,
	instead of calling update_packet_config.
	(remote_check_symbols): Use packet_support.
	(remote_supported_packet): Unconditionally set the packet config's
	support status.
	(remote_multi_process_feature, remote_non_stop_feature)
	(remote_cond_tracepoint_feature, remote_cond_breakpoint_feature)
	(remote_breakpoint_commands_feature)
	(remote_fast_tracepoint_feature, remote_static_tracepoint_feature)
	(remote_install_in_trace_feature)
	(remote_disconnected_tracing_feature)
	(remote_enable_disable_tracepoint_feature)
	(remote_string_tracing_feature)
	(remote_augmented_libraries_svr4_read_feature): Delete functions.
	(remote_protocol_features): Adjust to use remote_supported_packet
	for "augmented-libraries-svr4-read", "multiprocess", "QNonStop",
	"ConditionalTracepoints", "ConditionalBreakpoints",
	"BreakpointCommands", "FastTracepoints", "StaticTracepoints",
	"InstallInTrace", "DisconnectedTracing", "DisconnectedTracing",
	"EnableDisableTracepoints", and "tracenz".
	(remote_query_supported): Use packet_support.
	(remote_open_1): Adjust.
	(extended_remote_attach_1): Use packet_support.  Switch on the
	result of packet_ok instead of checking whether the packet ended
	up disabled.
	(remote_vcont_resume): Use packet_support.
	(remote_resume, remote_stop_ns, fetch_register_using_p)
	(remote_prepare_to_store, store_register_using_P)
	(check_binary_download, remote_write_bytes): Use packet_support.
	(remote_vkill): Use packet_support.  Switch on the result of
	packet_ok instead of checking whether the packet ended up
	disabled.
	(extended_remote_supports_disable_randomization): Use
	packet_support.
	(extended_remote_run): Switch on the result of packet_ok instead
	of checking whether the packet ended up disabled.
	(remote_insert_breakpoint, remote_remove_breakpoint)
	(remote_insert_watchpoint, remote_remove_watchpoint)
	(remote_insert_hw_breakpoint, remote_remove_hw_breakpoint): Use
	packet_support.
	(remote_search_memory): Use packet_config_support.
	(remote_get_thread_local_address, remote_get_tib_address)
	(remote_hostio_send_command, remote_can_execute_reverse): Use
	packet_support.
	(remote_supports_cond_tracepoints)
	(remote_supports_cond_breakpoints)
	(remote_supports_fast_tracepoints)
	(remote_supports_static_tracepoints)
	(remote_supports_install_in_trace)
	(remote_supports_enable_disable_tracepoint)
	(remote_supports_string_tracing)
	(remote_can_run_breakpoint_commands): Rewrite, checking whether
	the packet config says the feature is enabled or disabled.
	(remote_download_tracepoint, remote_trace_set_readonly_regions)
	(remote_get_trace_status): Use packet_support.
	(remote_set_disconnected_tracing): Adjust to check whether the
	feature is enabled with packet_support.
	(remote_set_trace_buffer_size, remote_use_agent)
	(remote_can_use_agent, remote_supports_btrace): Use
	packet_support.
	(remote_enable_btrace, remote_disable_btrace, remote_read_btrace):
	Use packet_config_support.
	(remote_augmented_libraries_svr4_read): Rewrite, checking whether
	the packet config says the feature is enabled or disabled.
	(set_range_stepping): Use packet_support.

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

	* gdb.base/cond-eval-mode.exp (warning): Move trailing \r\n to
	user.
	(top level): Test that "set remote conditional-breakpoints-packet
	off" works as intended.
	* gdb.base/dprintf.exp: Test that "set remote
	breakpoint-commands-packet off" works as intended.
	* gdb.trace/change-loc.exp (tracepoint_install_in_trace_disabled):
	New function.
	(top level): Call it.
	* gdb.trace/ftrace.exp (test_fast_tracepoints): Test that "set
	remote fast-tracepoints-packet off" works as intended.
	* gdb.trace/qtro.exp (gdb_is_target_remote): Moved ...
	* lib/gdb.exp (gdb_is_target_remote): ... here.
PR server/16255: gdbserver cannot attach to a second inferior that is multi-threaded.

On Linux, we need to explicitly ptrace attach to all lwps of a
process.  Because GDB might not be connected yet when an attach is
requested, and thus it may not be possible to activate thread_db, as
that requires access to symbols (IOW, gdbserver --attach), a while ago
we make linux_attach loop over the lwps as listed by /proc/PID/task to
find the lwps to attach to.

linux_attach_lwp_1 has:

...
  if (initial)
    /* If lwp is the tgid, we handle adding existing threads later.
       Otherwise we just add lwp without bothering about any other
       threads.  */
    ptid = ptid_build (lwpid, lwpid, 0);
  else
    {
      /* Note that extracting the pid from the current inferior is
	 safe, since we're always called in the context of the same
	 process as this new thread.  */
      int pid = pid_of (current_inferior);
      ptid = ptid_build (pid, lwpid, 0);
    }

That "safe" comment referred to linux_attach_lwp being called by
thread-db.c.  But this was clearly missed when a new call to
linux_attach_lwp_1 was added to linux_attach.  As a result,
current_inferior will be set to some random process, and non-initial
lwps of the second inferior get assigned the pid of the wrong
inferior.  E.g., in the case of attaching to two inferiors, for the
second inferior (and so on), non-initial lwps of the second inferior
get assigned the pid of the first inferior.  This doesn't trigger on
the first inferior, when current_inferior is NULL, add_thread switches
the current inferior to the newly added thread.

Rather than making linux_attach switch current_inferior temporarily
(thus avoiding further reliance on global state), or making
linux_attach_lwp_1 get the tgid from /proc, which add extra syscalls,
and will be wrong in case of the user having originally attached
directly to a non-tgid lwp, and then that lwp spawning new clones (the
ptid.pid field of further new clones should be the same as the
original lwp's pid, which is not the tgid), we note that callers of
linux_attach_lwp/linux_attach_lwp_1 always have the right pid handy
already, so they can pass it down along with the lwpid.

The only other reason for the "initial" parameter is to error out
instead of warn in case of attach failure, when we're first attaching
to a process.  There are only three callers of
linux_attach_lwp/linux_attach_lwp_1, and each wants to print a
different warn/error string, so we can just move the error/warn out of
linux_attach_lwp_1 to the callers, thus getting rid of the "initial"
parameter.

There really nothing gdbserver-specific about attaching to two
threaded processes, so this adds a new test under gdb.multi/.  The
test passes cleanly against the native GNU/Linux target, but
fails/triggers the bug against GDBserver (before the patch), with the
native-extended-remote board (as plain remote doesn't support
multi-process).

Tested on x86_64 Fedora 17, with the native-extended-gdbserver board.

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

	PR server/16255
	* linux-low.c (linux_attach_fail_reason_string): New function.
	(linux_attach_lwp): Delete.
	(linux_attach_lwp_1): Rename to ...
	(linux_attach_lwp): ... this.  Take a ptid instead of a pid as
	argument.  Remove "initial" parameter.  Return int instead of
	void.  Don't error or warn here.
	(linux_attach): Adjust to call linux_attach_lwp.  Call error on
	failure to attach to the tgid.  Call warning when failing to
	attach to an lwp.
	* linux-low.h (linux_attach_lwp): Take a ptid instead of a pid as
	argument.  Remove "initial" parameter.  Return int instead of
	void.  Don't error or warn here.
	(linux_attach_fail_reason_string): New declaration.
	* thread-db.c (attach_thread): Adjust to linux_attach_lwp's
	interface change.  Use linux_attach_fail_reason_string.

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

	PR server/16255
	* common/linux-ptrace.c (linux_ptrace_attach_warnings): Rename to ...
	(linux_ptrace_attach_fail_reason): ... this.  Remove "warning: "
	and newline from built string.
	* common/linux-ptrace.h (linux_ptrace_attach_warnings): Rename to ...
	(linux_ptrace_attach_fail_reason): ... this.
	* linux-nat.c (linux_nat_attach): Adjust to use
	linux_ptrace_attach_fail_reason.

gdb/testsuite/
2014-04-25  Simon Marchi  <simon.marchi@ericsson.com>
	    Pedro Alves  <palves@redhat.com>

	PR server/16255
	* gdb.multi/multi-attach.c: New file.
	* gdb.multi/multi-attach.exp: New file.
Add missing gdbserver/ChangeLog entry for previous commit.

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

	PR server/16255
	* linux-low.c (linux_attach_fail_reason_string): New function.
	(linux_attach_lwp): Delete.
	(linux_attach_lwp_1): Rename to ...
	(linux_attach_lwp): ... this.  Take a ptid instead of a pid as
	argument.  Remove "initial" parameter.  Return int instead of
	void.  Don't error or warn here.
	(linux_attach): Adjust to call linux_attach_lwp.  Call error on
	failure to attach to the tgid.  Call warning when failing to
	attach to an lwp.
	* linux-low.h (linux_attach_lwp): Take a ptid instead of a pid as
	argument.  Remove "initial" parameter.  Return int instead of
	void.  Don't error or warn here.
	(linux_attach_fail_reason_string): New declaration.
	* thread-db.c (attach_thread): Adjust to linux_attach_lwp's
	interface change.  Use linux_attach_fail_reason_string.