[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Re: memory view renderings don't update
|
I see this as well.
The reason is that the _expression_ is translated to an
address when first created; although the
_expression_
is still shown to the user, it is backed by that same
address, permanently.
To me this is a bug, but I'm not very familiar with the
memory part of things, so if someone else wants
to confirm that this behavior is not good, that would be
nice. Tim, if confirmed, can you open a bugzilla?
Thanks
Marc
P.S. Another issue I noticed is that when the debug session
is stopped, and then re-launched, the memory
_expression_ is still shown, but does not work. That is
because we don't re-create the proper context for that
memory _expression_.
I need to amend my earlier statement: the memory window doesn't
update only when I am using an _expression_ whose value changes each time I
break in that function. When I use an absolute address or an _expression_ whose
value never changes, it updates fine. So it's as if the memory view doesn't
re-evaluate expressions each time the application is suspended.
On Thu, Aug 19, 2010 at 3:58 PM, Tim Black
<timblaktu@xxxxxxxxx>
wrote:
When
I add a Memory Monitor and a rendering I can correctly see and modify
memory. If I resume my application, and break back in the same thread, same
function, the Memory Rendering never updates. I can create a new rendering,
and the correct memory is shown, but this is extremely cumbersome. This is a
problem regardless of whether I use an absolute address or an _expression_
that evaluates to an address.
I was not able to find anything about
this issue in the archives or on bugzilla. I am using standard Helios/CDT
with GDB 7.1-1 and GDB-DSF debug launchers. This problem plagues me whenever
I do any memory viewing. Please let me know if there is a fix, a workaround,
or if I should file a bug.
Thanks.
