This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: avoiding gdb cc1plus PACK_EXPANSION_PATTERN(result) gives 'No symbol "__extension__"', error msg
- From: Daniel Jacobowitz <drow at false dot org>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Larry Evans <cppljevans at suddenlink dot net>, gcc at gcc dot gnu dot org
- Date: Wed, 8 Jul 2009 22:53:03 -0400
- Subject: Re: avoiding gdb cc1plus PACK_EXPANSION_PATTERN(result) gives 'No symbol "__extension__"', error msg
- References: <h334g5$ij2$1@ger.gmane.org> <4A551A3C.7020606@redhat.com>
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