This is the mail archive of the
mailing list for the GCC project.
Re: Modify gcc for use with gdb (issue5132047)
- From: Diego Novillo <dnovillo at google dot com>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Lawrence Crowl <crowl at google dot com>, reply at codereview dot appspotmail dot com, gcc-patches at gcc dot gnu dot org
- Date: Wed, 05 Oct 2011 09:18:08 -0400
- Subject: Re: Modify gcc for use with gdb (issue5132047)
- References: <20110926220500.9254022266A@jade.mtv.corp.google.com> <20110927071447.GJ2687@tyan-ft48-01.lab.bos.redhat.com> <CAFiYyc1F+qt8c4XTBn=Jp2WCdOLppkWaPahnmxUfd97K43v7UA@mail.gmail.com> <CAFiYyc14=_KNGBqm9-6C3ZMCLjPmP1UDzbmZOsPLFpi20=UEpA@mail.gmail.com>
On 11-09-27 03:37 , Richard Guenther wrote:
On Tue, Sep 27, 2011 at 9:35 AM, Richard Guenther
On Tue, Sep 27, 2011 at 9:14 AM, Jakub Jelinek<firstname.lastname@example.org> 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.
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 GCC optimize ("-g0")
[ ... inline functions ... ]
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.