Re: external declaration of dominance debug functions

[Richard Guenther <richard.guenther@gmail.com>]

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