From: Doug Evans <dje@google.com>
To: Matt Rice <ratmice@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: Rename "info definitions"?
Date: Fri, 23 Sep 2011 17:38:00 -0000 [thread overview]
Message-ID: <CADPb22SaaAhEaVnZxYj2oJE7NDtfNUbTTaiPVeUb+fGKPxR1sw@mail.gmail.com> (raw)
In-Reply-To: <CACTLOFpW7o0rBh4ctKGa3gez9E7fbxVfZK82Gr4XR3iVWhCoJw@mail.gmail.com>
On Wed, Sep 21, 2011 at 12:33 PM, Matt Rice <ratmice@gmail.com> wrote:
> On Wed, Sep 21, 2011 at 12:04 PM, Doug Evans <dje@google.com> wrote:
>> Hi.
>>
>> I was wondering if it's not too late to rename "info definitions",
>> or better delete it and enhance "info macros" to replace it.
>> I look at "info definitions" and think "Definitions of what? That could be
>> anything." and then I find out what it refers to, look at both
>> "info macros" and "info definitions", and wish I didn't have to
>> think about when to use which one.
>>
>
> IMO not too late since its never hit a tar ball
>
> in fact I'd tried to merge info macros/info definitions but the
> resulting command would have 2 optional arguments, and be fairly
> difficult to comprehend.
>
> now that I think about it maybe add an optional arg to 'info macro'
> replace `info definitions MACRO' with 'info macro -all MACRO' ?
That would be better alright.
Also, I see calls to error() when there are no macros.
I think this shouldn't be an error.
For example, if it were done in a script it shouldn't break the script
if no macro info was found.
An informational message would be better IMO.
"info var foo" doesn't print an error on stripped binaries, for example.
E.g. here:
if (! ms || ! ms->file || ! ms->file->table)
error (_("GDB has no preprocessor macro information for that code."));
next prev parent reply other threads:[~2011-09-23 17:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-21 19:34 Doug Evans
2011-09-21 20:28 ` Matt Rice
2011-09-23 17:38 ` Doug Evans [this message]
2011-09-29 2:16 ` Matt Rice
2011-09-29 7:20 ` Eli Zaretskii
2011-09-29 10:55 ` Pedro Alves
2011-09-29 12:41 ` Matt Rice
2011-09-29 13:28 ` Pedro Alves
2011-09-29 13:37 ` Pedro Alves
2011-09-29 13:56 ` Matt Rice
2011-09-29 14:01 ` Pedro Alves
2011-10-03 21:18 ` Matt Rice
2011-10-04 16:51 ` Tom Tromey
2011-10-05 0:31 ` Matt Rice
2011-10-14 20:23 ` Tom Tromey
2011-11-12 17:03 ` Matt Rice
2011-11-12 17:09 ` Matt Rice
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=CADPb22SaaAhEaVnZxYj2oJE7NDtfNUbTTaiPVeUb+fGKPxR1sw@mail.gmail.com \
--to=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=ratmice@gmail.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