Patchwork external declaration of dominance debug functions

login
register
mail settings
Submitter Pierre Vittet
Date May 23, 2011, 8:33 a.m.
Message ID <20110523103355.71528d09@zenwalk.local>
Download mbox | patch
Permalink /patch/96838/
State New
Headers show

Comments

Pierre Vittet - May 23, 2011, 8:33 a.m.
Hello,

Here is a two lines patch, allowing to use debug_dominance_info and
debug_dominance_tree functions outside of gcc/dominance.c. For the
moment, those functions are not declared in any gcc/*.h files (as far as
I know after trying a grep). I have added them as external functions
into gcc/basic-block.h. I feel this is useful to be able to call those
functions from others files, for exemple from plugins.

ChangeLog:

2011-05-23  Pierre Vittet  <piervit@pvittet.com>

	* basic-block.h (debug_dominance_info, debug_dominance_tree):
	  Add declaration.
Basile Starynkevitch - May 23, 2011, 8:59 a.m.
On Mon, May 23, 2011 at 10:33:55AM +0200, Piervit wrote:
> 
> Here is a two lines patch, allowing to use debug_dominance_info and
> debug_dominance_tree functions outside of gcc/dominance.c. 

> +extern void debug_dominance_info (enum cdi_direction dir);
> +extern void debug_dominance_tree (enum cdi_direction dir, basic_block root);
> +
>  #include "cfghooks.h"

Please put all declarations after the #include, and add a simple comment describing 
what the functions are doing.

With this improvement, I really hope the patch will be accepted, 
because plugins really need to be able to call all the debug printing routines. 
As I told many times, debug printing routines are more useful 
for novice plugin developers that to experts working since many years on GCC.

Regards
Richard Guenther - May 23, 2011, 9:30 a.m.
On Mon, May 23, 2011 at 10:33 AM, Piervit <piervit@pvittet.com> wrote:
> Hello,
>
> Here is a two lines patch, allowing to use debug_dominance_info and
> debug_dominance_tree functions outside of gcc/dominance.c. For the
> moment, those functions are not declared in any gcc/*.h files (as far as
> I know after trying a grep). I have added them as external functions
> into gcc/basic-block.h. I feel this is useful to be able to call those
> functions from others files, for exemple from plugins.

debug_* functions are supposed to be used from interactive gdb sessions.
They should not be advertised in public headers.

Richard.

> ChangeLog:
>
> 2011-05-23  Pierre Vittet  <piervit@pvittet.com>
>
>        * basic-block.h (debug_dominance_info, debug_dominance_tree):
>          Add declaration.
Pierre Vittet - May 23, 2011, 9:56 a.m.
Le Mon, 23 May 2011 11:30:34 +0200,
Richard Guenther <richard.guenther@gmail.com> a écrit :

> On Mon, May 23, 2011 at 10:33 AM, Piervit <piervit@pvittet.com> wrote:
> > Hello,
> >
> > Here is a two lines patch, allowing to use debug_dominance_info and
> > debug_dominance_tree functions outside of gcc/dominance.c. For the
> > moment, those functions are not declared in any gcc/*.h files (as
> > far as I know after trying a grep). I have added them as external
> > functions into gcc/basic-block.h. I feel this is useful to be able
> > to call those functions from others files, for exemple from plugins.
> 
> debug_* functions are supposed to be used from interactive gdb
> sessions. They should not be advertised in public headers.
> 
> Richard.
> 
> > ChangeLog:
> >
> > 2011-05-23  Pierre Vittet  <piervit@pvittet.com>
> >
> >        * basic-block.h (debug_dominance_info, debug_dominance_tree):
> >          Add declaration.

Thank you for your answer. I am sorry I was not aware of this rule.
However I have try the following command in the gcc/ directory:

pierre@zenwalk gcc %grep " debug_*" *.h | wc -l
231

And the majority of the result are debug_* functions in header file,
such as extern void debug_tree (tree); in tree.h, extern void
debug_pass (void); in tree-pass.h and many others.
Basile Starynkevitch - May 23, 2011, 6:12 p.m.
On Mon, 23 May 2011 11:56:32 +0200
Piervit <piervit@pvittet.com> wrote:

> Le Mon, 23 May 2011 11:30:34 +0200,
> Richard Guenther <richard.guenther@gmail.com> a écrit :
> 
> > On Mon, May 23, 2011 at 10:33 AM, Piervit <piervit@pvittet.com> wrote:
> > > Hello,
> > >
> > > Here is a two lines patch, allowing to use debug_dominance_info and
> > > debug_dominance_tree functions outside of gcc/dominance.c. For the
> > > moment, those functions are not declared in any gcc/*.h files (as
> > > far as I know after trying a grep). I have added them as external
> > > functions into gcc/basic-block.h. I feel this is useful to be able
> > > to call those functions from others files, for exemple from plugins.
> > 
> > debug_* functions are supposed to be used from interactive gdb
> > sessions. They should not be advertised in public headers.
> > 
> > Richard.
> > 
> > > ChangeLog:
> > >
> > > 2011-05-23  Pierre Vittet  <piervit@pvittet.com>
> > >
> > >        * basic-block.h (debug_dominance_info, debug_dominance_tree):
> > >          Add declaration.
> 
> Thank you for your answer. I am sorry I was not aware of this rule.
> However I have try the following command in the gcc/ directory:
> 
> pierre@zenwalk gcc %grep " debug_*" *.h | wc -l
> 231
> 
> And the majority of the result are debug_* functions in header file,
> such as extern void debug_tree (tree); in tree.h, extern void
> debug_pass (void); in tree-pass.h and many others.

I was expecting Richard Guenther to say no at first to any patch,
especially when it is by a newbie. (Sorry Richie, but you do have your
reputation).   But I would like to hear the position of others (in
particular Diego Novillo, who did long time ago accept a similar patch
from my part).

If really all debug_* functions are only for the ease of gdb, they
should not be declared in public header files and should not be
available to plugins. I believe on the contrary that plugin coders need
much more than experienced GCC hackers some debug help, and that indeed
the existing debug functions are helping them.

So I don't buy Richie's argument. Otherwise, someone would propose a
patch to remove the hundreds of debug_ declarations in public header
files (i.e. those visible to plugins), and if he did, I hope such a
naughty patch won't be accepted.

As I told many many times, debug functions are mostly useful to newbies
and to plugin developers. People (like Richie) working on GCC since the
previous century don't need them. But people working on some plugins
for a few months (or young newbies starting to work on GCC) will be
desperate if these functions vanished. And these debug functions don't
cost at all: they are never called in normal GCC executions! So I don't
understand why declaring in a plugin header an existing debug function
is such an issue.

Hence, as Pierre's GSOC mentor, I told him to perservate on this patch
and I hope it will be accepted some day!!

GCC need more facilities for newbies & plugin developpers, not less!

Regards.
Richard Guenther - May 23, 2011, 8:23 p.m.
On Mon, May 23, 2011 at 8:12 PM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> On Mon, 23 May 2011 11:56:32 +0200
> Piervit <piervit@pvittet.com> wrote:
>
>> Le Mon, 23 May 2011 11:30:34 +0200,
>> Richard Guenther <richard.guenther@gmail.com> a écrit :
>>
>> > On Mon, May 23, 2011 at 10:33 AM, Piervit <piervit@pvittet.com> wrote:
>> > > Hello,
>> > >
>> > > Here is a two lines patch, allowing to use debug_dominance_info and
>> > > debug_dominance_tree functions outside of gcc/dominance.c. For the
>> > > moment, those functions are not declared in any gcc/*.h files (as
>> > > far as I know after trying a grep). I have added them as external
>> > > functions into gcc/basic-block.h. I feel this is useful to be able
>> > > to call those functions from others files, for exemple from plugins.
>> >
>> > debug_* functions are supposed to be used from interactive gdb
>> > sessions. They should not be advertised in public headers.
>> >
>> > Richard.
>> >
>> > > ChangeLog:
>> > >
>> > > 2011-05-23  Pierre Vittet  <piervit@pvittet.com>
>> > >
>> > >        * basic-block.h (debug_dominance_info, debug_dominance_tree):
>> > >          Add declaration.
>>
>> Thank you for your answer. I am sorry I was not aware of this rule.
>> However I have try the following command in the gcc/ directory:
>>
>> pierre@zenwalk gcc %grep " debug_*" *.h | wc -l
>> 231
>>
>> And the majority of the result are debug_* functions in header file,
>> such as extern void debug_tree (tree); in tree.h, extern void
>> debug_pass (void); in tree-pass.h and many others.
>
> I was expecting Richard Guenther to say no at first to any patch,
> especially when it is by a newbie. (Sorry Richie, but you do have your
> reputation).   But I would like to hear the position of others (in
> particular Diego Novillo, who did long time ago accept a similar patch
> from my part).

They clutter generic headerfiles which are supposed to present generally
usable functions.

If somebody thinks an external prototype is useful (apart from just shutting
up -Wstrict-prototypes) then please move all of these prototypes to a
new debug-functions.h headerfile.

A broken present state doesn't mean we have to continue adding to it.

> If really all debug_* functions are only for the ease of gdb, they
> should not be declared in public header files and should not be
> available to plugins. I believe on the contrary that plugin coders need
> much more than experienced GCC hackers some debug help, and that indeed
> the existing debug functions are helping them.

You can just declare them in your plugin.

> So I don't buy Richie's argument. Otherwise, someone would propose a
> patch to remove the hundreds of debug_ declarations in public header
> files (i.e. those visible to plugins), and if he did, I hope such a
> naughty patch won't be accepted.

Such a patch would be pre-approved by me ;)  Watch for not breaking
-Wstrict-prototypes and move them to their respective .c file.

> As I told many many times, debug functions are mostly useful to newbies
> and to plugin developers. People (like Richie) working on GCC since the
> previous century don't need them. But people working on some plugins

In fact I regularly use them from gdb.  And I use them for printf style
debugging as well by just sticking a prototype to wherever I need them.

Come on, you can't at the same time argue for modularization of GCC
with clean interfaces and sprinkle functions around those interfaces
that are _not_ part of any interface (but in some case randomly spit
output to random places).

> for a few months (or young newbies starting to work on GCC) will be
> desperate if these functions vanished. And these debug functions don't
> cost at all: they are never called in normal GCC executions! So I don't
> understand why declaring in a plugin header an existing debug function
> is such an issue.

plugin header?  what's that?

> Hence, as Pierre's GSOC mentor, I told him to perservate on this patch
> and I hope it will be accepted some day!!
>
> GCC need more facilities for newbies & plugin developpers, not less!

We also need them a) easily discoverable, b) easily identifiable as
if they are supposed to be used or not.

And yes, I know you, Basile, are arguing for all sorts of random stuff with
very elaborate and long e-mails.  That doesn't usually make your arguments
stronger though. (Sorry Basile, you have your reputation, too :))

Richard.

>
> 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} ***
>
Nathan Froyd - May 23, 2011, 8:42 p.m.
On 05/23/2011 04:23 PM, Richard Guenther wrote:
>> So I don't buy Richie's argument. Otherwise, someone would propose a
>> patch to remove the hundreds of debug_ declarations in public header
>> files (i.e. those visible to plugins), and if he did, I hope such a
>> naughty patch won't be accepted.
> 
> Such a patch would be pre-approved by me ;)  Watch for not breaking
> -Wstrict-prototypes and move them to their respective .c file.

JFTR, the reason some of the prototypes are in headers are that they are
*gasp* needed by multiple files in GCC (debug_tree comes to mind).  Removing
the ones that aren't so needed would be useful, but you can't delete them all
willy-nilly.

-Nathan
Richard Guenther - May 23, 2011, 8:55 p.m.
On Mon, May 23, 2011 at 10:42 PM, Nathan Froyd <froydnj@codesourcery.com> wrote:
> On 05/23/2011 04:23 PM, Richard Guenther wrote:
>>> So I don't buy Richie's argument. Otherwise, someone would propose a
>>> patch to remove the hundreds of debug_ declarations in public header
>>> files (i.e. those visible to plugins), and if he did, I hope such a
>>> naughty patch won't be accepted.
>>
>> Such a patch would be pre-approved by me ;)  Watch for not breaking
>> -Wstrict-prototypes and move them to their respective .c file.
>
> JFTR, the reason some of the prototypes are in headers are that they are
> *gasp* needed by multiple files in GCC (debug_tree comes to mind).  Removing
> the ones that aren't so needed would be useful, but you can't delete them all
> willy-nilly.

You can surely move those to a debug-functions.h file.  debug_tree is probably
an example of misuse as well  - we have a nearly perfect print_node which should
be used by other debug functions.

Richard.

> -Nathan
>
>
>
>
Basile Starynkevitch - May 24, 2011, 5:32 a.m.
On Mon, 23 May 2011 22:23:01 +0200
Richard Guenther <richard.guenther@gmail.com> wrote:
[...]
> plugin header?  what's that?
[...]

The headers made available to and installed for plugins, 
thru the PLUGIN_HEADERS variable of the gcc/Makefile.in near line 4572

After installation, plugin developers can access them because they got
installed under $(gcc -print-file-name=plugin)/include

And I strongly believe that debug functions should be declared in some
files installed there. Which file is somehow an important
implementation detail.

I am not at all sure that putting all debug functions into a
debug-functions.h brings more modularity. Because debug functions belong
more to the sub-part of GCC they are related to. So I see no win in
moving debug_tree from tree.h to an hypothetical debug-functions.h;
hence I believe that Pierre's patch is indeed necessary.

Regards.

Patch

Index: gcc/basic-block.h
===================================================================
--- gcc/basic-block.h	(revision 174056)
+++ gcc/basic-block.h	(working copy)
@@ -882,6 +882,9 @@  extern basic_block get_bb_copy (basic_block);
 void set_loop_copy (struct loop *, struct loop *);
 struct loop *get_loop_copy (struct loop *);
 
+extern void debug_dominance_info (enum cdi_direction dir);
+extern void debug_dominance_tree (enum cdi_direction dir, basic_block root);
+
 #include "cfghooks.h"
 
 /* Return true when one of the predecessor edges of BB is marked with EDGE_EH.  */