Lawrence == Lawrence Crowl cr...@google.com writes:
Lawrence Should I add that to my patch to gdbinit.in?
I think it would be helpful.
Tom
Mike == Mike Stump mikest...@comcast.net writes:
Mike Yeah, I kinda think the gdb people are wimping out by not just
Mike implementing __extension__ and ({}), which, I think get us most of the
Mike way there. Shh, don't tell them I said that.
We eagerly await your patch.
Tom
On 5/21/12, Mike Stump mikest...@comcast.net wrote:
On May 18, 2012, at 7:48 PM, Lawrence Crowl wrote:
On 5/17/12, Mike Stump mikest...@comcast.net wrote:
On May 17, 2012, at 2:41 PM, Lawrence Crowl wrote:
Reusing the compiler for this seems like the only way to go.
But, we did look at using
On 5/21/12, Tom Tromey tro...@redhat.com wrote:
Alexander == Alexander Monakov amona...@ispras.ru writes:
Alexander Hm, isn't GDB's 'set unwindonsignal on' enough to fix it?
Alexander It's useful to have that in your .gdbinit anyway, because the
Alexander same issue arises when calling
On May 23, 2012, at 3:36 PM, Lawrence Crowl wrote:
For variables that are not optimized out of memory, I think this
can work. But if you need to go for registers,
Also trivial... Just one has to generate the context correctly. One has to
save off the registers and then in the context
On Sun, May 20, 2012 at 9:10 PM, Diego Novillo dnovi...@google.com wrote:
On 12-05-20 13:59 , Richard Henderson wrote:
On 05/18/2012 04:48 PM, Diego Novillo wrote:
We can do this in trunk today using a variant of Lawrence's original
patch
On Mon, May 21, 2012 at 12:18 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Sun, May 20, 2012 at 9:10 PM, Diego Novillo dnovi...@google.com wrote:
On 12-05-20 13:59 , Richard Henderson wrote:
On 05/18/2012 04:48 PM, Diego Novillo wrote:
We can do this in trunk today using a
On May 18, 2012, at 7:48 PM, Lawrence Crowl wrote:
On 5/17/12, Mike Stump mikest...@comcast.net wrote:
On May 17, 2012, at 2:41 PM, Lawrence Crowl wrote:
Reusing the compiler for this seems like the only way to go.
But, we did look at using g++ to parse C++ expressions from gdb,
and it was
Alexander == Alexander Monakov amona...@ispras.ru writes:
Alexander Hm, isn't GDB's 'set unwindonsignal on' enough to fix it?
Alexander It's useful to have that in your .gdbinit anyway, because the
Alexander same issue arises when calling debug_* functions in cc1 from
Alexander the debugger.
On 05/18/2012 04:48 PM, Diego Novillo wrote:
We can do this in trunk today using a variant of Lawrence's original patch
(http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01649.html). This uses no C++
features, though it weakens type checking by removing away constness.
In the cxx-conversion
On 12-05-20 13:59 , Richard Henderson wrote:
On 05/18/2012 04:48 PM, Diego Novillo wrote:
We can do this in trunk today using a variant of Lawrence's original
patch (http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01649.html). This
uses no C++ features, though it weakens type checking by removing
On Thu, May 17, 2012 at 8:36 PM, Diego Novillo dnovi...@google.com wrote:
On 12-05-17 10:52 , Michael Matz wrote:
Cross the bridge when you reach it, not before. Not everybody agrees that
the splitting of tree would be a good idea. Right now templates aren't
necessary, so you shouldn't use
On 12-05-18 06:14 , Richard Guenther wrote:
As you retain the macros anyway you can simply not return anything
from the C++ checking functions define to a stmt expression
({ check_in_cxx (t); t; })
Sure, but that takes us back to the original gdb issue: it does not
understand statement
On Fri, May 18, 2012 at 1:46 PM, Diego Novillo dnovi...@google.com wrote:
On 12-05-18 06:14 , Richard Guenther wrote:
As you retain the macros anyway you can simply not return anything
from the C++ checking functions define to a stmt expression
({ check_in_cxx (t); t; })
Sure, but that
On 18 May 2012 12:46, Diego Novillo dnovi...@google.com wrote:
On 12-05-18 06:14 , Richard Guenther wrote:
As you retain the macros anyway you can simply not return anything
from the C++ checking functions define to a stmt expression
({ check_in_cxx (t); t; })
Sure, but that takes us back
On 05/18/12 05:06, Richard Guenther wrote:
Can you locate those? I mean, most uses look like
#define DECL_NONSHAREABLE(NODE) \
(TREE_CHECK2 (NODE, VAR_DECL, \
RESULT_DECL)-decl_common.decl_nonshareable_flag)
thus they only dereference the result, not assign it anywhere.
On 12-05-18 18:14 , Richard Henderson wrote:
On 05/18/12 05:06, Richard Guenther wrote:
Can you locate those? I mean, most uses look like
#define DECL_NONSHAREABLE(NODE) \
(TREE_CHECK2 (NODE, VAR_DECL, \
RESULT_DECL)-decl_common.decl_nonshareable_flag)
thus they only
On 12-05-18 08:23 , Jay Foad wrote:
What's wrong with:
(check_in_cxx(t), t)
?
This evaluates 't' twice.
Diego.
On 5/17/12, Mike Stump mikest...@comcast.net wrote:
On May 17, 2012, at 2:41 PM, Lawrence Crowl wrote:
Reusing the compiler for this seems like the only way to go.
But, we did look at using g++ to parse C++ expressions from gdb,
and it was too slow :-(. We're going to look again, at least to
On 5/18/12, Diego Novillo dnovi...@google.com wrote:
So, I would like to figure out what to do with this. We have
a usability problem wrt deubgging that I would like to fix.
The only way we have of using all the tree accessor macros from
GDB is to convert the checks into functions (converting
On 12-05-17 10:52 , Michael Matz wrote:
Cross the bridge when you reach it, not before. Not everybody agrees that
the splitting of tree would be a good idea. Right now templates aren't
necessary, so you shouldn't use them. (well, and an investigation why
they come up with smaller .text would
Lawrence == Lawrence Crowl cr...@google.com writes:
Tom Doesn't this mean that if you have checking enabled, and you use the
Tom wrong macro on some tree, cc1 will crash? That seems like a distinct
Tom minus to me.
Lawrence Yes, it does mean that, but it is a net overall improvement.
It is a
On Thu, May 17, 2012 at 1:53 PM, Tom Tromey tro...@redhat.com wrote:
Lawrence == Lawrence Crowl cr...@google.com writes:
Tom Doesn't this mean that if you have checking enabled, and you use the
Tom wrong macro on some tree, cc1 will crash? That seems like a distinct
Tom minus to me.
On 5/17/12, Tom Tromey tro...@redhat.com wrote:
Lawrence == Lawrence Crowl cr...@google.com writes:
Tom Doesn't this mean that if you have checking enabled, and you use
Tom the wrong macro on some tree, cc1 will crash? That seems like
Tom a distinct minus to me.
Lawrence Yes, it does mean
On Tue, May 15, 2012 at 7:19 PM, Lawrence Crowl 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.
In particular,
On 12-05-16 05:41 , Richard Guenther wrote:
What's the reason for templating these functions? They all take trees as
parameter!?
True. I don't recall what Lawrence had in mind, but I remember that by
using templates here, you don't need to deal with the mess of
distinguishing tree from
On Wed, May 16, 2012 at 2:43 PM, Diego Novillo dnovi...@google.com wrote:
On 12-05-16 05:41 , Richard Guenther wrote:
What's the reason for templating these functions? They all take trees as
parameter!?
True. I don't recall what Lawrence had in mind, but I remember that by
using
On 12-05-16 09:00 , Richard Guenther wrote:
On Wed, May 16, 2012 at 2:43 PM, Diego Novillodnovi...@google.com wrote:
On 12-05-16 05:41 , Richard Guenther wrote:
What's the reason for templating these functions? They all take trees as
parameter!?
True. I don't recall what Lawrence had in
On Wed, May 16, 2012 at 3:16 PM, Diego Novillo dnovi...@google.com wrote:
On 12-05-16 09:00 , Richard Guenther wrote:
On Wed, May 16, 2012 at 2:43 PM, Diego Novillodnovi...@google.com
wrote:
On 12-05-16 05:41 , Richard Guenther wrote:
What's the reason for templating these functions?
On 12-05-16 09:27 , Richard Guenther wrote:
There's less typing if you use the template variant. Not sure why
you say there is less type safety with templates.
Because it accepts any type as tree argument?
Yes and no. It accepts any type that responds to tree
operations and has the same
On Wed, May 16, 2012 at 3:40 PM, Diego Novillo dnovi...@google.com wrote:
On 12-05-16 09:27 , Richard Guenther wrote:
There's less typing if you use the template variant. Not sure why
you say there is less type safety with templates.
Because it accepts any type as tree argument?
Yes and
Il 16/05/2012 15:27, Richard Guenther ha scritto:
Two bootstrapped compilers built exactly the same, except one was using the
template version, the other using the straight inline functions with
const_tree parameters and CONST_CAST_TREE in return values.
That's of course not exactly the
Lawrence == Lawrence Crowl cr...@google.com writes:
Lawrence The effect is that it now possible to get useful responses to gdb
Lawrence command like
Lawrence (gdb) print DECL_FUNCTION_CODE (decl)
Doesn't this mean that if you have checking enabled, and you use the
wrong macro on some tree,
On 5/16/12, Richard Guenther richard.guent...@gmail.com wrote:
On May 16, 2012 Diego Novillo dnovi...@google.com wrote:
On 12-05-16 09:00 , Richard Guenther wrote:
On May 16, 2012 Diego Novillodnovi...@google.com wrote:
On 12-05-16 05:41 , Richard Guenther wrote:
What's the reason
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
On Tue, May 15, 2012 at 7:19 PM, Lawrence Crowl 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.
Index:
On 12-05-15 14:23 , Steven Bosscher wrote:
On Tue, May 15, 2012 at 7:19 PM, Lawrence Crowlcr...@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
On May 15, 2012, at 11:23 AM, Steven Bosscher wrote:
On Tue, May 15, 2012 at 7:19 PM, Lawrence Crowl 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
On 12-05-15 13:19 , Lawrence Crowl 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.
In particular, I change the implementation of
39 matches
Mail list logo
