Re: [PATCH]: add set/show debug, move gdb debugging flags into it

[Fernando Nasser <fnasser@cygnus.com>]

Daniel,

Your patch is something we've been looking forward to.  In the perspective of the CLI (which I am the maintainer) I am
eager to see it checked in.  It touches other files though, so I would rather wait for Andrew to see them overnight (his
day).

However...  your patch is removing the old command formats.  I have not yet checked in David Whedon patch for
deprecating commands (I've been *real* busy these days) so we can't use it yet.

This leaves us with two choices: we wait a week or so and use David deprecating thing, or just leave the old commands
alive for now.  In either case you would have to adjust your patch, I hope you don't mind.

Thank you very much for doing this.  This "set xyxsdert$#@%$debug" commands were really weird.

Best regards,
Fernando


Daniel Berlin wrote:
> 
> Attached is a patch to add "set debug" and "show debug", and move the gdb
> debugging stuff (targetdebug,expressiondebug,etc) into those lists.
> 
> I renamed targetdebug,expressiondebug,etc (all the debug settings i
> moved), to remove the "debug" from their name, so you do "set debug target
> 1" rather than "set debug targetdebug 1".
> 
> The new command lists are named setdebuglist/showdebuglist, and are in
> command.c.
> I put set_debug and show_debug into command.c, for lack of a better place.
> The point of all this is to make it much easier to see what debugging
> flags you can set for GDB, and what they were set to. It also declutters
> the set list.
> I also enabled monitordebug, since it said int he comment it was waiting
> for "set debug".
> 
> I have no idea who needs to approve this, since it touches a bunch of
> stuff, but is only related to one domain so to speak.
> 
> I'm working on a changelog entry,  i wanted to get comments first.
> 
> Example of what you get with the patch installed:
> (gdb) help set debug
> Generic command for setting gdb debugging flags
> List of set debug subcommands:
> set debug arch -- Set architecture debugging
> set debug event -- Set event debugging
> set debug expression -- Set expression debugging
> set debug remote -- Set debugging of remote protocol
> set debug serial -- Set serial debugging
> set debug target -- Set target debugging
> set debug varobj -- Set varobj debugging
> Type "help set debug" followed by set debug subcommand name for full
> documentation.
> Command name abbreviations are allowed if unambiguous.
> (gdb)
> 
> (gdb) help show debug
> Generic command for showing gdb debugging flags
> List of show debug subcommands:
> show debug arch -- Show architecture debugging
> show debug event -- Show event debugging
> show debug expression -- Show expression debugging
> show debug remote -- Show debugging of remote protocol
> show debug serial -- Show serial debugging
> show debug target -- Show target debugging
> show debug varobj -- Show varobj debugging
> Type "help show debug" followed by show debug subcommand name for full
> documenta
> tion.
> Command name abbreviations are allowed if unambiguous.
> (gdb)
> (gdb) show debug
> arch:  Architecture debugging is 0.
> event:  Event debugging is 0.
> expression:  Expression debugging is 0.
> remote:  Debugging of remote protocol is 0.
> serial:  Serial debugging is 0.
> target:  Target debugging is 0.
> varobj:  Varobj debugging is 0.
> (gdb) set debug
> "set debug" must be followed by the name of a print subcommand.
> List of set debug subcommands:
> set debug arch -- Set architecture debugging
> set debug event -- Set event debugging
> set debug expression -- Set expression debugging
> set debug remote -- Set debugging of remote protocol
> set debug serial -- Set serial debugging
> set debug target -- Set target debugging
> set debug varobj -- Set varobj debugging
> Type "help set debug" followed by set debug subcommand name for full
> documentati
> on.
> Command name abbreviations are allowed if unambiguous.
> (gdb)
> 
>   ------------------------------------------------------------------------------------------------------------------------
>                     Name: setdebug.diff
>    setdebug.diff    Type: Plain Text (TEXT/PLAIN)
>                 Encoding: BASE64

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFC] Notes on QUIT and STREQ et.al.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38CD7F9E.206D9351@cygnus.com>
References: <200003131412.PAA16094@landau.wins.uva.nl> <b4saaq07p.fsf@rtl.cygnus.com>
X-SW-Source: 2000-q1/msg00678.html
Content-length: 938

Jim Kingdon wrote:

