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 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.


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.

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