public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Basile Starynkevitch <basile@starynkevitch.net>
To: gcc@gcc.gnu.org
Subject: debug & trace printing from GCC plugins (& MELT extensions)
Date: Mon, 07 Mar 2011 15:40:00 -0000	[thread overview]
Message-ID: <20110307163958.85f23bdd.basile@starynkevitch.net> (raw)


Hello All,

I have a "philosophical" question about debug & trace printing from
inside GCC plugins (beyond the nearly useless answer that plugins being
outside of GCC could do what they wish), in particular from MELT (&
MELT extensions).

For various reasons (in particular because debugging MELT code with gdb
is possible, but not very fun) I like to have debug printing. For
instance, I added the DBGPRINTF macro inside gengtype.

Likewise, both the melt runtime (ie the melt.so metaplugin itself) and
MELT code extensively uses such debug & trace printing.

Of course, it can be (and usually it is) disabled, both at configure &
compile time and at run time. So the average user don't see it at all.
However, plugin developers find it quite useful, and MELT extensions
could not be easily developped without (and probably, any other big GCC
plugin).

So please accept (at least temporily) the usefulness of debug & trace
printing.

My question then is how to implement it nicely?

To have it disabled at configure time, the trick is very easy:
I wrap such debug printing with #if ENABLE_CHECKING

To have it disabled at runtime, I also have an easy trick. An option,
eg -fplugin-melt-arg-debug.

My question is then, where should the debug printing go? 

I usually print to dump_file -and wrap the call with something similar
to 
#if ENABLE_CHECKING
#define dbgprintf_raw(Fmt,...) do{if (want_debug && dump_file) \
      {fprintf(dump_file, Fmt, ##__VA_ARGS__); fflush(dump_file);}}while
(0)
#define dbgprintf(Fmt,...) dbgprintf_raw("@%s:%d: " Fmt "\n", \
 basename(__FILE__), __LINE__, ##__VA_ARGS__)
#else
#define dbgprintf(Fmt,...) (void)0
#endif

However, debug printing to dump_file is not always appropriate:

Some code, in particular code called from plugin initialization, is
called outside of any pass. In that case, dump_file is null (and I even
added shameful tricks to temporarily set it stderr & restore it to NULL)

And I don't know if debug printing should go to stdout or to stderr.

Your insights are welcome. How do you add debug printing inside your plugins?

Regards.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

             reply	other threads:[~2011-03-07 15:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-07 15:40 Basile Starynkevitch [this message]
2011-03-08 21:08 ` Dave Korn
2011-03-09  6:15   ` Basile Starynkevitch

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=20110307163958.85f23bdd.basile@starynkevitch.net \
    --to=basile@starynkevitch.net \
    --cc=gcc@gcc.gnu.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).