This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PING PATCH: break lines in announce_function


On 16 May 2012 16:02, Richard Guenther <richard.guenther@gmail.com> wrote:
> On Wed, May 16, 2012 at 3:56 PM, Manuel López-Ibáñez
> <lopezibanez@gmail.com> wrote:
>> On 16 May 2012 15:40, Richard Guenther <richard.guenther@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]