This is the mail archive of the
mailing list for the GDB project.
Re: recursive user-defined commands and
- From: Tom Tromey <tromey at redhat dot com>
- To: selcuk dot kopru at tyazilimevi dot com
- Cc: gdb at sourceware dot org
- Date: Thu, 13 Aug 2009 09:59:14 -0600
- Subject: Re: recursive user-defined commands and
- References: <1250118614.3975.43.camel@selcuk-laptop>
- Reply-to: tromey at redhat dot com
>>>>> ">" == Selcuk Kopru <email@example.com> writes:
>> I'm trying to write user-defined commands to view some
>> nested/embedded classes which form a huge data hierarchy.
My advice is to switch to CVS GDB and use the new Python-based
With this feature you can write Python code to customize the display of
various objects in your program. This is mostly transparent to the user
-- "print" will print them prettily, so will stack traces, so will MI
>> define show_string
>> wchar_print ((CMyString*)$arg0).m_Value
CVS GDB also has direct support for wide characters.
>> If the "show_dag" command is being hit for the second time in the same
>> call sequence then the "$dlist" variable becomes invalid at the time the
>> control returns back to the first instance of the "show_dag" command and
>> resulting in a "Cannot access memory at address 0x.." error message. How
>> can I prevent this error?
I suppose you could allocate an array and then manage the recursion
manually by using $dlist[$depth].
Otherwise, yeah, this seems like a limitation of gdb's scripting
language. It seems like it would nice to let user-defined commands
define local variables.