[Bug macros/9748] New: macros containing __extension__ won't run

[Bug macros/9748] New: macros containing __extension__ won't run

[rearnsha at gcc dot gnu dot org]

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.

-- 
           Summary: macros containing __extension__ won't run
           Product: gdb
           Version: 6.7
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: macros
        AssignedTo: unassigned at sourceware dot org
        ReportedBy: rearnsha at gcc dot gnu dot org
                CC: gdb-prs at sourceware dot org


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.

[Bug macros/9748] macros containing __extension__ won't run

[pedro at codesourcery dot com]

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

[Bug macros/9748] macros containing __extension__ won't run

[drow at false dot org]

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

[Bug macros/9748] macros containing __extension__ won't run

[pedro at codesourcery dot com]

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

[Bug macros/9748] macros containing __extension__ won't run

[tromey at redhat dot com]

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