Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Kingdon <kingdon@redhat.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFC] Notes on QUIT and STREQ et.al.
Date: Mon, 13 Mar 2000 09:15:00 -0000	[thread overview]
Message-ID: <b4saaq07p.fsf@rtl.cygnus.com> (raw)
In-Reply-To: <200003131412.PAA16094@landau.wins.uva.nl>

> Well, STRCMP really doesn't make any sense.  A decent compiler in
> combination with appropriate headers will take care of the
> optimization.

I agree.  Trying to second-guess the compiler/library might even be
slower (not that I've done any benchmarking, mind you, just that I
have a hunch that comparing the first word rather than the first byte
might be a win on some architectures/situations).

> 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.

As for QUIT, I agree that it should be possible to be a function.  If
the functional call overhead ends up mattering, it is being called too
often (for one thing, the test of quit_flag and interactive_flag are
also going to slow things down unnecessarily).
From fnasser@cygnus.com Mon Mar 13 10:50:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: add set/show debug, move gdb debugging flags into it
Date: Mon, 13 Mar 2000 10:50:00 -0000
Message-id: <38CD37F8.D1B20C40@cygnus.com>
References: <Pine.LNX.4.10.10003130852170.6968-200000@localhost.localdomain>
X-SW-Source: 2000-03/msg00234.html
Content-length: 4359

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 rearnsha@arm.com Mon Mar 13 11:20:00 2000
From: Richard Earnshaw <rearnsha@arm.com>
To: gdb-patches@sourceware.cygnus.com
Cc: rearnsha@arm.com
Subject: ARM patch -- extra info about cpsr register
Date: Mon, 13 Mar 2000 11:20:00 -0000
Message-id: <200003131918.TAA21085@cam-mail2.cambridge.arm.com>
X-SW-Source: 2000-03/msg00235.html
Content-length: 632

Time I sorted out some of my local changes...

This patch provides a useful additional decoding of the CPSR register for 
ARM ports of GDB for commands such as "info reg".  It translates the 
setting of the CPSR into a set of mnemonic letters representing the 
settings of the various flag bits as documented in the data sheet (upper 
case for set bits, lower case for clear bits) -- generally I find this 
much more intelligible than the raw numbers.

<date>  Richard Earnshaw (rearnsha@arm.com)

	* arm-tdep.c (arm_print_register_hook): New function.
	* arm/tm-arm.h (PRINT_REGISTER_HOOK): Call it.
	(FLAG_*): New bits in CPSR.



       reply	other threads:[~2000-03-13  9:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200003131412.PAA16094@landau.wins.uva.nl>
2000-03-13  9:15 ` Jim Kingdon [this message]
     [not found] <38CCC819.1071F28E@cygnus.com>
2000-03-13  8:28 ` Kevin Buettner
2000-03-13 11:50   ` J.T. Conklin
2000-04-01  0:00 ` Andrew Cagney
     [not found] ` <5m1z5emy7b.fsf@jtc.redbacknetworks.com>
2000-04-01  0:00   ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b4saaq07p.fsf@rtl.cygnus.com \
    --to=kingdon@redhat.com \
    --cc=gdb-patches@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox