Re: problem with gdb's 'call'

["André Pönitz" <apoenitz@trolltech.com>]

On Tuesday 12 August 2008 16:39:45 Daniel Jacobowitz wrote:
> On Tue, Aug 12, 2008 at 04:36:40PM +0200, André Pönitz wrote:
> >   (gdb) p _Z3fooIiET_v
> >   $1 = {int (void)} 0x400544 <int foo<int>()>
> > 
> >   (gdb) call _Z3fooIiET_v()
> >    /build/buildd/gdb-6.8/gdb/valops.c:2069: internal-error: find_oload_champ_namespace_loop:
> >    Assertion    `new_oload_champ != -1' failed.
> >    A problem internal to GDB has been detected,
> 
> I've seen this error recently, with pointers to members.  I don't
> think my patches will fix this particular case (the OP_VAR_VALUE
> rather than STRUCTOP_MPTR case).
> 
> > I already use the mangled name of the symbol as I did not find a way to
> > quote  'call  foo<int>()' in a way that looks acceptable to gdb.
> 
> It's because of the templated return type.  The quoting that works
> today is (gross, I know):
> 
>   p 'int foo<int>'()
> 
> But it doesn't help, there's the same error.

I noticed in the mean time that

  set demangle-style none 

helps to prevent the crash. Together with your hint this might
already be 'some kind of "solution"' ;-)

> > Is there a way to make the gdb core accept the mangled name without
> > attempting to demangling it (to avoid the crash)?
> 
> The crash has nothing to do with demangling, but you can disable
> overload resolution and that should help.  "set overload-resolution
> off".

Is there somewhere a description in what code paths setting variables
like   overload-resolution  or   demangle-style  has an effect?

> Or just fix the bug :-)

;-} That's certainly the best solution for the long run. In the short term
I have to live with debuggers that are already released....

André