Re: Modify gcc for use with gdb (issue5132047)

[Tom Tromey]

 Jeff == Jeff Law l...@redhat.com writes:

Jeff Presumably it hasn't been included because not all gdb's understand
Jeff those bits and we typically don't build with -g3.

GCC is pretty much the perfect candidate for a -g3 build.  All those
macros...

The needed gdb changes have been in since right around when I added that
patch to the incremental branch.  Anybody with a  3 year old gdb should
upgrade :-)

Tom

Re: Modify gcc for use with gdb (issue5132047)

[Jakub Jelinek]

On Fri, Oct 07, 2011 at 07:42:44AM -0600, Tom Tromey wrote:
  Jeff == Jeff Law l...@redhat.com writes:
 
 Jeff Presumably it hasn't been included because not all gdb's understand
 Jeff those bits and we typically don't build with -g3.
 
 GCC is pretty much the perfect candidate for a -g3 build.  All those
 macros...
 
 The needed gdb changes have been in since right around when I added that
 patch to the incremental branch.  Anybody with a  3 year old gdb should
 upgrade :-)

A  3 years old gdb is useless for debugging gcc anyway, it won't understand
epilogue unwind info, discriminators, lots of .debug_info stuff added
in the last few years and not even the .debug_macro format.

Jakub

Re: Modify gcc for use with gdb (issue5132047)

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/07/11 07:42, Tom Tromey wrote:
 Jeff == Jeff Law l...@redhat.com writes:
 
 Jeff Presumably it hasn't been included because not all gdb's 
 understand Jeff those bits and we typically don't build with -g3.
 
 GCC is pretty much the perfect candidate for a -g3 build.  All 
 those macros...
 
 The needed gdb changes have been in since right around when I added
 that patch to the incremental branch.  Anybody with a  3 year old
 gdb should upgrade :-)
Hard to argue with that :-)  Gone are the days when I'd build a binary
tool of some sort and use it for many years thereafter.  I doubt
there's any binary on my boxes older than a year...

jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOjx63AAoJEBRtltQi2kC7fXoH/13uE6l2klTOFPrAKbTszo5s
0fxtmLD9NQWyeOFuGL4P9O9J6rChdulFvY9oNlWUrJIwF7WTOp4FjqNZnhvzoIT8
zEqoT8yVO7pNS7KMyRbxJxz5iEx8pX0YW2O2Rl/qZGy/hFKatqaOgz/RuBZy4lg2
NpiKWULKRsc66FxPKhCPMqtSd338XOhC0S67D2GuK1qD93SFDEyoQbaViieMlmoo
qr5oFn1052byWd3J1cPbu5vv76YLnzPEmBybm0k/ZaoGFC/JidDghQvR9uHtBbbl
LLsFIej62rzCLWZTfbgaiAfKZv79msjhZIrhv8T9iSAolUG4KDvLCvP8SbUg6XI=
=KKKR
-END PGP SIGNATURE-

Re: Modify gcc for use with gdb (issue5132047)

[Richard Guenther]

On Wed, Oct 5, 2011 at 6:53 PM, Diego Novillo dnovi...@google.com wrote:
 On Wed, Oct 5, 2011 at 11:28, Diego Novillo dnovi...@google.com wrote:
 On Wed, Oct 5, 2011 at 10:51, Richard Guenther
 richard.guent...@gmail.com wrote:

 Did you also mark the function with always_inline?  That's a requirement
 as artificial only works for inlined function bodies.

 Yeah.  It doesn't quite work as I expect it to.  It steps into the
 function at odd places.

 So, I played with this some more with this, and there seems to be some
 inconsistency in how these attributes get handled.
 http://sourceware.org/bugzilla/show_bug.cgi?id=13263

 static inline int foo (int) __attribute__((always_inline,artificial));

 static inline int foo (int x)
 {
  int y  = x - 3;
  return y;
 }

 int bar (int y)
 {
  return y == 0;
 }

 main ()
 {
  foo (10);
  return bar (foo (3));
 }

 With GCC 4.7, the stand alone call foo(10) is not ignored by 'step'.
 However, the embedded call bar(foo(3)) is ignored as I was expecting.

Hm, nothing is ignored for me with gcc 4.6.


 Diego.

Re: Modify gcc for use with gdb (issue5132047)

[Richard Guenther]

