* [Bug macros/9748] macros containing __extension__ won't run
2009-01-15 21:06 [Bug macros/9748] New: macros containing __extension__ won't run rearnsha at gcc dot gnu dot org
@ 2009-01-15 21:30 ` pedro at codesourcery dot com
2009-01-15 21:40 ` drow at false dot org
` (2 subsequent siblings)
3 siblings, 0 replies; 7+ messages in thread
From: pedro at codesourcery dot com @ 2009-01-15 21:30 UTC (permalink / raw)
To: gdb-prs
------- Additional Comments From pedro at codesourcery dot com 2009-01-15 21:30 -------
Subject: Re: New: macros containing __extension__ won't run
On Thursday 15 January 2009 21:06:26, rearnsha at gcc dot gnu dot org wrote:
> Consider a macro, such as the following (from GCC):
>
> #define TREE_CHECK(T, CODE) __extension__ ({ __typeof (T) const __t = (T); if
> (TREE_CODE (__t) != (CODE)) tree_check_failed (__t, __FILE__, __LINE__,
> __FUNCTION__, (CODE), 0); __t; })
>
> if the object containing the macro is compiled with -g3, then the definition is
> available to GDB, but this doesn't help much...
>
> (gdb) p TREE_CHECK (fntype, CALL_EXPR)
> No symbol "__extension__" in current context.
>
I current gdb mainline, you could try defining __extension__ to empty:
(gdb) macro define __extension__
("macro define" was stubbed in yearlier versions of gdb, it
has only recently been implemented)
I guess you'd need to do the same for __FILE__, __LINE__, etc, but I
think you'll trip on __typeof.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=9748
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug macros/9748] macros containing __extension__ won't run
2009-01-15 21:06 [Bug macros/9748] New: macros containing __extension__ won't run rearnsha at gcc dot gnu dot org
2009-01-15 21:30 ` [Bug macros/9748] " pedro at codesourcery dot com
@ 2009-01-15 21:40 ` drow at false dot org
2009-01-15 23:39 ` pedro at codesourcery dot com
2009-01-16 0:05 ` tromey at redhat dot com
3 siblings, 0 replies; 7+ messages in thread
From: drow at false dot org @ 2009-01-15 21:40 UTC (permalink / raw)
To: gdb-prs
------- Additional Comments From drow at false dot org 2009-01-15 21:40 -------
Subject: Re: macros containing __extension__ won't run
On Thu, Jan 15, 2009 at 09:30:06PM -0000, pedro at codesourcery dot com wrote:
> I current gdb mainline, you could try defining __extension__ to empty:
>
> (gdb) macro define __extension__
>
> ("macro define" was stubbed in yearlier versions of gdb, it
> has only recently been implemented)
>
> I guess you'd need to do the same for __FILE__, __LINE__, etc, but I
> think you'll trip on __typeof.
Also on statement expressions, which is what the __extension__ marker
is for in the first place :-)
I don't think statement expressions are likely to be implemented in
GDB. It currently has only a C expression parser, with no support for
statements etc.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=9748
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug macros/9748] macros containing __extension__ won't run
2009-01-15 21:06 [Bug macros/9748] New: macros containing __extension__ won't run rearnsha at gcc dot gnu dot org
2009-01-15 21:30 ` [Bug macros/9748] " pedro at codesourcery dot com
2009-01-15 21:40 ` drow at false dot org
@ 2009-01-15 23:39 ` pedro at codesourcery dot com
2009-01-16 0:05 ` tromey at redhat dot com
3 siblings, 0 replies; 7+ messages in thread
From: pedro at codesourcery dot com @ 2009-01-15 23:39 UTC (permalink / raw)
To: gdb-prs
------- Additional Comments From pedro at codesourcery dot com 2009-01-15 23:39 -------
Subject: Re: macros containing __extension__ won't run
On Thursday 15 January 2009 21:40:25, drow at false dot org wrote:
> Also on statement expressions, which is what the __extension__ marker
> is for in the first place :-)
IIRC, the __extensions__ marker is for enabling
gnu-C-isms no matter the C dialect or e.g., if -pedantic is selected,
so it's for more things, but, yeah, missed that. :-)
> I don't think statement expressions are likely to be implemented in
> GDB. It currently has only a C expression parser, with no support for
> statements etc.
Stating the obvious, you can override the checked versions
in gdb expressions with:
(gdb) macro define TREE_CHECK(T, CODE) (T)
If wanting to retain the checking ability when called from gdb,
perhaps the best would be to still override the whole TREE_CHECK macro
with macro define, retaining close enough semantics. Say, add
something like this and similars to gcc:
const_tree
gdb_tree_check (const_tree __t, int code)
{
if (TREE_CODE (__t) != code)
tree_check_failed (__t, "<gdb>", 0, "<nofunction>", code); // or call some other variant
return __t;
}
And this in .gdbinit:
macro define TREE_CHECK(T, CODE) gdb_tree_check(T, CODE)
--
http://sourceware.org/bugzilla/show_bug.cgi?id=9748
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug macros/9748] macros containing __extension__ won't run
2009-01-15 21:06 [Bug macros/9748] New: macros containing __extension__ won't run rearnsha at gcc dot gnu dot org
` (2 preceding siblings ...)
2009-01-15 23:39 ` pedro at codesourcery dot com
@ 2009-01-16 0:05 ` tromey at redhat dot com
3 siblings, 0 replies; 7+ messages in thread
From: tromey at redhat dot com @ 2009-01-16 0:05 UTC (permalink / raw)
To: gdb-prs
------- Additional Comments From tromey at redhat dot com 2009-01-16 00:05 -------
Occasionally I fantasize about putting the GCC (or clang) parsers into
gdb and having a C interpreter environment.
For the specific case of gcc, I put this into the incremental branch's
gcc/gdbinit.in:
# 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) ((T)->common.chain)
macro define TREE_TYPE(NODE) ((T)->common.type)
# Another handy one.
macro define __builtin_offsetof(T, F) ((int) &(((T *) 0)->F))
In fact, this is why I implemented "macro define" :-)
Perhaps this should go on gcc trunk at some point.
Defining __extension__ wouldn't be completely crazy.
Maybe we need "set lang gnuc".
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=9748
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 7+ messages in thread