This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI Interface - interpretation of value returned by -stack-list-locals (C++)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]