MI behaviour - var-evaluate-expression

[Mike Wrighton-2]

Hi,

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...

Mike
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[Marc Khouzam]

Hi,

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.

Marc




-----Original Message-----
From: cdt-dev-bounces@... 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
 
Hi,

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...

Mike
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[Mike Wrighton-2]

Great, thanks for the info.

2008/12/2 Marc Khouzam <marc.khouzam@...>:

> Hi,
>
> 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.
>
> Marc
>
>
>
>
> -----Original Message-----
> From: cdt-dev-bounces@... 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
>
> Hi,
>
> 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...
>
> Mike
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[Vladimir Prus-3]

On Tuesday 02 December 2008 17:45:16 Marc Khouzam wrote:

> Hi,
>
> 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.

FWIW, @-varobjs are documented in the GDB manual, CVS version, since yesterday.

- Volodya
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev