Re: Modify gcc for use with gdb (issue5132047)

[Diego Novillo <dnovillo at google dot com>]

On Wed, Oct 5, 2011 at 09:45, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Oct 5, 2011 at 3:18 PM, Diego Novillo <dnovillo@google.com> wrote:
>> On 11-09-27 03:37 , Richard Guenther wrote:
>>>
>>> On Tue, Sep 27, 2011 at 9:35 AM, Richard Guenther
>>> <richard.guenther@gmail.com> Âwrote:
>>>>
>>>> On Tue, Sep 27, 2011 at 9:14 AM, Jakub Jelinek<jakub@redhat.com> Âwrote:
>>>>>
>>>>> On Mon, Sep 26, 2011 at 03:05:00PM -0700, Lawrence Crowl wrote:
>>>>>>
>>>>>> There a non-transparent change in behavior that may affect some users.
>>>>>> The inline functions will introduce additional lines in a sequence of
>>>>>> gdb 'step' commands. ÂUse 'next' instead.
>>>>>
>>>>> That is IMHO a serious obstackle. ÂIf anything, the inlines should
>>>>> use always_inline, artificial attributes, but don't know if GDB treats
>>>>> them
>>>>> already specially and doesn't step into them with step.
>>>>> Also, I'm afraid it will significantly grow cc1plus/cc1 debug info.
>>>>>
>>>>> The .gdbinit macro redefinition Paolo posted sounds to be a better
>>>>> approach.
>>>>
>>>> Yeah, I already see me typing s<return>finish<return> Âgazillion of times
>>>> when
>>>> trying to step into a function call that produces a function argument
>>>> ... there is
>>>> already the very very very annoying tree_code_length function that you
>>>> get for
>>>> each TREE_OPERAND (...) macro on function arguments. ÂI'd be very opposed
>>>> to any change that makes this situation worse.
>>>
>>> tree_operand_length actually. ÂPlease produce a patch that makes this
>>> function
>>> transparent to gdb, then I might be convinced converting the other macros
>>> to
>>> such function might be worthwhile.
>>>
>>> Thanks,
>>> Richard.
>>
>> I think we need to find a solution for this situation. ÂThe suggestions I
>> see in this thread are nothing but workarounds to cope with current
>> debugging limitations. ÂWe have learned to live with them and hack around
>> them, but debugging GCC is already a daunting task, and I think we can
>> improve it.
>>
>> Richard, yes, stepping into one-liner inline functions can be aggravating
>> (particularly with some of the 2-3 embedded function calls we have in some
>> places). ÂHowever, the ability to easily inspect state of data structures
>> using the standard accessors is fundamental. Particularly, for developers
>> that may not have the extensive knowledge of internals that you do.
>
> It is much more important to optimize my debugging time as experienced
> developer resources are more scarce than some random unexperienced
> guy that happens to dig into GCC.
>
> ;)
>
> or not really ;).

You are being facetious, I hope.  Part of the reason that experienced
developers are scarce is precisely because dealing with GCC's code
base is so daunting.  We should be trying to attract those random
inexperienced developers, not scare them away.

The experienced developers will retire, eventually.  Who is going to
replace them?


>> Jakub, is size of a debuggable cc1/cc1plus really all that important? Yes,
>> more debug info makes for bigger binaries. ÂBut when debugging, that hardly
>> matters. ÂUnless we were talking about a multi-Gb binary, which we aren't.
>>
>> I would like to solve this problem for all inline functions that we may not
>> care to step into. ÂThere is a whole bunch of one-liners that generally
>> annoy me: tree_operand_length, gimple_op, ... in fact, all the gimple
>> accessors, etc.
>>
>> How about one of these two ideas?
>>
>> 1- Add -g to the list of supported settings in #pragma GCC optimize (or
>> create a new #pragma GCC no_debug). ÂThis way, we can brace all these one
>> liners with:
>>
>> #pragma push_options
>> #pragma GCC optimize ("-g0")
>> [ ... inline functions ... ]
>> #pragma pop_options
>>
>>
>> 2- Similar to #1, but with __attribute__ in each function declaration. I
>> think I prefer #1 since it's simpler for the user to specify.
>>
>>
>> This would also let us generate smaller debug binaries, since the bracketed
>> functions would not get any debug info at all.
>>
>> Any reason why that scheme couldn't work? ÂIt works well for separate TUs.
>
> If you crash inside those -g0 marked functions, what happens?

You don't see the body of the function, but you can go up into the
exact call site.

> Why
> not use the artificial attribute on them instead? ÂAt least what is documented
> is exactly what we want (well, at least it seems to me).

Yes, I forgot to mention in my reply.  I tried it, but you still step
into the functions.  If this is a bug with the attribute, then it
could be fixed.

> Thus, produce a patch that improves tree_operand_length with either
> approach so we can test it.

I have a slight preference for making these functions totally opaque
to the debugger.  But may be there is a setting we can use that will
not affect step and still give us some debug info in the presence of
crashes.

Tom, Cary, Ian, any suggestions?  We are trying to figure out a
compromise for tiny inline functions that are generally a nuisance
when debugging.  The scenario is a call like this: big_function_foo
(inlined_f (x), inlined_g (y));
We want to use 's' to step inside the call to big_function_foo(), but
we don't want to step into either inlined_f() or inlined_g().

I tried __attribute__((artificial)), but that is either buggy on the
gcc side or the gdb side, because I am still getting into the inlined
function (with -g3).

I proposed extending #pragma GCC options to bracket these functions
with -g0.  This would help reduce the impact of debug info size.

Thoughts?


Thanks.  Diego.