This is the mail archive of the 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: Modify gcc for use with gdb (issue5132047)

On Wed, Oct 5, 2011 at 4:10 PM, Diego Novillo <> wrote:
> On Wed, Oct 5, 2011 at 09:45, Richard Guenther
> <> wrote:
>> On Wed, Oct 5, 2011 at 3:18 PM, Diego Novillo <> wrote:
>>> On 11-09-27 03:37 , Richard Guenther wrote:
>>>> On Tue, Sep 27, 2011 at 9:35 AM, Richard Guenther
>>>> <> ?wrote:
>>>>> On Tue, Sep 27, 2011 at 9:14 AM, Jakub Jelinek<> ?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.

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