On Wed, Oct 5, 2011 at 4:10 PM, Diego Novillo <dnovi...@google.com> wrote:
> On Wed, Oct 5, 2011 at 09:45, Richard Guenther
> <richard.guent...@gmail.com> wrote:
>> On Wed, Oct 5, 2011 at 3:18 PM, Diego Novillo <dnovi...@google.com> wrote:
>>> On 11-09-27 03:37 , Richard Guenther wrote:
>>>>
>>>> On Tue, Sep 27, 2011 at 9:35 AM, Richard Guenther
>>>> <richard.guent...@gmail.com> wrote:
>>>>>
>>>>> On Tue, Sep 27, 2011 at 9:14 AM, Jakub Jelinek<ja...@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.
Did you also mark the function with always_inline? That's a requirement
as artificial only works for inlined function bodies.
>> 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.
>
