This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
problem with gdb's 'call'
- From: André Pönitz <apoenitz at trolltech dot com>
- To: gdb at sourceware dot org
- Date: Tue, 12 Aug 2008 16:36:40 +0200
- Subject: problem with gdb's 'call'
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.