On Mon, May 23, 2011 at 8:12 PM, Basile Starynkevitch <bas...@starynkevitch.net> wrote: > On Mon, 23 May 2011 11:56:32 +0200 > Piervit <pier...@pvittet.com> wrote: > >> Le Mon, 23 May 2011 11:30:34 +0200, >> Richard Guenther <richard.guent...@gmail.com> a écrit : >> >> > On Mon, May 23, 2011 at 10:33 AM, Piervit <pier...@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 <pier...@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} *** >
