Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] MI behaviour - var-evaluate-expression


the command -var-create - * &(x)
uses a * as the frame, which tells GDB to use the current frame and thread
for this variableObject, permanently. What that means is that when 
you do a -var-evaluate-expression of that same varObject, GDB will
evaluate it in the context of the proper thread and frame; no
need to do a -thread-select.

Don't forget to properly use -var-update if the memory might have changed.

As a note, with var-create, instead of using * for the frame, you can use @;
this will tell GDB to change the frame (and the thread?) for that variable
to the current frame at the time of your -var-evaluate-expression.  I haven't
used that form, so I'm not very familiar with it.


-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx on behalf of Mike Wrighton
Sent: Tue 12/2/2008 9:29 AM
To: CDT General developers list.
Subject: [cdt-dev] MI behaviour - var-evaluate-expression

I noticed that -var-evaluate-expression is called for variables that
could exist in other threads than the current one and wondered if this
is a bug or not (I've read the MI section in the gdb manual but
couldn't really find a proper spec for an MI controller)? So as an
example - if a user selects a thread in the thread list, CDT calls
-thread-select n, followed later by -var-create - * &(x) (for array
variables) in that thread, switches back to thread 1, then calls
-var-evaluate-expression for the array variable in the selected
thread. So what's happening is gdb is being asked to evaluate a
variable which exists in another thread. Normally this may be fine but
in a multi-core environment the other thread could use a different
address space in which case reading that variable will fail unless the
thread is switched to before.

Apologies if this makes no sense whatsoever...

cdt-dev mailing list

Back to the top