avoiding gdb cc1plus PACK_EXPANSION_PATTERN(result) gives 'No symbol "__extension__"', error msg

avoiding gdb cc1plus PACK_EXPANSION_PATTERN(result) gives 'No symbol "__extension__"', error msg

[Larry Evans]

I compiled gcc with -g3 -O0' compiler flags to enable invocation of 
macros during a gdb session; however, the
macro,  PACK_EXPANSION_PATTERN, apparently uses a symbol:

   __extension__

not understood by gdb.  How can gdb be made to understand
__extension__ or how can __extension__ be rm'ed from the
macros?

More specifically, while in pt.c:

http://gcc.gnu.org/viewcvs/trunk/gcc/cp/pt.c?revision=149351&view=markup

at around line 2671, I got:

(gdb) p PACK_EXPANSION_PATTERN(result)
No symbol "__extension__" in current context.
(gdb)

Now, I could use 'macro exp' as follows:

(gdb) macro exp PACK_EXPANSION_PATTERN(result)
expands to: (((enum tree_code) (result)->base.code) == 
TYPE_PACK_EXPANSION? __extension__ (*({__typeof (result) const __t = 
(result); &__t->common.type; })) : __extension__ (*({__typeof (result) 
const __t = __extension__ ({ __typeof (result) const __t = (result); 
char const __c = tree_code_type[(int) (((enum tree_code) 
(__t)->base.code))]; if (!((__c) >= tcc_reference && (__c) <= 
tcc_expression)) tree_class_check_failed (__t, tcc_expression, __FILE__, 
__LINE__, __FUNCTION__); __t; }); const int __i = (0); if (__i < 0 || 
__i >= tree_operand_length (__t)) tree_operand_check_failed (__i, __t, 
__FILE__, __LINE__, __FUNCTION__); &__t->exp.operands[__i]; })))
(gdb)

However, that's very hard to parse (FWIW, the result I was looking
for was result->common.type; however, my first guess was 
result->exp.operands[0], and that was wrong :( )

It would be much easier if gdb understood __extension__. Is there a way?

TIA.

-regards,
Larry

Re: avoiding gdb cc1plus PACK_EXPANSION_PATTERN(result) gives 'No symbol "__extension__"', error msg

[Richard Henderson]

On 07/08/2009 03:11 PM, Larry Evans wrote:
> It would be much easier if gdb understood __extension__. Is there a way?

In this case, no.  It's protecting a statement expression, which gdb 
will never be able to parse.

A better project for helping debug gcc would be to convert all macros 
that use statement expressions into proper inline functions.  Which 
would then be emitted as out-of-line functions by gcc's -fkeep-inlines 
flag, which would yield something that's callable from within gdb.


r~

Re: avoiding gdb cc1plus PACK_EXPANSION_PATTERN(result) gives 'No symbol "__extension__"', error msg

[Daniel Jacobowitz]

On Wed, Jul 08, 2009 at 03:14:20PM -0700, Richard Henderson wrote:
> On 07/08/2009 03:11 PM, Larry Evans wrote:
> >It would be much easier if gdb understood __extension__. Is there a way?
> 
> In this case, no.  It's protecting a statement expression, which gdb
> will never be able to parse.
> 
> A better project for helping debug gcc would be to convert all macros
> that use statement expressions into proper inline functions.  Which
> would then be emitted as out-of-line functions by gcc's
> -fkeep-inlines flag, which would yield something that's callable from
> within gdb.

FWIW, as a GDB maintainer I completely agree with Richard.  We could
teach GDB to ignore __extension__, which is used in some other places
(like "long long").  You can even do this from the command line using
"macro define":

(gdb) macro define __extension__
(gdb) p __extension__ 1
$1 = 1

That's all that's necessary; it's used to suppress warnings.

Statement expressions, on the other hand, are right out.  I can't see
any practical way to teach GDB about that.

-- 
Daniel Jacobowitz
CodeSourcery

Re: avoiding gdb cc1plus PACK_EXPANSION_PATTERN(result) gives 'No symbol "__extension__"', error msg

[Ian Lance Taylor]

Richard Henderson <rth@redhat.com> writes:

> A better project for helping debug gcc would be to convert all macros
> that use statement expressions into proper inline functions.  Which
> would then be emitted as out-of-line functions by gcc's -fkeep-inlines
> flag, which would yield something that's callable from within gdb.

Conveniently, if you build with C++, the inline functions can return
references, so you don't have to change hundreds of occurrences of
  REG_ATTRS (x) = ...;
into
  SET_REG_ATTRS (x, ...);

You do still have to face the problem that the macros are often defined
before the structures that they use, so simple replacement with inline
functions fails.

Ian

Re: avoiding gdb cc1plus PACK_EXPANSION_PATTERN(result) gives 'No symbol "__extension__"', error msg

[Tom Tromey]

>>>>> "Larry" == Larry Evans <cppljevans@suddenlink.net> writes:

Larry> I compiled gcc with -g3 -O0' compiler flags to enable invocation of
Larry> macros during a gdb session; however, the
Larry> macro,  PACK_EXPANSION_PATTERN, apparently uses a symbol:
Larry>   __extension__
Larry> not understood by gdb.  How can gdb be made to understand
Larry> __extension__ or how can __extension__ be rm'ed from the
Larry> macros?

This is a gdb PR:

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

If you use a new (CVS) gdb, that has "macro define", you can use the
defines in that PR to circumvent the GCC statement expressions and
make everything work reasonably well.  You lose checking but I never
missed that when evaluating things from the gdb CLI.

Once this gdb is released I think those macro defines should go in
gcc's .gdbinit.

Tom