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