* problem with gdb's 'call'
@ 2008-08-12 15:30 André Pönitz
2008-08-12 16:12 ` Daniel Jacobowitz
2008-08-12 19:30 ` Andreas Schwab
0 siblings, 2 replies; 5+ messages in thread
From: André Pönitz @ 2008-08-12 15:30 UTC (permalink / raw)
To: gdb
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.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: problem with gdb's 'call'
2008-08-12 15:30 problem with gdb's 'call' André Pönitz
@ 2008-08-12 16:12 ` Daniel Jacobowitz
2008-08-12 21:10 ` André Pönitz
2008-08-12 19:30 ` Andreas Schwab
1 sibling, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2008-08-12 16:12 UTC (permalink / raw)
To: André Pönitz; +Cc: gdb
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: problem with gdb's 'call'
2008-08-12 16:12 ` Daniel Jacobowitz
@ 2008-08-12 21:10 ` André Pönitz
2008-08-12 22:51 ` Daniel Jacobowitz
0 siblings, 1 reply; 5+ messages in thread
From: André Pönitz @ 2008-08-12 21:10 UTC (permalink / raw)
To: gdb
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é
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: problem with gdb's 'call'
2008-08-12 21:10 ` André Pönitz
@ 2008-08-12 22:51 ` Daniel Jacobowitz
0 siblings, 0 replies; 5+ messages in thread
From: Daniel Jacobowitz @ 2008-08-12 22:51 UTC (permalink / raw)
To: André Pönitz; +Cc: gdb
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: problem with gdb's 'call'
2008-08-12 15:30 problem with gdb's 'call' André Pönitz
2008-08-12 16:12 ` Daniel Jacobowitz
@ 2008-08-12 19:30 ` Andreas Schwab
1 sibling, 0 replies; 5+ messages in thread
From: Andreas Schwab @ 2008-08-12 19:30 UTC (permalink / raw)
To: André Pönitz; +Cc: gdb
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."
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-08-12 15:30 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-08-12 15:30 problem with gdb's 'call' André Pönitz
2008-08-12 16:12 ` Daniel Jacobowitz
2008-08-12 21:10 ` André Pönitz
2008-08-12 22:51 ` Daniel Jacobowitz
2008-08-12 19:30 ` Andreas Schwab
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox