RFC: Clean up "show remote"

RFC: Clean up "show remote"

[Daniel Jacobowitz]

Does anyone have an opinion on this patch?  It's, um, a bit inelegant;
but it removes the hardcoded list of subcommands in show_remote_cmd, which
happens to be missing two.  I always try "show remote" when I want to
remember the spelling of "set remote hardware-breakpoint-limit", but
it didn't include that.

Also shorten the messages a bit by removing redundancy; either the user
typed config->title, or it was prefixed to the output already.

An alternative if the code in show_remote_cmd is too ugly would be to delete
"show remote Z-packet".  I think we have to leave "set remote Z-packet" -
it's five years obsoleted but never marked as deprecated and I know people
are continuing to use it - but the show command is completely redundant.

-- 
Daniel Jacobowitz
CodeSourcery

2006-01-22  Daniel Jacobowitz  <dan@codesourcery.com>

	* Makefile.in (remote.o): Update.
	* remote.c (show_packet_config_cmd): Shorten messages.
	(remote_set_cmdlist, remote_show_cmdlist): Make file-static.
	(show_remote_cmd): Iterate.
	(_initialize_remote): Remove remote_set_cmdlist,
	remote_show_cmdlist.

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.777
diff -u -p -r1.777 Makefile.in
--- Makefile.in	21 Jan 2006 01:29:03 -0000	1.777
+++ Makefile.in	22 Jan 2006 20:12:52 -0000
@@ -2441,7 +2441,8 @@ remote.o: remote.c $(defs_h) $(gdb_strin
 	$(symfile_h) $(exceptions_h) $(target_h) $(gdbcmd_h) $(objfiles_h) \
 	$(gdb_stabs_h) $(gdbthread_h) $(remote_h) $(regcache_h) $(value_h) \
 	$(gdb_assert_h) $(event_loop_h) $(event_top_h) $(inf_loop_h) \
-	$(serial_h) $(gdbcore_h) $(remote_fileio_h) $(solib_h) $(observer_h)
+	$(serial_h) $(gdbcore_h) $(remote_fileio_h) $(solib_h) $(observer_h) \
+	$(cli_decode_h) $(cli_setshow_h)
 remote-e7000.o: remote-e7000.c $(defs_h) $(gdbcore_h) $(gdbarch_h) \
 	$(inferior_h) $(target_h) $(value_h) $(command_h) $(gdb_string_h) \
 	$(exceptions_h) $(gdbcmd_h) $(serial_h) $(remote_utils_h) \
Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.198
diff -u -p -r1.198 remote.c
--- remote.c	17 Jan 2006 14:11:16 -0000	1.198
+++ remote.c	22 Jan 2006 20:12:52 -0000
@@ -43,6 +43,8 @@
 #include "gdb_assert.h"
 #include "observer.h"
 #include "solib.h"
+#include "cli/cli-decode.h"
+#include "cli/cli-setshow.h"
 
 #include <ctype.h>
 #include <sys/time.h>
@@ -612,13 +614,13 @@ show_packet_config_cmd (struct packet_co
   switch (config->detect)
     {
     case AUTO_BOOLEAN_AUTO:
-      printf_filtered (_("Support for remote protocol `%s' (%s) packet is auto-detected, currently %s.\n"),
-		       config->name, config->title, support);
+      printf_filtered (_("Support for the `%s' packet is auto-detected, currently %s.\n"),
+		       config->name, support);
       break;
     case AUTO_BOOLEAN_TRUE:
     case AUTO_BOOLEAN_FALSE:
-      printf_filtered (_("Support for remote protocol `%s' (%s) packet is currently %s.\n"),
-		       config->name, config->title, support);
+      printf_filtered (_("Support for the `%s' packet is currently %s.\n"),
+		       config->name, support);
       break;
     }
 }
@@ -5564,6 +5566,9 @@ Specify the serial device it is connecte
   extended_async_remote_ops.to_mourn_inferior = extended_remote_mourn;
 }
 