On Wed, Oct 5, 2011 at 8:51 PM, Diego Novillo dnovi...@google.com wrote:
 On Wed, Oct 5, 2011 at 14:20, Mike Stump mikest...@comcast.net wrote:
 On Oct 5, 2011, at 6:18 AM, Diego Novillo wrote:
 I think we need to find a solution for this situation.

 The solution Apple found and implemented is a __nodebug__ attribute, as can 
 be seen in Apple's gcc.

 We use it like so:

 #define __always_inline__ __always_inline__, __nodebug__
 #undef __always_inline__

 in headers like mmintrn.h:

 __STATIC_INLINE void __attribute__((__always_inline__))
 /* APPLE LOCAL end radar 5618945 */
 _mm_empty (void)
 {
  __builtin_ia32_emms ();
 }

 Ah, nice.  Though, one of the things I am liking more and more about
 the blacklist solution is that it (a) does not need any modifications
 to the source code, and (b) it works with no-inline functions as well.

 This gives total control to the developer.  I would blacklist a bunch
 of functions I never care to go into, for instance.  Others may choose
 to blacklist a different set.  And you can change that from debug
 session to the next.

 I agree with Jakub that artificial functions should be blacklisted
 automatically, however.

 Richi, Jakub, if the blacklist solution was implemented in GCC would
 you agree with promoting these macros into inline functions?  This is
 orthogonal to http://sourceware.org/bugzilla/show_bug.cgi?id=13263, of
 course.

I know you are on to that C++ thing and ending up returning a reference
to make it an lvalue.  Which I very much don't like (please, if you go
that route add _set functions and lower the case of the macros).

What's the other advantage of using inline functions?  The gdb
annoyance with the macros can be solved with the .gdbinit macro
defines (which might be nice to commit to SVN btw).

Richard.


 Thanks.  Diego.

Re: Modify gcc for use with gdb (issue5132047)

[Diego Novillo]

On 11-10-06 04:58 , Richard Guenther wrote:


I know you are on to that C++ thing and ending up returning a reference
to make it an lvalue.  Which I very much don't like (please, if you go
that route add _set functions and lower the case of the macros).


Not necessarily.  I'm after making the debugging experience easier 
(among other things).  Only a handful of macros were converted into 
functions in this patch, not all of them.  We may not *need* to convert 
all of them either.



What's the other advantage of using inline functions?  The gdb
annoyance with the macros can be solved with the .gdbinit macro
defines (which might be nice to commit to SVN btw).


Static type checking, of course.  Ability to set breakpoints, and as 
time goes on, more inline functions will start showing up.


We already have several.  The blacklist feature would solve your 
annoyance with tree_operand_length, too.  Additionally, blacklist can 
deal with non-inline functions, which can be useful.



Diego.

Re: Modify gcc for use with gdb (issue5132047)

[Mike Stump]

On Oct 6, 2011, at 1:58 AM, Richard Guenther wrote:
 On Wed, Oct 5, 2011 at 8:51 PM, Diego Novillo dnovi...@google.com wrote:
 What's the other advantage of using inline functions?  The gdb
 annoyance with the macros can be solved with the .gdbinit macro
 defines (which might be nice to commit to SVN btw).

http://old.nabble.com/-incremental--Patch%3A-FYI%3A-add-accessor-macros-to-gdbinit-td17370385.html

And yet, this still isn't in gcc.  :-(  I wonder how much programmer 
productivity we've lost due to it.

Re: Modify gcc for use with gdb (issue5132047)

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/06/11 12:46, Mike Stump wrote:
 On Oct 6, 2011, at 1:58 AM, Richard Guenther wrote:
 On Wed, Oct 5, 2011 at 8:51 PM, Diego Novillo
 dnovi...@google.com wrote: What's the other advantage of using
 inline functions?  The gdb annoyance with the macros can be
 solved with the .gdbinit macro defines (which might be nice to
 commit to SVN btw).
 
 http://old.nabble.com/-incremental--Patch%3A-FYI%3A-add-accessor-macros-to-gdbinit-td17370385.html

  And yet, this still isn't in gcc.  :-(  I wonder how much
 programmer productivity we've lost due to it.
Presumably it hasn't been included because not all gdb's understand
those bits and we typically don't build with -g3.

