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)

Diego Novillo <> writes:

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

Yes.  We experienced gcc developers can adapt to the tools, and we can
modify the tools to work better.  We should not hold up code
improvements because of tool deficiencies.  We should fix both problems,
but we don't have to fix them in sequence.

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

This is a general problem when debugging C++ programs, so any solution
to this gcc-specific issue will be of general use.  However, I don't
know of a way to make it work today without changing gdb.  There is a
lot I don't know about gdb, so it is possible that there is some
approach that will work.

Basically, gdb's relatively new support for debugging inline functions
is sometimes nice, but sometimes it just gets in the way.  I guess the
most general solution is a way to mark the inline function in the source
as uninteresting.  I don't really understand the doc for the
"artificial" function attribute, but it looks like it was intended to
serve this purpose.  So it seems to me that there is a bug in gdb:
"step" should not step into a function with the "artificial" attribute.
I agree that it does not currently work that way.  Looking at the gdb
sources, it seems to me that it currently ignores DW_AT_artificial on an
ordinary function.


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