On 16 May 2012 16:02, Richard Guenther <richard.guent...@gmail.com> wrote: > 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).
Could these macdefs be loaded by default? I see now that any change in the underlying implementation becomes a serious annoyance for you. > >> * __extension__ prevents GDB from evaluating many things. > > I did not run into this one yet - maybe open a GDB bug? It seems it will never work for statement expressions: http://article.gmane.org/gmane.comp.gcc.devel/107339 >> * 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. So why not make that the default? >> * 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 :( I guess 'n' doesn't work because they are really inlined. Open a GDB bug? I guess this answer does not work both ways... :-( I see how these small functions can quickly become annoying. Is it really that hard to make GDB ignore some functions? On a more general note, there is really a conflict between the old-timers who know every little detail and have grown their custom recipes for going around annoyances, so they resist any change that breaks those recipes or their hard-won knowledge of GCC internals. And any new potential contributor, who feels that trivial things are extremely hard and time-consuming and wants to make things simpler and easier. Of course, it is not really a conflict. New contributors have little saying, which is normal because obviously they contribute the least. However, the mere fact that it is hard to contribute prevents them to contribute more. So we have 2 or 3 people that do 90% of the work, and not a long tail but a very small number of people that contribute the other 10%. Not a good prospect for the future... On this topic, I found this talk particularly interesting: http://percival-music.ca/blog/2010-08-01-sustainable-development.html However, I don't have any solutions to offer, but the situation has been a source of frustration for me since a long time, and I think also for others. Cheers, Manuel.
