This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI Interface - interpretation of value returned by -stack-list-locals (C++)
- From: Eran Ifrah <eran dot ifrah at gmail dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: BarrRobot <robert at rwall dot plus dot com>, gdb at sourceware dot org
- Date: Wed, 30 Mar 2011 16:04:41 +0200
- Subject: Re: MI Interface - interpretation of value returned by -stack-list-locals (C++)
- References: <31246347.post@talk.nabble.com> <m38vvyotxo.fsf@fleche.redhat.com>
On Tue, Mar 29, 2011 at 4:57 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> ">" == BarrRobot ?<robert@rwall.plus.com> writes:
>
>>> Is there an intention to present the entire output of these commands
>>> in the defined MI output syntax
>
> I haven't heard of any plans in that direction.
>
>>> and if not, what is the recommended way to handle this part of the
>>> output, i.e. is it the expectation to present it 'as is' to the user,
>>> or is it safe to attempt to parse out the component parts and their
>>> values with rules derived from the CLI output?
>
> All I can think of is that you could make a varobj for the arguments you
> are interested in displaying in more detail.
This is how I chose to implement this under codelite IDE, the problem
is that it doubles the calls I need to pass to the GDB process from
the IDE - and when you have a frame with many variable (I am using
-stack-list-locals followed by -stack-list-arguments 2 0 0 to get the
function arguments as well) it starts to show lag.
BTW, I noticed the Mac's GDB creates a varobj per argument on the
stack / function arg (i.e. the output for -stack-list-locals is list
of varobj ID, the attribute name is the varobj unique id)
>
> Tom
>
--
Eran Ifrah
Cross platform, open source C++ IDE: http://www.codelite.org