Personally, the accessors I use are muscle-memory...  Which works
great until someone buries everything a level deeper :(

jeff

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOjfkaAAoJEBRtltQi2kC7nz0H/iOeU6/iqNBfMDGUMaJbFe/R
rbBFKJzAR6IOXWBJzlnA+d1qvpF5z1GsdfkqtaLImKrAFNsbv1LV58X3lc7l8yLQ
TGgLVuZPc/cJ8q0fyAd1rDBGsxRrapm5cPgyMFhl9eY1pC9pejAcbqLnXxRmIs41
NyohojHLu09o+WRkjNg79TOyapFNnY8w0Hz6PuFOyYv/eYthZ5dw9+N1XyUKey/M
6GHAOqTD3iQKz9QsG5dc+SVfTPLkToOnAZ5y8TnupFay9aLRXUlXDpFHZbre9h5C
ICK8FnWf74Xemw79ID94WWwomdND69myTf7bMlD4pFiHK3Wz6fPeR1GIdTixi7s=
=BrUJ
-END PGP SIGNATURE-

Re: Modify gcc for use with gdb (issue5132047)

[Mike Stump]

On Oct 6, 2011, at 11:53 AM, Jeff Law wrote:
 Presumably it hasn't been included because not all gdb's understand
 those bits and we typically don't build with -g3.

 Personally, the accessors I use are muscle-memory...  Which works
 great until someone buries everything a level deeper :(

Yeah, which works great for encouraging new comers that doing anything with gcc 
is hard.  They, by definition, don't have the muscle memory, and the 
documentation that describes which memory their muscles should have is hard to 
find, or non-existant.  I'd merely favor any approach to make their life 
easier, -g3, a gdb macro package, all inline functions, no macros...

Re: Modify gcc for use with gdb (issue5132047)

[Diego Novillo]

On 11-09-27 03:37 , Richard Guenther wrote:

On Tue, Sep 27, 2011 at 9:35 AM, Richard Guenther
richard.guent...@gmail.com  wrote:

On Tue, Sep 27, 2011 at 9:14 AM, Jakub Jelinekja...@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 sreturnfinishreturn  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.

Re: Modify gcc for use with gdb (issue5132047)

[Diego Novillo]

On Wed, Oct 5, 2011 at 09:45, Richard Guenther
richard.guent...@gmail.com wrote:
 On Wed, Oct 5, 2011 at 3:18 PM, Diego Novillo dnovi...@google.com wrote:
 On 11-09-27 03:37 , Richard Guenther wrote:

 On Tue, Sep 27, 2011 at 9:35 AM, Richard Guenther
 richard.guent...@gmail.com  wrote:

 On Tue, Sep 27, 2011 at 9:14 AM, Jakub Jelinekja...@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 sreturnfinishreturn  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.

 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 

Re: Modify gcc for use with gdb (issue5132047)

[Jakub Jelinek]

On Wed, Oct 05, 2011 at 10:10:44AM -0400, Diego Novillo wrote:
  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.

If it doesn't work, then something should be done about it in gdb.
Hiding the inlines altogether from the debugger is undesirable, it is
better if the debugger has choice what to do, still the default should
be that it ignores the artificial inlines in the backtraces as well as when
stepping through, e.g. glibc headers use artificial attribute heavily
for inlines which are of no interest to users to step through too.

Jakub

Re: Modify gcc for use with gdb (issue5132047)

[Ian Lance Taylor]

Diego Novillo dnovi...@google.com 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.

Ian

Re: Modify gcc for use with gdb (issue5132047)

[Richard Guenther]

On Wed, Oct 5, 2011 at 4:10 PM, Diego Novillo dnovi...@google.com wrote:
 On Wed, Oct 5, 2011 at 09:45, Richard Guenther
 richard.guent...@gmail.com wrote:
 On Wed, Oct 5, 2011 at 3:18 PM, Diego Novillo dnovi...@google.com wrote:
 On 11-09-27 03:37 , Richard Guenther wrote:

 On Tue, Sep 27, 2011 at 9:35 AM, Richard Guenther
 richard.guent...@gmail.com  wrote:

 On Tue, Sep 27, 2011 at 9:14 AM, Jakub Jelinekja...@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 sreturnfinishreturn  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 

Re: Modify gcc for use with gdb (issue5132047)

[Tom Tromey]

 Diego == Diego Novillo dnovi...@google.com writes:

Diego Tom, Cary, Ian, any suggestions?  We are trying to figure out a
Diego compromise for tiny inline functions that are generally a nuisance
Diego when debugging.  The scenario is a call like this: big_function_foo
Diego (inlined_f (x), inlined_g (y));
Diego We want to use 's' to step inside the call to big_function_foo(), but
Diego we don't want to step into either inlined_f() or inlined_g().

FWIW, I wrote the macro define stuff that Paolo posted back when I was
actively hacking on gcc.  I consider it to be mildly superior to the
inline approach, because it circumvents the runtime type checking --
this is a plus because it means that if I type the wrong thing to gdb it
doesn't cause cc1 to abort.  At least, this is a plus for me, since I
make mistakes like that with reasonable frequency.

Diego I proposed extending #pragma GCC options to bracket these functions
Diego with -g0.  This would help reduce the impact of debug info size.

I think this is fixing the wrong component: it means making a
one-size-fits-all decision in the gcc build, instead of just making the
debugger be more flexible.

If you want to pursue the inline function approach, I suggest
resurrecting this gdb patch:

http://sourceware.org/bugzilla/show_bug.cgi?id=8287
http://sourceware.org/ml/gdb-patches/2010-06/msg00417.html

Then you could add the appropriate blacklisting commands to gcc's
.gdbinit by default.

Tom

Re: Modify gcc for use with gdb (issue5132047)

[Diego Novillo]

On Wed, Oct 5, 2011 at 10:51, Richard Guenther
richard.guent...@gmail.com wrote:

 Did you also mark the function with always_inline?  That's a requirement
 as artificial only works for inlined function bodies.

Yeah.  It doesn't quite work as I expect it to.  It steps into the
function at odd places.


Diego.

Re: Modify gcc for use with gdb (issue5132047)

[Paolo Carlini]

On 10/05/2011 05:27 PM, Tom Tromey wrote:
FWIW, I wrote the macro define stuff that Paolo posted back when I 
was actively hacking on gcc.
Yes, thanks Tom! Actually, I suspected that, but couldn't remember where 
I actually got it from, maybe you posted it on a public discussion 
thread somewhere...


Paolo.

Re: Modify gcc for use with gdb (issue5132047)

[Diego Novillo]

On Wed, Oct 5, 2011 at 11:27, Tom Tromey tro...@redhat.com wrote:

 Diego I proposed extending #pragma GCC options to bracket these functions
 Diego with -g0.  This would help reduce the impact of debug info size.

 I think this is fixing the wrong component: it means making a
 one-size-fits-all decision in the gcc build, instead of just making the
 debugger be more flexible.

That's true.

 If you want to pursue the inline function approach, I suggest
 resurrecting this gdb patch:

    http://sourceware.org/bugzilla/show_bug.cgi?id=8287
    http://sourceware.org/ml/gdb-patches/2010-06/msg00417.html

 Then you could add the appropriate blacklisting commands to gcc's
 .gdbinit by default.

I think this could work.  I'm not sure I like the idea of having to
specify all these blacklist commands, but I appreciate how it can make
debugging more flexible.

Is this patch stalled?  the last I see is Justin's reply to review
feedback, but no indication of whether it will be accepted.

Richi, Jakub, Lawrence, would you be OK with this approach?  IIUC,
this means we'd have to add a bunch of blacklist commands to
gcc/gdbinit.in.

This does ties us to gdb, but I don't think that's a problem.

How does this work with C++?  Do the functions need to be specified
with their mangled names?


Diego.

Re: Modify gcc for use with gdb (issue5132047)

[Jakub Jelinek]

On Wed, Oct 05, 2011 at 11:42:51AM -0400, Diego Novillo wrote:
 Richi, Jakub, Lawrence, would you be OK with this approach?  IIUC,
 this means we'd have to add a bunch of blacklist commands to
 gcc/gdbinit.in.

I don't mind if it goes into gdb, but IMHO the blacklisting should
definitely default to blacklisting DW_AT_artificial inline functions
(and allowing to unblacklist them), because the artificial attribute
has been designed for that purpose already more than 4 years ago
and many headers use it.

Jakub

Re: Modify gcc for use with gdb (issue5132047)

[Tom Tromey]

 Diego == Diego Novillo dnovi...@google.com writes:

Tom    http://sourceware.org/bugzilla/show_bug.cgi?id=8287

Diego I think this could work.  I'm not sure I like the idea of having to
Diego specify all these blacklist commands, but I appreciate how it can make
Diego debugging more flexible.

Yeah, that's a drawback, since you have to remember to update .gdbinit.

Diego Is this patch stalled?  the last I see is Justin's reply to review
Diego feedback, but no indication of whether it will be accepted.

The thread continues in the next month:

http://sourceware.org/ml/gdb-patches/2010-07/threads.html#00318

The patch needed some updates.  I don't know what happened.

Diego How does this work with C++?  Do the functions need to be specified
Diego with their mangled names?

I would hope not, but I don't remember any more.

Tom

Re: Modify gcc for use with gdb (issue5132047)

[Tom Tromey]

 Jakub == Jakub Jelinek ja...@redhat.com writes:

Jakub I don't mind if it goes into gdb, but IMHO the blacklisting should
Jakub definitely default to blacklisting DW_AT_artificial inline functions
Jakub (and allowing to unblacklist them), because the artificial attribute
Jakub has been designed for that purpose already more than 4 years ago
Jakub and many headers use it.

Could you file a gdb bug report for this?

In general I'd appreciate it if folks making debug changes to gcc filed
bug reports against gdb.  I do follow the gcc list looking for things
like this, but I miss things sometimes, and this isn't really the best
way.

Tom

Re: Modify gcc for use with gdb (issue5132047)

[Diego Novillo]

On Wed, Oct 5, 2011 at 11:28, Diego Novillo dnovi...@google.com wrote:
 On Wed, Oct 5, 2011 at 10:51, Richard Guenther
 richard.guent...@gmail.com wrote:

 Did you also mark the function with always_inline?  That's a requirement
 as artificial only works for inlined function bodies.

 Yeah.  It doesn't quite work as I expect it to.  It steps into the
 function at odd places.

So, I played with this some more with this, and there seems to be some
inconsistency in how these attributes get handled.
http://sourceware.org/bugzilla/show_bug.cgi?id=13263

static inline int foo (int) __attribute__((always_inline,artificial));

static inline int foo (int x)
{
  int y  = x - 3;
  return y;
}

int bar (int y)
{
  return y == 0;
}

main ()
{
  foo (10);
  return bar (foo (3));
}

With GCC 4.7, the stand alone call foo(10) is not ignored by 'step'.
However, the embedded call bar(foo(3)) is ignored as I was expecting.


Diego.

Re: Modify gcc for use with gdb (issue5132047)

[Mike Stump]

On Oct 5, 2011, at 6:18 AM, Diego Novillo wrote:
 I think we need to find a solution for this situation.

The solution Apple found and implemented is a __nodebug__ attribute, as can be 
seen in Apple's gcc.

We use it like so:

#define __always_inline__ __always_inline__, __nodebug__
#undef __always_inline__

in headers like mmintrn.h:

__STATIC_INLINE void __attribute__((__always_inline__))
/* APPLE LOCAL end radar 5618945 */
_mm_empty (void)
{
  __builtin_ia32_emms ();
}

to disappear the debug information for all the routines, so that the context is 
the context in which the routine is called (because the routine is always 
inlined).  It is implemented and works great.  Easy to use and understand.  
Since we use the #define, #undef around the functions, it is mostly equivalent 
to #pragma, though, it does attach a little closer to the function.  You can 
strip #.* from the .i files, and not have it removed (which is nice).

Re: Modify gcc for use with gdb (issue5132047)

[Diego Novillo]

On Wed, Oct 5, 2011 at 14:20, Mike Stump mikest...@comcast.net wrote:
 On Oct 5, 2011, at 6:18 AM, Diego Novillo wrote:
 I think we need to find a solution for this situation.

 The solution Apple found and implemented is a __nodebug__ attribute, as can 
 be seen in Apple's gcc.

 We use it like so:

 #define __always_inline__ __always_inline__, __nodebug__
 #undef __always_inline__

 in headers like mmintrn.h:

 __STATIC_INLINE void __attribute__((__always_inline__))
 /* APPLE LOCAL end radar 5618945 */
 _mm_empty (void)
 {
  __builtin_ia32_emms ();
 }

Ah, nice.  Though, one of the things I am liking more and more about
the blacklist solution is that it (a) does not need any modifications
to the source code, and (b) it works with no-inline functions as well.

This gives total control to the developer.  I would blacklist a bunch
of functions I never care to go into, for instance.  Others may choose
to blacklist a different set.  And you can change that from debug
session to the next.

I agree with Jakub that artificial functions should be blacklisted
automatically, however.

Richi, Jakub, if the blacklist solution was implemented in GCC would
you agree with promoting these macros into inline functions?  This is
orthogonal to http://sourceware.org/bugzilla/show_bug.cgi?id=13263, of
course.


Thanks.  Diego.

Re: Modify gcc for use with gdb (issue5132047)

[Jakub Jelinek]

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.

Jakub

Re: Modify gcc for use with gdb (issue5132047)

[Richard Guenther]

On Tue, Sep 27, 2011 at 9:14 AM, Jakub Jelinek ja...@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 sreturnfinishreturn 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.

Richard.

        Jakub

Re: Modify gcc for use with gdb (issue5132047)

[Richard Guenther]

On Tue, Sep 27, 2011 at 9:35 AM, Richard Guenther
richard.guent...@gmail.com wrote:
 On Tue, Sep 27, 2011 at 9:14 AM, Jakub Jelinek ja...@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 sreturnfinishreturn 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.

 Richard.

        Jakub

Re: Modify gcc for use with gdb (issue5132047)

[Paolo Carlini]

On 09/27/2011 12:05 AM, cr...@google.com wrote:

The gcc source uses several constructs that GDB does not understand.
This patch corrects some of them.  It affects only compilers built
with ENABLE_TREE_CHECKING, and hence release compilers are unaffected.
This is funny. I have been using for years and years the attached 
.gdbinit, assuming it was part of life ;) (I don't know much about gdb, 
it's clear)


Paolo.
# Redefine any macro from tree.h that uses a statement expression.
# Last in case of failure.
macro define TREE_CHECK(T, CODE) (T)
macro define TREE_NOT_CHECK(T, CODE) (T)
macro define TREE_CHECK2(T, CODE1, CODE2) (T)
macro define TREE_NOT_CHECK2(T, CODE1, CODE2) (T)
macro define TREE_CHECK3(T, CODE1, CODE2, CODE3) (T)
macro define TREE_NOT_CHECK3(T, CODE1, CODE2, CODE3) (T)
macro define TREE_CHECK4(T, CODE1, CODE2, CODE3, CODE4) (T)
macro define NON_TREE_CHECK4(T, CODE1, CODE2, CODE3, CODE4) (T)
macro define TREE_CHECK5(T, CODE1, CODE2, CODE3, CODE4, CODE5) (T)
macro define TREE_NOT_CHECK5(T, CODE1, CODE2, CODE3, CODE4, CODE5) (T)
macro define CONTAINS_STRUCT_CHECK(T, STRUCT) (T)
macro define TREE_CLASS_CHECK(T, CLASS) (T)
macro define TREE_RANGE_CHECK(T, CODE1, CODE2) (T)
macro define OMP_CLAUSE_SUBCODE_CHECK(T, CODE) (T)
macro define OMP_CLAUSE_RANGE_CHECK(T, CODE1, CODE2) (T)
macro define EXPR_CHECK(T) (T)
macro define GIMPLE_STMT_CHECK(T) (T)
macro define NON_TYPE_CHECK(T) (T)
macro define TREE_VEC_ELT_CHECK(T, I) ((T)-vec.a[I])
macro define PHI_NODE_ELT_CHECK(T, I) ((T)-phi.a[I])
macro define OMP_CLAUSE_ELT_CHECK(T, I) ((T)-omp_clause.ops[I])
macro define TREE_OPERAND_CHECK(T, I) ((T)-exp.operands[I])
macro define TREE_OPERAND_CHECK_CODE(T, CODE, I) ((T)-exp.operands[I])
macro define GIMPLE_STMT_OPERAND_CHECK(T, I) ((T)-gstmt.operands[I])
macro define TREE_RTL_OPERAND_CHECK(T, CODE, I) ((T)-exp.operands[I])
macro define TREE_CHAIN(NODE) ((NODE)-common.chain)
macro define TREE_TYPE(NODE) ((NODE)-common.type)
# Paolo
macro define LANG_TYPE_CLASS_CHECK(NODE) (TYPE_LANG_SPECIFIC (NODE)-u.c)
macro define LANG_TYPE_PTRMEM_CHECK(NODE) (TYPE_LANG_SPECIFIC (NODE)-u.ptrmem)
# Another handy one.
macro define __builtin_offsetof(T, F) ((int) (((T *) 0)-F))