debug & trace printing from GCC plugins (& MELT extensions)

debug & trace printing from GCC plugins (& MELT extensions)

[Basile Starynkevitch]

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} ***

Re: debug & trace printing from GCC plugins (& MELT extensions)

[Dave Korn]

On 07/03/2011 15:39, Basile Starynkevitch wrote:

> So please accept (at least temporily) the usefulness of debug & trace
> printing.
> 
> My question then is how to implement it nicely?

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

  MELT is for writing new passes, right?  So it could use the existing
per-pass dump files mechanism I would expect.

    cheers,
      DaveK

Re: debug & trace printing from GCC plugins (& MELT extensions)

[Basile Starynkevitch]

On Tue, 08 Mar 2011 21:07:39 +0000
Dave Korn <dave.korn.cygwin@gmail.com> wrote:

> On 07/03/2011 15:39, Basile Starynkevitch wrote:
> 
> > So please accept (at least temporily) the usefulness of debug & trace
> > printing.
> > 
> > My question then is how to implement it nicely?
> 
> > And I don't know if debug printing should go to stdout or to stderr.
> 
>   MELT is for writing new passes, right?  So it could use the existing
> per-pass dump files mechanism I would expect.


Yes, but some processing happens outside passes (like complex
initializations at least). And I believe this is also true for some
other plugins. The question becoms where and how should the debug
printing happens in that case.

I'm sure the question is not MELT specific. Imagine a plugin (coded in
C) which uses some database, or some web services, or provide a web or
a graphical interface. Then its initialization code also need debug
printing.

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} ***