+static struct cmd_list_element *remote_set_cmdlist;
+static struct cmd_list_element *remote_show_cmdlist;
+
 static void
 set_remote_cmd (char *args, int from_tty)
 {
@@ -5572,16 +5577,25 @@ set_remote_cmd (char *args, int from_tty
 static void
 show_remote_cmd (char *args, int from_tty)
 {
-  /* FIXME: cagney/2002-06-15: This function should iterate over
-     remote_show_cmdlist for a list of sub commands to show.  */
-  show_remote_protocol_Z_packet_cmd (gdb_stdout, from_tty, NULL, NULL);
-  show_remote_protocol_P_packet_cmd (gdb_stdout, from_tty, NULL, NULL);
-  show_remote_protocol_p_packet_cmd (gdb_stdout, from_tty, NULL, NULL);
-  show_remote_protocol_qSymbol_packet_cmd (gdb_stdout, from_tty, NULL, NULL);
-  show_remote_protocol_vcont_packet_cmd (gdb_stdout, from_tty, NULL, NULL);
-  show_remote_protocol_binary_download_cmd (gdb_stdout, from_tty, NULL, NULL);
-  show_remote_protocol_qPart_auxv_packet_cmd (gdb_stdout, from_tty, NULL, NULL);
-  show_remote_protocol_qGetTLSAddr_packet_cmd (gdb_stdout, from_tty, NULL, NULL);
+  /* We can't just use cmd_show_list here, because we want to skip
+     the redundant "show remote Z-packet".  */
+  struct cleanup *showlist_chain;
+  struct cmd_list_element *list = remote_show_cmdlist;
+
+  showlist_chain = make_cleanup_ui_out_tuple_begin_end (uiout, "showlist");
+  for (; list != NULL; list = list->next)
+    if (strcmp (list->name, "Z-packet") == 0)
+      continue;
+    else if (list->type == show_cmd)
+      {
+	struct cleanup *option_chain
+	  = make_cleanup_ui_out_tuple_begin_end (uiout, "option");
+	ui_out_field_string (uiout, "name", list->name);
+	ui_out_text (uiout, ":  ");
+	do_setshow_command ((char *) NULL, from_tty, list);
+	/* Close the tuple.  */
+	do_cleanups (option_chain);
+      }
 }
 
 static void
@@ -5610,9 +5624,6 @@ remote_new_objfile (struct objfile *objf
 void
 _initialize_remote (void)
 {
-  static struct cmd_list_element *remote_set_cmdlist;
-  static struct cmd_list_element *remote_show_cmdlist;
-
   /* architecture specific data */
   remote_gdbarch_data_handle = 
     gdbarch_data_register_post_init (init_remote_state);

Re: RFC: Clean up "show remote"

[Eli Zaretskii]

> Date: Sun, 22 Jan 2006 15:17:59 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> Does anyone have an opinion on this patch?  It's, um, a bit inelegant;
> but it removes the hardcoded list of subcommands in show_remote_cmd, which
> happens to be missing two.  I always try "show remote" when I want to
> remember the spelling of "set remote hardware-breakpoint-limit", but
> it didn't include that.

This patch is fine with me, in general.

> Also shorten the messages a bit by removing redundancy; either the user
> typed config->title, or it was prefixed to the output already.

I'm not quite sure I get this.  With the current code, "show remote"
outputs lines like this:

 Support for remote protocol `Z0' (software-breakpoint) packet is auto-detected,
 currently unknown.

With your change, the part in parentheses will not be displayed, so
how would the user know that Z0 is a packet that sets software
breakpoints?

> An alternative if the code in show_remote_cmd is too ugly would be to delete
> "show remote Z-packet".  I think we have to leave "set remote Z-packet" -
> it's five years obsoleted but never marked as deprecated and I know people
> are continuing to use it - but the show command is completely redundant.

I think what you did is fine, but perhaps explain a bit more in
comments about why Z-packet is redundant, and that maybe it should be
removed later on.

Re: RFC: Clean up "show remote"

[Daniel Jacobowitz]

On Mon, Jan 23, 2006 at 06:38:37AM +0200, Eli Zaretskii wrote:
> > Also shorten the messages a bit by removing redundancy; either the user
> > typed config->title, or it was prefixed to the output already.
> 
> I'm not quite sure I get this.  With the current code, "show remote"
> outputs lines like this:
> 
>  Support for remote protocol `Z0' (software-breakpoint) packet is auto-detected,
>  currently unknown.
> 
> With your change, the part in parentheses will not be displayed, so
> how would the user know that Z0 is a packet that sets software
> breakpoints?

Instead, you'll get something that looks like the current output of
"show print":

software-breakpoint-packet: Support for the `Z0' packet is auto-detected, currently unknown

I'm trying to cut down on how badly this wraps, since we can't
word-wrap in translated messages (is there any way to do that?
GCC seems to wrap using spaces even in i18n output; maybe we
could do the same, if I am interpreting that right?).

> > An alternative if the code in show_remote_cmd is too ugly would be to delete
> > "show remote Z-packet".  I think we have to leave "set remote Z-packet" -
> > it's five years obsoleted but never marked as deprecated and I know people
> > are continuing to use it - but the show command is completely redundant.
> 
> I think what you did is fine, but perhaps explain a bit more in
> comments about why Z-packet is redundant, and that maybe it should be
> removed later on.

Willdo (although I don't know if we can reasonably remove the "set"
variant - I keep finding new docs suggesting it.)

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: Clean up "show remote"

[Eli Zaretskii]

> Date: Mon, 23 Jan 2006 00:15:44 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> > With your change, the part in parentheses will not be displayed, so
> > how would the user know that Z0 is a packet that sets software
> > breakpoints?
> 
> Instead, you'll get something that looks like the current output of
> "show print":
> 
> software-breakpoint-packet: Support for the `Z0' packet is auto-detected, currently unknown

Right, I didn't catch the part before the colon, since it's in another
place in the code.

But doesn't the above looks backwards, English-wise? we first announce
the full packet name, and then say that support for its short alias is
<whatever>.  The "foo: Bar" syntax is usually reserved for messages
that come from `foo', which is not really the case here.

> I'm trying to cut down on how badly this wraps, since we can't
> word-wrap in translated messages (is there any way to do that?

The only good way is to break it into two separate messages and mark
them in i18n comments as belonging to the same phrase.  Translators
will then break the translated message as appropriate for their
language (or even produce a single line, by translating the second
part as an empty string).

> GCC seems to wrap using spaces even in i18n output; maybe we
> could do the same, if I am interpreting that right?).

If that's what GCC does, GCC is not doing TRT: wrapping on spaces
works for Latin and other similar languages, but can be dead wrong in
other scripts.

Re: RFC: Clean up "show remote"

[Jim Blandy]

One alternative to the special case for the Z packet command would be
to mark that command 'obscure', and then have the look skip over
obscure subcommands.

Re: RFC: Clean up "show remote"

[Daniel Jacobowitz]

On Mon, Jan 23, 2006 at 03:01:29PM -0800, Jim Blandy wrote:
> One alternative to the special case for the Z packet command would be
> to mark that command 'obscure', and then have the look skip over
> obscure subcommands.

I did consider that - but all the other "show remote" subcommands are
already class_obscure :-(

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: Clean up "show remote"

[Daniel Jacobowitz]

On Tue, Jan 24, 2006 at 12:44:28AM +0200, Eli Zaretskii wrote:
> > Date: Mon, 23 Jan 2006 00:15:44 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > > With your change, the part in parentheses will not be displayed, so
> > > how would the user know that Z0 is a packet that sets software
> > > breakpoints?
> > 
> > Instead, you'll get something that looks like the current output of
> > "show print":
> > 
> > software-breakpoint-packet: Support for the `Z0' packet is auto-detected, currently unknown
> 
> Right, I didn't catch the part before the colon, since it's in another
> place in the code.
> 
> But doesn't the above looks backwards, English-wise? we first announce
> the full packet name, and then say that support for its short alias is
> <whatever>.  The "foo: Bar" syntax is usually reserved for messages
> that come from `foo', which is not really the case here.

Well, it doesn't look at all unnatural to me.  It would if there were
only one of them, but there's a whole list.

To recap (from memory, forgive typos):
(gdb) show remote software-breakpoint-backet
Support for the `Z0' packet is auto-detected, currently unknown
(gdb) show remote
software-breakpoint-packet: Support for the `Z0' packet is auto-detected, currently unknown
hardware-breakpoint-packet: Support for the `Z1' packet is auto-detected, currently unknown
[more...]

> > I'm trying to cut down on how badly this wraps, since we can't
> > word-wrap in translated messages (is there any way to do that?
> 
> The only good way is to break it into two separate messages and mark
> them in i18n comments as belonging to the same phrase.  Translators
> will then break the translated message as appropriate for their
> language (or even produce a single line, by translating the second
> part as an empty string).
> 
> > GCC seems to wrap using spaces even in i18n output; maybe we
> > could do the same, if I am interpreting that right?).
> 
> If that's what GCC does, GCC is not doing TRT: wrapping on spaces
> works for Latin and other similar languages, but can be dead wrong in
> other scripts.

This would be a terrible shame.  I asked for opinions from a couple of
GCC developers, and Paolo Bonzini suggested:

> if a translator is anal about where to break, he should use non-breaking spaces
> (such as Unicode 160) and those answer false for iswspace

> iow, doing mbstowcs, breaking at iswspace, and converting back, should work.
>  but it's sort of a mess

> ask eli if that's correct.  maybe it's not.

Is that right?  If not, is there some forum where I could get a
definitive answer?  No one's ever complained about the GCC wrapping
(well, people have complained about a related problem in the English
wrapping output, but not about bad wrapping in translations as far as I
can see); and it's very convenient.  I'd love to be able to make
GDB word-break output.

Right now we just write overlength messages to the screen.  I don't see
how that can be an improvement over breaking them at whitespace instead
of at the margins, but maybe I'm missing something?

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: Clean up "show remote"

[Eli Zaretskii]

> Date: Tue, 24 Jan 2006 11:53:26 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> > If that's what GCC does, GCC is not doing TRT: wrapping on spaces
> > works for Latin and other similar languages, but can be dead wrong in
> > other scripts.
> 
> This would be a terrible shame.  I asked for opinions from a couple of
> GCC developers, and Paolo Bonzini suggested:

Btw, I don't think we should tie these two issues, they are completely
independent.  The word-wrapping problem can wait, but the cleanup is
good (modulo our disagreement about the style of the output).

Re: RFC: Clean up "show remote"

[Eli Zaretskii]

> Date: Tue, 24 Jan 2006 11:53:26 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> > > GCC seems to wrap using spaces even in i18n output; maybe we
> > > could do the same, if I am interpreting that right?).
> > 
> > If that's what GCC does, GCC is not doing TRT: wrapping on spaces
> > works for Latin and other similar languages, but can be dead wrong in
> > other scripts.
> 
> This would be a terrible shame.  I asked for opinions from a couple of
> GCC developers, and Paolo Bonzini suggested:
> 
> > if a translator is anal about where to break, he should use non-breaking spaces
> > (such as Unicode 160) and those answer false for iswspace
> 
> > iow, doing mbstowcs, breaking at iswspace, and converting back, should work.
> >  but it's sort of a mess
> 
> > ask eli if that's correct.  maybe it's not.
> 
> Is that right?

I'm not sure I understand what Paolo is saying.  If he is saying that
translators should bear the burden of forcing GDB not to break by
using NBSP, then I think it's ridiculous: software should help us, not
force us to work harder.

> If not, is there some forum where I could get a definitive answer?

For the definitive answer, look in the Unicode standard (not for the
faint at heart):

   http://www.unicode.org/reports/tr14/

> Right now we just write overlength messages to the screen.  I don't see
> how that can be an improvement over breaking them at whitespace instead
> of at the margins, but maybe I'm missing something?

I think, as long as we are not sure about how to solve this in
general, manually breaking into two messages is better than letting
code blissfully break at whitespace, because that leaves the job of
breaking in other languages to a (human) translator.

Re: RFC: Clean up "show remote"

[Daniel Jacobowitz]

On Tue, Jan 24, 2006 at 11:20:26PM +0200, Eli Zaretskii wrote:
> > > if a translator is anal about where to break, he should use non-breaking spaces
> > > (such as Unicode 160) and those answer false for iswspace
> > 
> > > iow, doing mbstowcs, breaking at iswspace, and converting back, should work.
> > >  but it's sort of a mess
> > 
> > > ask eli if that's correct.  maybe it's not.
> > 
> > Is that right?
> 
> I'm not sure I understand what Paolo is saying.  If he is saying that
> translators should bear the burden of forcing GDB not to break by
> using NBSP, then I think it's ridiculous: software should help us, not
> force us to work harder.

What he's saying is that a space in the output can be assumed to be a
safe place to line break, and if there is some reason why it should
not - from my look over the Unicode spec, a relatively rare and less
important case - then the translator would be well advised to use an
NBSP.  But, let's not focus on that yet - see below.

> > If not, is there some forum where I could get a definitive answer?
> 
> For the definitive answer, look in the Unicode standard (not for the
> faint at heart):
> 
>    http://www.unicode.org/reports/tr14/
> 
> > Right now we just write overlength messages to the screen.  I don't see
> > how that can be an improvement over breaking them at whitespace instead
> > of at the margins, but maybe I'm missing something?
> 
> I think, as long as we are not sure about how to solve this in
> general, manually breaking into two messages is better than letting
> code blissfully break at whitespace, because that leaves the job of
> breaking in other languages to a (human) translator.

Asking the translator do it defeats my goal - which is to adapt to the
user's terminal width, automatically.

I spent fifteen minutes or so looking over the relevant Unicode TR;
thank you for the reference.  I'd even be willing to implement a
substantial subset of it, if that's what it took to make GDB wrap
output prettily.  However, before I even think of doing that, I'd like
to rephrase my question.

Right now the GDB CLI is generally run either in a TTY or in some
wrapping environment (e.g. emacs).  I don't know much about the Emacs
case, but at least on a TTY, when we encounter the terminal's physical
margins we wrap - always.  No matter where we are within a word.

How is wrapping after spaces, as suggested by the Unicode TR but
without the remaining complexity of the TR, inferior to that?  We'd
check widths and space characters on the results of gettext, of course,
using appropriate wide character routines.

There are probably some cases where this would lead to oddly placed
line breaks.  I'm hypothesizing that there would be fewer oddly placed
line breaks even in the affected scripts than there are today.

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: Clean up "show remote"

[Eli Zaretskii]

> Date: Tue, 24 Jan 2006 16:48:58 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> Asking the translator do it defeats my goal - which is to adapt to the
> user's terminal width, automatically.

That's true, but does this work well with non-Latin scripts
(i.e. those where the characters' widths are not equal)?

> Right now the GDB CLI is generally run either in a TTY or in some
> wrapping environment (e.g. emacs).  I don't know much about the Emacs
> case,

The Emacs case is not interesting: Emacs disables the wrapping (both
horizontal and vertical) and wraps itself, according to its rules and
user's preferences.

> but at least on a TTY, when we encounter the terminal's physical
> margins we wrap - always.  No matter where we are within a word.

You mean, the TTY wraps, yes?

> How is wrapping after spaces, as suggested by the Unicode TR but
> without the remaining complexity of the TR, inferior to that?

It might not work at all, when there are not enough spaces in the
line.  Which is not worse than what we have now, but at least now we
don't claim we have this feature.

> We'd check widths and space characters on the results of gettext, of
> course, using appropriate wide character routines.

Will this work on terminal emulators in a graphical environment, such
as xterm?  Won't we need some knowledge about the font?

> There are probably some cases where this would lead to oddly placed
> line breaks.  I'm hypothesizing that there would be fewer oddly placed
> line breaks even in the affected scripts than there are today.

Maybe, I don't know.

Anyway, since we don't yet support i18n, perhaps we shouldn't worry
now about implementing Unicode line-breaking, or even subset thereof.
There are more important things to do, I think.  (Although, having
once written a very unorthodox implementation of the Unicode
Bidirectional Algorithm--see UAX#9 on the Unicode site--I can
easily understand how tempting can it be to sit down and implement a
significant subset of the line-breaking algorithm ;-)

Re: RFC: Clean up "show remote"

[Daniel Jacobowitz]

On Wed, Jan 25, 2006 at 12:10:15AM +0200, Eli Zaretskii wrote:
> > Date: Tue, 24 Jan 2006 16:48:58 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > Asking the translator do it defeats my goal - which is to adapt to the
> > user's terminal width, automatically.
> 
> That's true, but does this work well with non-Latin scripts
> (i.e. those where the characters' widths are not equal)?

Yes, it does.  We can use the POSIX wide character interface, which
includes wcwidth() for this purpose.

Of course, when you're in a non-fixed-width font this is going to break
down.  But terminals for languages with wide characters still seem
to use fixed-width columns, in my experience.

(That experience is somewhat limited, but I have experimented with
Chinese and Japanese terminal emulators for ncurses bug reports a
couple of times).

> The Emacs case is not interesting: Emacs disables the wrapping (both
> horizontal and vertical) and wraps itself, according to its rules and
> user's preferences.

Great.

> > but at least on a TTY, when we encounter the terminal's physical
> > margins we wrap - always.  No matter where we are within a word.
> 
> You mean, the TTY wraps, yes?

Right, that's what I meant - GDB doesn't even know where.

> > How is wrapping after spaces, as suggested by the Unicode TR but
> > without the remaining complexity of the TR, inferior to that?
> 
> It might not work at all, when there are not enough spaces in the
> line.  Which is not worse than what we have now, but at least now we
> don't claim we have this feature.

Well, that's true.  At this point I think we'd have a pretty convincing
reason to implement the rest of the TR :-)

> > We'd check widths and space characters on the results of gettext, of
> > course, using appropriate wide character routines.
> 
> Will this work on terminal emulators in a graphical environment, such
> as xterm?  Won't we need some knowledge about the font?

It'll still work - Xterm generally uses a fixed width font, even for
scripts with wide characters.  In fact this is the case I'm most
interested in (I use GDB inside "screen" inside an xterm or rxvt, 99%
of the time).

> > There are probably some cases where this would lead to oddly placed
> > line breaks.  I'm hypothesizing that there would be fewer oddly placed
> > line breaks even in the affected scripts than there are today.
> 
> Maybe, I don't know.
> 
> Anyway, since we don't yet support i18n, perhaps we shouldn't worry
> now about implementing Unicode line-breaking, or even subset thereof.
> There are more important things to do, I think.  (Although, having
> once written a very unorthodox implementation of the Unicode
> Bidirectional Algorithm--see UAX#9 on the Unicode site--I can
> easily understand how tempting can it be to sit down and implement a
> significant subset of the line-breaking algorithm ;-)

I don't want to add new features that are going to be a problem when we
do support i18n - no one's moving us further toward that goal at the
moment, but I don't want us moving gratuituously away from it, either
:-)

I speculate that the TR offers a sufficient way forward, were we to
start supporting i18n, that I don't need to feel guilty implementing
wrapping based on gettext output.  I'm not going to do it tonight,
but maybe I'll do it sometime soon - it would really make me a happier
user of GDB.

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: Clean up "show remote"

[Daniel Jacobowitz]

On Mon, Jan 23, 2006 at 12:15:44AM -0500, Daniel Jacobowitz wrote:
> > > An alternative if the code in show_remote_cmd is too ugly would be to delete
> > > "show remote Z-packet".  I think we have to leave "set remote Z-packet" -
> > > it's five years obsoleted but never marked as deprecated and I know people
> > > are continuing to use it - but the show command is completely redundant.
> > 
> > I think what you did is fine, but perhaps explain a bit more in
> > comments about why Z-packet is redundant, and that maybe it should be
> > removed later on.
> 
> Willdo (although I don't know if we can reasonably remove the "set"
> variant - I keep finding new docs suggesting it.)

I've checked in this version.  I'll be back to the line-wrapping
problem at some later date - and back to the formatting question
if anyone has a preference for that.

-- 
Daniel Jacobowitz
CodeSourcery

2006-02-01  Daniel Jacobowitz  <dan@codesourcery.com>

	* Makefile.in (remote.o): Update.
	* remote.c (show_packet_config_cmd): Shorten messages.
	(remote_set_cmdlist, remote_show_cmdlist): Make file-static.
	(show_remote_cmd): Iterate.
	(_initialize_remote): Remove remote_set_cmdlist,
	remote_show_cmdlist.

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.781
diff -u -p -r1.781 Makefile.in
--- Makefile.in	1 Feb 2006 23:14:09 -0000	1.781
+++ Makefile.in	2 Feb 2006 02:03:55 -0000
@@ -2441,7 +2441,8 @@ remote.o: remote.c $(defs_h) $(gdb_strin
 	$(symfile_h) $(exceptions_h) $(target_h) $(gdbcmd_h) $(objfiles_h) \
 	$(gdb_stabs_h) $(gdbthread_h) $(remote_h) $(regcache_h) $(value_h) \
 	$(gdb_assert_h) $(event_loop_h) $(event_top_h) $(inf_loop_h) \
-	$(serial_h) $(gdbcore_h) $(remote_fileio_h) $(solib_h) $(observer_h)
+	$(serial_h) $(gdbcore_h) $(remote_fileio_h) $(solib_h) $(observer_h) \
+	$(cli_decode_h) $(cli_setshow_h)
 remote-e7000.o: remote-e7000.c $(defs_h) $(gdbcore_h) $(gdbarch_h) \
 	$(inferior_h) $(target_h) $(value_h) $(command_h) $(gdb_string_h) \
 	$(exceptions_h) $(gdbcmd_h) $(serial_h) $(remote_utils_h) \
Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.200
diff -u -p -r1.200 remote.c
--- remote.c	24 Jan 2006 22:34:34 -0000	1.200
+++ remote.c	2 Feb 2006 02:03:56 -0000
@@ -43,6 +43,8 @@
 #include "gdb_assert.h"
 #include "observer.h"
 #include "solib.h"
+#include "cli/cli-decode.h"
+#include "cli/cli-setshow.h"
 
 #include <ctype.h>
 #include <sys/time.h>
@@ -612,13 +614,13 @@ show_packet_config_cmd (struct packet_co
   switch (config->detect)
     {
     case AUTO_BOOLEAN_AUTO:
-      printf_filtered (_("Support for remote protocol `%s' (%s) packet is auto-detected, currently %s.\n"),
-		       config->name, config->title, support);
+      printf_filtered (_("Support for the `%s' packet is auto-detected, currently %s.\n"),
+		       config->name, support);
       break;
     case AUTO_BOOLEAN_TRUE:
     case AUTO_BOOLEAN_FALSE:
-      printf_filtered (_("Support for remote protocol `%s' (%s) packet is currently %s.\n"),
-		       config->name, config->title, support);
+      printf_filtered (_("Support for the `%s' packet is currently %s.\n"),
+		       config->name, support);
       break;
     }
 }
@@ -5544,6 +5546,9 @@ Specify the serial device it is connecte
   extended_async_remote_ops.to_mourn_inferior = extended_remote_mourn;
 }
 
+static struct cmd_list_element *remote_set_cmdlist;
+static struct cmd_list_element *remote_show_cmdlist;
+
 static void
 set_remote_cmd (char *args, int from_tty)
 {
@@ -5552,16 +5557,25 @@ set_remote_cmd (char *args, int from_tty
 static void
 show_remote_cmd (char *args, int from_tty)
 {
-  /* FIXME: cagney/2002-06-15: This function should iterate over
-     remote_show_cmdlist for a list of sub commands to show.  */
-  show_remote_protocol_Z_packet_cmd (gdb_stdout, from_tty, NULL, NULL);
-  show_remote_protocol_P_packet_cmd (gdb_stdout, from_tty, NULL, NULL);
-  show_remote_protocol_p_packet_cmd (gdb_stdout, from_tty, NULL, NULL);
-  show_remote_protocol_qSymbol_packet_cmd (gdb_stdout, from_tty, NULL, NULL);
-  show_remote_protocol_vcont_packet_cmd (gdb_stdout, from_tty, NULL, NULL);
-  show_remote_protocol_binary_download_cmd (gdb_stdout, from_tty, NULL, NULL);
-  show_remote_protocol_qPart_auxv_packet_cmd (gdb_stdout, from_tty, NULL, NULL);
-  show_remote_protocol_qGetTLSAddr_packet_cmd (gdb_stdout, from_tty, NULL, NULL);
+  /* We can't just use cmd_show_list here, because we want to skip
+     the redundant "show remote Z-packet".  */
+  struct cleanup *showlist_chain;
+  struct cmd_list_element *list = remote_show_cmdlist;
+
+  showlist_chain = make_cleanup_ui_out_tuple_begin_end (uiout, "showlist");
+  for (; list != NULL; list = list->next)
+    if (strcmp (list->name, "Z-packet") == 0)
+      continue;
+    else if (list->type == show_cmd)
+      {
+	struct cleanup *option_chain
+	  = make_cleanup_ui_out_tuple_begin_end (uiout, "option");
+	ui_out_field_string (uiout, "name", list->name);
+	ui_out_text (uiout, ":  ");
+	do_setshow_command ((char *) NULL, from_tty, list);
+	/* Close the tuple.  */
+	do_cleanups (option_chain);
+      }
 }
 
 static void
@@ -5590,9 +5604,6 @@ remote_new_objfile (struct objfile *objf
 void
 _initialize_remote (void)
 {
-  static struct cmd_list_element *remote_set_cmdlist;
-  static struct cmd_list_element *remote_show_cmdlist;
-
   /* architecture specific data */
   remote_gdbarch_data_handle = 
     gdbarch_data_register_post_init (init_remote_state);
@@ -5798,7 +5809,10 @@ Show the maximum size of the address (in
 			 &remote_set_cmdlist, &remote_show_cmdlist,
 			 0);
 
-  /* Keep the old ``set remote Z-packet ...'' working.  */
+  /* Keep the old ``set remote Z-packet ...'' working.  Each individual
+     Z sub-packet has its own set and show commands, but users may
+     have sets to this variable in their .gdbinit files (or in their
+     documentation).  */
   add_setshow_auto_boolean_cmd ("Z-packet", class_obscure,
 				&remote_Z_packet_detect, _("\
 Set use of remote protocol `Z' packets"), _("\