problem with gdb's 'call'

problem with gdb's 'call'

[André Pönitz]

Hi all.

I have a problem calling certain functions in the inferior using gdb's 
"call" command.

With gdb 6.8 and the following code compiled with  g++ -g main.cpp

  template <class T> T foo() { return T(0); }
  int main() { return foo<int>(); }

I get after  'b main' and 'r':

  (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,

The same happens if I do a 'set print demangle off'. I thought in this case
there should be not much C++ involved, but somehow demangling seems
to be attempted anyway.

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.

Now I have two questions: 

How can I quote the function name such that it will be acceptable by the
gdb parser [actually the function that I'd like to call in reality looks more like
ns::foo<ns::type>((ns::type*)0x1234). I am not sure this is even 'quotable']

Is there a way to make the gdb core accept the mangled name without
attempting to demangling it (to avoid the crash)?

As usual, I am at the my wit's end and would appreciate any help ;-}

Regards,
André


PS: Stack trace would be something like

#0  0x00002b695b4ff095 in raise () from /lib/libc.so.6
#1  0x00002b695b500af0 in abort () from /lib/libc.so.6
#2  0x0000000000451635 in ?? ()
#3  0x000000000044e949 in internal_verror ()
#4  0x000000000044e9e1 in internal_error ()
#5  0x00000000004bc3b6 in ?? ()
#6  0x00000000004bc2fb in ?? ()
#7  0x00000000004bc2fb in ?? ()
#8  0x00000000004bd27f in find_overload_match ()
#9  0x00000000004b9bfe in evaluate_subexp_standard ()
#10 0x00000000004b636d in evaluate_expression ()
#11 0x00000000004c8086 in ?? ()
#12 0x000000000044d7e2 in execute_command ()
#13 0x00000000004ee04b in ?? ()
#14 0x00000000004eecdb in ?? ()
#15 0x00002b695a9cfea7 in rl_callback_read_char () from /lib/libreadline.so.5
#16 0x00000000004ee229 in ?? ()
#17 0x00000000004eccd3 in ?? ()
#18 0x00000000004ed5e8 in gdb_do_one_event ()
#19 0x00000000004ea4ab in catch_errors ()
#20 0x0000000000493876 in ?? ()
#21 0x0000000000445dc9 in ?? ()
#22 0x00000000004ea4ab in catch_errors ()
#23 0x0000000000446566 in ?? ()

at that point of time, I guess I can re-compile gdb with debug symbols
if that would help.

Re: problem with gdb's 'call'

[Daniel Jacobowitz]

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.

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

Or just fix the bug :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: problem with gdb's 'call'

[Andreas Schwab]

André Pönitz <apoenitz@trolltech.com> writes:

> How can I quote the function name such that it will be acceptable by the
> gdb parser [actually the function that I'd like to call in reality looks more like
> ns::foo<ns::type>((ns::type*)0x1234). I am not sure this is even 'quotable']

For template functions you the demanged name includes the return type.

(gdb) call 'int f<TAB>

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: problem with gdb's 'call'

[André Pönitz]

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é

Re: problem with gdb's 'call'

[Daniel Jacobowitz]

On Tue, Aug 12, 2008 at 05:27:39PM +0200, André Pönitz wrote:
> > > 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?

Just the description of the commands in the manual.

-- 
Daniel Jacobowitz
CodeSourcery