Re: Modify gcc for use with gdb (issue5132047)

[Diego Novillo <dnovillo at google dot com>]

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.

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.


Thanks.  Diego.