> > I'm not sure if we want STREQ to go.  I think that `STREQ (a, b)' is
> > both easier to read and easier to type than `strcmp (a, b) == 0'.
> 
> Well, perhaps it is because I have gotten used to the strcmp == 0
> idiom, but I find it to be pretty annoying to have to look up a macro
> like this (sure, it _probably_ is defined in the obvious way, but you
> don't know that for sure when digging into a new program).  Granted
> strcmp == 0 is hard to understand until/unless you know the standard C
> library well enough for it to be second nature.

Well I personally prefer the forms:

	strcmp() == 0 (read: strcmp () equal)
and	strcmp() != 0 (read: strcmp () not-equal)

over ``strcmp()'' and ``!strcmp()'' as they offer a queue to the
programer but even then that style isn't a requirement.

Like you, the one I don't trust is STREQ().  I'm never 100% certain what
that macro is doing behind my back :-)

	Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Please ``withdraw'' patches
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BB29FF.2467FCE@cygnus.com>
X-SW-Source: 2000-q1/msg00410.html
Content-length: 449

Hello,

I've just spent an hour going over a patch (yes I'm working through a
long backlog) only to then find a later submission by the same author
supersedes the earlier posting.

If people withdraw or re-submit patches, could they please to a follow
up to the original posting making it clear that that submission was
withdrawn.

	enjoy,
		Andrew

(Hopefully a patch tracking system will help with this problem (although
it may not eliminate it))
From fnasser@cygnus.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: glen mccready <gkm@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFA] gdb/command.c, gdb/command.h: "help all"
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DBB714.67024F64@cygnus.com>
References: <200003241731.JAA12735@cygint.cygnus.com> <8bg9c0$3rt$1@cronkite.cygnus.com>
X-SW-Source: 2000-q1/msg00991.html
Content-length: 1267

glen mccready wrote:
> 
> I will get better at this, I'm sure. :-/
> 
That is fine.  There are lots of common practices that are not written anywhere, so you post and we tell you.  After a
short while you'll know them all and will be your turn to tell others...

> In article < 200003241731.JAA12735@cygint.cygnus.com >,
> glen mccready <gkm@cygnus.com> wrote:
> [...]
> >Fri Mar 24 12:10:38 2000  glen mccready  <gkm@pobox.com>
> >
> >       * commands.c (help_all): Add functionality to display a complete
> >       listing of available commands.
> 
> Fri Mar 24 12:10:38 2000  glen mccready  <gkm@pobox.com>
> 
>         * command.c, command.h (help_all): Add functionality to display
>         a complete listing of available commands.

Better yet:

Fri Mar 24 12:10:38 2000  glen mccready  <gkm@pobox.com>

        * command.c (help_all): New function. Add functionality
        to display a complete listing of available commands.
	* command.h: Add declaration for the above.


If nobody objects by the end of the afternoon, please check it in.

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From fnasser@cygnus.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: gdb-patches@sourceware.cygnus.com, James Ingham <jingham@cygnus.com>
Subject: RFC: Patch to make "set remotebaud" and "-b" work for RDI targets
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <3873D9FC.EF374435@cygnus.com>
X-SW-Source: 2000-q1/msg00012.html
Content-length: 1412

The baud specified on the target command itself takes precedence, but if
it has not been specified and gdb was invoked with a "-b" argument or
the user (or Insight) have issued a "set remotebaud" command, that
valued is tried (comapared against the list of valid values kept by the
rdi code).

-- 
Fernando Nasser
Cygnus Solutions - Toronto Office       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299


Index: rdi-share/serdrv.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/rdi-share/serdrv.c,v
retrieving revision 1.4
diff -c -r1.4 serdrv.c
*** serdrv.c    1999/01/28 03:50:16     1.4
--- serdrv.c    2000/01/05 23:45:25
***************
*** 32,37 ****
--- 32,39 ----
  #include "params.h"
  #include "logging.h"
  
+ extern int baud_rate;   /* From gdb/top.c */
+ 
  #ifdef COMPILING_ON_WINDOWS
  #  undef   ERROR
  #  undef   IGNORE
***************
*** 228,233 ****
--- 230,241 ----
          else
             printf( "could not understand baud rate %s\n", arg );
  #endif
+     }
+     else if (baud_rate > 0)
+     {
+       /* If the user specified a baud rate on the command line "-b" or
via
+          the "set remotebaud" command then try to use that one */
+       process_baud_rate( baud_rate );
      }
  
  #ifdef COMPILING_ON_WINDOWS
From jlarmour@redhat.co.uk Sat Apr 01 00:00:00 2000
From: Jonathan Larmour <jlarmour@redhat.co.uk>
To: fnasser@redhat.com, gdb-patches@sourceware.cygnus.com
Subject: Re: thumb_skip_prologue too adventurous
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D40052.AF731E81@redhat.co.uk>
References: <38D3FFC8.32082A85@redhat.co.uk>
X-SW-Source: 2000-q1/msg00770.html
Content-length: 1896

Jonathan Larmour wrote:
> 2000-03-18  Jonathan Larmour  <jlarmour@redhat.co.uk>
> 
>         * arm-tdep.c (thumb_skip_prologue): Take function end addr argument
>         so that we can stop searching for the prologue past the function end
>         (arm_skip_prologue): Call thumb_skip_prologue with function end addr

Doh! Patch attached.

Jifl
Index: arm-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/arm-tdep.c,v
retrieving revision 1.4
diff -u -5 -p -r1.4 arm-tdep.c
--- arm-tdep.c	2000/02/29 07:23:02	1.4
+++ arm-tdep.c	2000/03/18 22:16:21
@@ -326,20 +326,20 @@ arm_frameless_function_invocation (struc
    When we have found at least one of each class we are done with the prolog.
    Note that the "sub sp, #NN" before the push does not count.
    */
 
 static CORE_ADDR
-thumb_skip_prologue (CORE_ADDR pc)
+thumb_skip_prologue (CORE_ADDR pc, CORE_ADDR func_end)
 {
   CORE_ADDR current_pc;
   int findmask = 0;  	/* findmask:
       			   bit 0 - push { rlist }
 			   bit 1 - mov r7, sp  OR  add r7, sp, #imm  (setting of r7)
       			   bit 2 - sub sp, #simm  OR  add sp, #simm  (adjusting of sp)
 			*/
 
-  for (current_pc = pc; current_pc < pc + 40; current_pc += 2)
+  for (current_pc = pc; current_pc + 2 < func_end && current_pc < pc + 40; current_pc += 2)
     {
       unsigned short insn = read_memory_unsigned_integer (current_pc, 2);
 
       if ((insn & 0xfe00) == 0xb400)	/* push { rlist } */
 	{
@@ -397,11 +397,11 @@ arm_skip_prologue (CORE_ADDR pc)
 	return sal.end;
     }
 
   /* Check if this is Thumb code.  */
   if (arm_pc_is_thumb (pc))
-    return thumb_skip_prologue (pc);
+    return thumb_skip_prologue (pc, func_end);
 
   /* Can't find the prologue end in the symbol table, try it the hard way
      by disassembling the instructions. */
   skip_pc = pc;
   inst = read_memory_integer (skip_pc, 4);
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Comment out longest_raw_hex_string
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bsny6ls1u.fsf@rtl.cygnus.com>
References: <38C0973D.DA06DA51@cygnus.com>
X-SW-Source: 2000-q1/msg00508.html
Content-length: 452

> The attatched comments out the function longest_raw_hex_string().  It
> can be deleted in a month or so (although everyone things it isn't
> used).

Not that it's a big deal, but in case you want my advice, I'd just
delete longest_raw_hex_string now.  If there really is some reason to
resurrect it, it is in CVS.  <cynical, but based on experience>To
think that the #if 0 code would go away as soon as a month is, er,
optimistic </cynical>.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [MAINT] Minor admin tweeks
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BE0A0E.ED3A565B@cygnus.com>
References: <38BC6514.DC70948@cygnus.com> <b900153hd.fsf@rtl.cygnus.com>
X-SW-Source: 2000-q1/msg00457.html
Content-length: 769

Jim Kingdon wrote:
> 
>         * MAINTAINERS: Document people with paperwork pending.
> 
> Sorry, I'm a bit confused by this one.  Did you mean "+" rather than
> "*" for the people you added the symbol to ("*" means that they don't
> have an account, according to the key)?
> 
> Philippe De Muyter seems to have the right listing in copyright.html
> (1996-06-12).  As does JT Conklin (1998-12-21).

The ChangeLog entry (poorly worded) in combination with the file changes
have thrown a few people.
As you note, the footnotes are:

	* Indicates folks we need to get
	  Kerberos/ssh accounts ready so they
	  can write in the source tree

	+ Indicates folks that have been caught up in a paper trail.
	
I was refering to the ``account request form'' paperwork.

	Andrew
From jason@cygnus.com Sat Apr 01 00:00:00 2000
From: Jason Merrill <jason@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: dwarf2 class handling patch
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <u9ln5uhh9t.fsf@yorick.cygnus.com>
References: <199911240949.BAA18700@yorick.cygnus.com>
X-SW-Source: 2000-q1/msg00015.html
Content-length: 2206

Ping?  Without this patch, gdb gets things wrong with the current gcc.

>>>>> Jason Merrill <jason@cygnus.com> writes:

 > The dwarf2 spec says that an incomplete type will have AT_declaration set.
 > Some changes I'm making to gcc will produce class DIEs with children that
 > should still be considered incomplete.

 > 1999-11-24  Jason Merrill  <jason@casey.cygnus.com>

 > 	* dwarf2read.c (die_is_declaration): New fn.
 > 	(read_structure_scope): Use it.

 > Index: dwarf2read.c
 > ===================================================================
 > RCS file: /cvs/cvsfiles/devo/gdb/dwarf2read.c,v
 > retrieving revision 2.33
 > diff -c -p -r2.33 dwarf2read.c
 > *** dwarf2read.c	1999/10/11 21:17:22	2.33
 > --- dwarf2read.c	1999/11/24 09:38:16
 > *************** static void set_cu_language PARAMS ((uns
 > *** 621,626 ****
 > --- 621,628 ----
 >   static struct attribute *dwarf_attr PARAMS ((struct die_info *,
 >   					     unsigned int));
  
 > + static int die_is_declaration PARAMS ((struct die_info *));
 > + 
 >   static void dwarf_decode_lines PARAMS ((unsigned int, char *, bfd *));
  
 >   static void dwarf2_start_subfile PARAMS ((char *, char *));
 > *************** read_structure_scope (die, objfile)
 > *** 2202,2208 ****
 >        type within the structure itself. */
 >     die->type = type;
  
 > !   if (die->has_children)
 >       {
 >         struct field_info fi;
 >         struct die_info *child_die;
 > --- 2204,2210 ----
 >        type within the structure itself. */
 >     die->type = type;
  
 > !   if (die->has_children && ! die_is_declaration (die))
 >       {
 >         struct field_info fi;
 >         struct die_info *child_die;
 > *************** dwarf_attr (die, name)
 > *** 3700,3705 ****
 > --- 3702,3715 ----
 >     return NULL;
 >   }
  
 > + static int
 > + die_is_declaration (die)
 > +      struct die_info *die;
 > + {
 > +   return (dwarf_attr (die, DW_AT_declaration)
 > + 	  && ! dwarf_attr (die, DW_AT_specification));
 > + }
 > + 
 >   /* Decode the line number information for the compilation unit whose
 >      line number info is at OFFSET in the .debug_line section.
 >      The compilation directory of the file is passed in COMP_DIR.  */
From davidw@gordian.com Sat Apr 01 00:00:00 2000
From: David Whedon <davidw@gordian.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: Deprecating commands; Was: RFC: patch for ... 
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.BSF.3.96.1000216105317.23431r-100000@ares.gordian.com>
X-SW-Source: 2000-q1/msg00196.html
Content-length: 1887

Andrew, Fernando,

I'm happy to volunteer.  I've given it a start and I think I know where to
go with it.  I'll probably have something by the weekend.

David

Andrew Cagney wrote:
> 
> For what its worth,
> 
> Something buried on my to-do / wish list is to extend GDB's command
> mechanism so that the user is advised that a command is deprecated the
> first time they use it:
> 
>         (gdb) othernames xyz
>         warning: Command `othernames' is deprecated, use `set
architecture
> abc'.
>         (gdb) othernames zzz
>         (gdb)
> 
> Doing that opens up the possibility of moving GDB's CLI (command line
> interface) forward.  One release would have a poorly chosen command
> deprecated.  A follow on release could see it (ya!) removed.
> 
> I don't think it is reasonable to simply drop a command (no matter what
> the results of a gdb@sourceware straw poll) without some sort of warning
> to the general public.
> 
I agree with Andrew.  He proposed the "deprecated" mechanism some time
ago and it went on our TODO list.  Although I am the maintainer of the
command line interpreter and I agree with this feature, it was not done
because of the major work that we had to do for getting (part of) libgdb
out (and people were claiming for it).

If someone has the time to contribute with a patch we would appreciate. 
If not, as soon as possible we will include this "deprecated" state so
we can have a graceful phasing out of "bad" commands.

Talking about "bad" commands, what can be worse that the "set"
overloading?  It should only work for gdb control switches.  The "set
var" should be name "assign".  But who dares to change this after 15+
years...

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299