Re: PING PATCH: break lines in announce_function
On 16 May 2012 20:41, Tom Tromey tro...@redhat.com wrote: Manuel * Hitting auto-completion in GDB means staring at the window for 5-10 Manuel minutes until it decides to stop listing stuff. Report completion bugs to gdb. There's only so much gdb can do here. But maybe we could have some mode to be more selective about what to complete. Well, it could do like bash. Give a message if there are more than N options and ask y/n, no? Cheers, Manuel.
Re: PING PATCH: break lines in announce_function
On Thu, May 17, 2012 at 10:24 AM, Mike Stump mikest...@comcast.net wrote: * announce_function dumps slow down Emacs (and the shell when working via SSH) when debugging anything related to libstdc++ (or any large testcase). Let's make -quiet the default. Agreed. (I had always reflexively used -quiet so that it wasn't a proble, ofr me.) -- Gaby
Re: PING PATCH: break lines in announce_function
On May 16, 2012, at 8:57 AM, Manuel López-Ibáñez lopeziba...@gmail.com wrote: I see now that any change in the underlying implementation becomes a serious annoyance for you. No, it is easy, we just need a low cost solution by which people can use the normal accessors. Once that is provided, then I think it is easy to change the underlying bits. Though, it is kinda sad that 20 years later, things are still as they were, with no improvement. I wish the steering committe would find a way to allow improvements to be made more easily in this area. I would have checked in my changes to support -g3 debugging if it were easier. I'll note, I'm not the first person to do the work, just the last.
Re: PING PATCH: break lines in announce_function
On Wed, May 16, 2012 at 2:46 PM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
Hello All,
I am pinging the patch http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html
below for trunk svn 187587
# patch
Index: gcc/toplev.c
===
--- gcc/toplev.c (revision 187587)
+++ gcc/toplev.c (working copy)
@@ -229,6 +229,12 @@
{
if (!quiet_flag)
{
+
Seems pretty arbitrary and with bogus whitespace here ^^^
So - why? I like it the way it is.
Richard.
+ static long count;
+ count++;
+ if (count % 8 == 0)
+ putc('\n', stderr);
+
if (rtl_dump_and_exit)
fprintf (stderr, %s ,
identifier_to_locale (IDENTIFIER_POINTER (DECL_NAME (decl;
### gcc/ChangeLog
entry
2011-05-16 Basile Starynkevitch bas...@starynkevitch.net
* toplev.c (announce_function): Output newline periodically.
###
Ok for trunk?
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: PING PATCH: break lines in announce_function
On Wed, May 16, 2012 at 03:02:39PM +0200, Richard Guenther wrote:
On Wed, May 16, 2012 at 2:46 PM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
Hello All,
I am pinging the patch
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html
below for trunk svn 187587
--- gcc/toplev.c(revision 187587)
+++ gcc/toplev.c(working copy)
@@ -229,6 +229,11 @@ announce_function (tree decl)
{
if (!quiet_flag)
{
+ static long count;
+ count++;
+ if (count % 8 == 0)
+putc('\n', stderr);
+
if (rtl_dump_and_exit)
fprintf (stderr, %s ,
identifier_to_locale (IDENTIFIER_POINTER (DECL_NAME (decl;
So - why? I like it the way it is.
Because, as I explained in
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html without that patch
you have arbitrarily long output lines, and that is unpleasant, in particular
when running under gdb
or under emacs (also, there may be buffering issues: if GCC misbehave, stderr
might not be flushed
often enough...)
The announce_function is quite rarely really used (because quiet_flag is almost
always true),
and it is used mostly to debug GCC (or plugins), and in that case having not
too large output
is quite useful in practice. The patch above is quick dirty but seems enough.
Do you want me to add a comment like /* Hack to avoid very large output lines.
*/ before?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: PING PATCH: break lines in announce_function
On Wed, May 16, 2012 at 3:18 PM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
On Wed, May 16, 2012 at 03:02:39PM +0200, Richard Guenther wrote:
On Wed, May 16, 2012 at 2:46 PM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
Hello All,
I am pinging the patch
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html
below for trunk svn 187587
--- gcc/toplev.c (revision 187587)
+++ gcc/toplev.c (working copy)
@@ -229,6 +229,11 @@ announce_function (tree decl)
{
if (!quiet_flag)
{
+ static long count;
+ count++;
+ if (count % 8 == 0)
+ putc('\n', stderr);
+
if (rtl_dump_and_exit)
fprintf (stderr, %s ,
identifier_to_locale (IDENTIFIER_POINTER (DECL_NAME (decl;
So - why? I like it the way it is.
Because, as I explained in
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html without that patch
you have arbitrarily long output lines, and that is unpleasant, in particular
when running under gdb
or under emacs (also, there may be buffering issues: if GCC misbehave, stderr
might not be flushed
often enough...)
stderr is unbuffered
The announce_function is quite rarely really used (because quiet_flag is
almost always true),
and it is used mostly to debug GCC (or plugins), and in that case having not
too large output
is quite useful in practice. The patch above is quick dirty but seems
enough.
Do you want me to add a comment like /* Hack to avoid very large output
lines. */ before?
No, I want the large line to stay as-is. It's pleasant for me.
Richard.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: PING PATCH: break lines in announce_function
On Wed, May 16, 2012 at 03:29:12PM +0200, Richard Guenther wrote:
On Wed, May 16, 2012 at 3:18 PM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
On Wed, May 16, 2012 at 03:02:39PM +0200, Richard Guenther wrote:
On Wed, May 16, 2012 at 2:46 PM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
Hello All,
I am pinging the patch
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html
below for trunk svn 187587
--- gcc/toplev.c (revision 187587)
+++ gcc/toplev.c (working copy)
@@ -229,6 +229,11 @@ announce_function (tree decl)
{
if (!quiet_flag)
{
+ static long count;
+ count++;
+ if (count % 8 == 0)
+ putc('\n', stderr);
+
if (rtl_dump_and_exit)
fprintf (stderr, %s ,
identifier_to_locale (IDENTIFIER_POINTER (DECL_NAME
(decl;
So - why? I like it the way it is.
Because, as I explained in
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html without that patch
you have arbitrarily long output lines, and that is unpleasant, in
particular when running under gdb
or under emacs (also, there may be buffering issues: if GCC misbehave,
stderr might not be flushed
often enough...)
stderr is unbuffered
The announce_function is quite rarely really used (because quiet_flag is
almost always true),
and it is used mostly to debug GCC (or plugins), and in that case having
not too large output
is quite useful in practice. The patch above is quick dirty but seems
enough.
Do you want me to add a comment like /* Hack to avoid very large output
lines. */ before?
No, I want the large line to stay as-is. It's pleasant for me.
Do you have any hints or tricks to have this work well when running cc1 under
emacs
(eg in a *shell* or *gud-cc1* Emacs buffer)?
Without that patch displaying happen too late (and eats a lot of Emacs CPU)!!
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: PING PATCH: break lines in announce_function
On Wed, May 16, 2012 at 3:38 PM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
On Wed, May 16, 2012 at 03:29:12PM +0200, Richard Guenther wrote:
On Wed, May 16, 2012 at 3:18 PM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
On Wed, May 16, 2012 at 03:02:39PM +0200, Richard Guenther wrote:
On Wed, May 16, 2012 at 2:46 PM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
Hello All,
I am pinging the patch
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html
below for trunk svn 187587
--- gcc/toplev.c (revision 187587)
+++ gcc/toplev.c (working copy)
@@ -229,6 +229,11 @@ announce_function (tree decl)
{
if (!quiet_flag)
{
+ static long count;
+ count++;
+ if (count % 8 == 0)
+ putc('\n', stderr);
+
if (rtl_dump_and_exit)
fprintf (stderr, %s ,
identifier_to_locale (IDENTIFIER_POINTER (DECL_NAME
(decl;
So - why? I like it the way it is.
Because, as I explained in
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html without that patch
you have arbitrarily long output lines, and that is unpleasant, in
particular when running under gdb
or under emacs (also, there may be buffering issues: if GCC misbehave,
stderr might not be flushed
often enough...)
stderr is unbuffered
The announce_function is quite rarely really used (because quiet_flag is
almost always true),
and it is used mostly to debug GCC (or plugins), and in that case having
not too large output
is quite useful in practice. The patch above is quick dirty but seems
enough.
Do you want me to add a comment like /* Hack to avoid very large output
lines. */ before?
No, I want the large line to stay as-is. It's pleasant for me.
Do you have any hints or tricks to have this work well when running cc1 under
emacs
(eg in a *shell* or *gud-cc1* Emacs buffer)?
Without that patch displaying happen too late (and eats a lot of Emacs CPU)!!
1) Fix emacs (do not buffer stderr)
2) do not omit -quiet when running from inside emacs
Richard.
Re: PING PATCH: break lines in announce_function
On 16 May 2012 15:40, Richard Guenther richard.guent...@gmail.com wrote: Without that patch displaying happen too late (and eats a lot of Emacs CPU)!! 1) Fix emacs (do not buffer stderr) 2) do not omit -quiet when running from inside emacs Actually, I wonder how you (Richard) and other GCC hackers work with and debug GCC, because it is a real pain in the ass. * All the TREE_ macros don't work. * __extension__ prevents GDB from evaluating many things. * announce_function dumps slow down Emacs (and the shell when working via SSH) when debugging anything related to libstdc++ (or any large testcase). * Hitting auto-completion in GDB means staring at the window for 5-10 minutes until it decides to stop listing stuff. There are quite a few other annoyances, but these are the most common (perhaps I should make a list in the wiki). Cheers, Manuel.
Re: PING PATCH: break lines in announce_function
On Wed, May 16, 2012 at 3:56 PM, Manuel López-Ibáñez lopeziba...@gmail.com wrote: On 16 May 2012 15:40, Richard Guenther richard.guent...@gmail.com wrote: Without that patch displaying happen too late (and eats a lot of Emacs CPU)!! 1) Fix emacs (do not buffer stderr) 2) do not omit -quiet when running from inside emacs Actually, I wonder how you (Richard) and other GCC hackers work with and debug GCC, because it is a real pain in the ass. * All the TREE_ macros don't work. I have memoized all sub-fields of tree, so I don't use those macros (still other people use them with some gdbinit macdefs and -g3). * __extension__ prevents GDB from evaluating many things. I did not run into this one yet - maybe open a GDB bug? * announce_function dumps slow down Emacs (and the shell when working via SSH) when debugging anything related to libstdc++ (or any large testcase). I always use -quiet, even when debugging. I do not use -quite when tracking down compile-time hog issues. * Hitting auto-completion in GDB means staring at the window for 5-10 minutes until it decides to stop listing stuff. That works for me. Though my debug-cc1 is built with a C compiler (yes, with C++ this will get a pain in the ass ...) There are quite a few other annoyances, but these are the most common (perhaps I should make a list in the wiki). The most common annoyance for me is stepping into trivial inline functions when trying to step into an important function, thus foo (tree_code_length (x), a, b); something people want to make even more prominent :( Richard. Cheers, Manuel.
Re: PING PATCH: break lines in announce_function
Manuel == Manuel López-Ibáñez lopeziba...@gmail.com writes: Manuel Actually, I wonder how you (Richard) and other GCC hackers work with Manuel and debug GCC, because it is a real pain in the ass. Manuel * All the TREE_ macros don't work. Manuel * __extension__ prevents GDB from evaluating many things. See that other thread... When I was debugging gcc regularly I added a bunch of macro defines to .gdbinit, and built with -g3. This fixed the macro problem and the __extension__ problem. Manuel * Hitting auto-completion in GDB means staring at the window for 5-10 Manuel minutes until it decides to stop listing stuff. Report completion bugs to gdb. There's only so much gdb can do here. But maybe we could have some mode to be more selective about what to complete. Tom
Re: PING PATCH: break lines in announce_function
Manuel == Manuel López-Ibáñez lopeziba...@gmail.com writes: Manuel It seems it will never work for statement expressions: Manuel http://article.gmane.org/gmane.comp.gcc.devel/107339 It could be done, but it is non-trivial for sure. Manuel I see how these small functions can quickly become annoying. Is it Manuel really that hard to make GDB ignore some functions? There's a new skip feature in gdb specifically for this. It is in gdb 7.4. Tom
