From: Pedro Alves <pedro@codesourcery.com>
To: Matt Rice <ratmice@gmail.com>
Cc: gdb-patches@sourceware.org, Doug Evans <dje@google.com>
Subject: Re: Rename "info definitions"?
Date: Thu, 29 Sep 2011 14:01:00 -0000 [thread overview]
Message-ID: <201109291456.47303.pedro@codesourcery.com> (raw)
In-Reply-To: <CACTLOFpbaBafSjnTXqL9wMEtB39at4Zu0Wqx_Dgac_R2QiC6gQ@mail.gmail.com>
On Thursday 29 September 2011 14:42:42, Matt Rice wrote:
> On Thu, Sep 29, 2011 at 6:28 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> > On Thursday 29 September 2011 14:26:19, Pedro Alves wrote:
> >> We could just add it back if we ever find a need though.
> >> If a language needing it for macros would require adding more
> >> such switches to other commands.
> >
> > Err, I meant, "I suspect a language needing it for macros would
> > require adding more such switches to other commands."
>
> None of the other macro commands accept options, they just interpret
> the entire string as a
> name currently, so this is a new form of c-ism
>
> I think all that would be required is just turning the macro printing
> formatters into language based callbacks, and the macro expansion
> parser into language based callbacks.
Still, I'm really not sure doing just that would be a good idea. You
can always run a C preprocessor on some non-C sources. If it's a
compiled language, the compiler should be able to output c preprocessor
macro debug info in that case too. I think that "info macros" and friends
(possibly renamed to c-macros?) should would still operate on the C
preprocessor macros / text expansion level in that case, instead of on
whatever the target language calls macros, and a new command specific
for the language's macros would be added.
> but who knows what you would run into if you actually tried.
Exactly. :-)
--
Pedro Alves
next prev parent reply other threads:[~2011-09-29 13:57 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
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 [this message]
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=201109291456.47303.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=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