This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]