-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/07/11 07:42, Tom Tromey wrote:
>> "Jeff" == Jeff Law 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 candid
On Fri, Oct 07, 2011 at 07:42:44AM -0600, Tom Tromey wrote:
> > "Jeff" == Jeff Law 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. Al
> "Jeff" == Jeff Law 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 aroun
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
-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
>> wrote: What's the other advantage of using
>> inline functions? The gdb annoyance with the macros can be
>>
On Oct 6, 2011, at 1:58 AM, Richard Guenther wrote:
> On Wed, Oct 5, 2011 at 8:51 PM, Diego Novillo 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:
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 deb
On Wed, Oct 5, 2011 at 8:51 PM, Diego Novillo wrote:
> On Wed, Oct 5, 2011 at 14:20, Mike Stump 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
On Wed, Oct 5, 2011 at 6:53 PM, Diego Novillo wrote:
> On Wed, Oct 5, 2011 at 11:28, Diego Novillo wrote:
>> On Wed, Oct 5, 2011 at 10:51, Richard Guenther
>> wrote:
>>
>>> Did you also mark the function with always_inline? That's a requirement
>>> as artificial only works for inlined function
On Wed, Oct 5, 2011 at 14:20, Mike Stump 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
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 __alwa
On Wed, Oct 5, 2011 at 11:28, Diego Novillo wrote:
> On Wed, Oct 5, 2011 at 10:51, Richard Guenther
> 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.
> "Jakub" == Jakub Jelinek 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 tha
> "Diego" == Diego Novillo 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'
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
On Wed, Oct 5, 2011 at 11:27, Tom Tromey 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
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 somewher
On Wed, Oct 5, 2011 at 10:51, Richard Guenther
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.
> "Diego" == Diego Novillo 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));
On Wed, Oct 5, 2011 at 4:10 PM, Diego Novillo wrote:
> On Wed, Oct 5, 2011 at 09:45, Richard Guenther
> wrote:
>> On Wed, Oct 5, 2011 at 3:18 PM, Diego Novillo wrote:
>>> On 11-09-27 03:37 , Richard Guenther wrote:
On Tue, Sep 27, 2011 at 9:35 AM, Richard Guenther
wrote:
>
>
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
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
> in
On Wed, Oct 5, 2011 at 09:45, Richard Guenther
wrote:
> On Wed, Oct 5, 2011 at 3:18 PM, Diego Novillo wrote:
>> 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 Wed, Oct 5, 2011 at 3:18 PM, Diego Novillo wrote:
> 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 w
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.
T
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 ad
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 'n
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 anythin
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 yea
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.
In particular, I change the implementation of CHECK macros using
__extension__ into macros
30 matches
Mail list logo
