[Bug exp/30107] New: Value history entries not necessarily dissociated from the inferior

[Bug exp/30107] New: Value history entries not necessarily dissociated from the inferior

[macro at orcam dot me.uk]

https://sourceware.org/bugzilla/show_bug.cgi?id=30107

            Bug ID: 30107
           Summary: Value history entries not necessarily dissociated from
                    the inferior
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: exp
          Assignee: unassigned at sourceware dot org
          Reporter: macro at orcam dot me.uk
  Target Milestone: ---

We have this comment in `record_latest_value':

   /* We don't want this value to have anything to do with the inferior
anymore.
      In particular, "set $1 = 50" should not affect the variable from which
      the value was taken, and fast watchpoints should be able to assume that
      a value on the value history never changes.  */

however it is not necessarily always the case that the original variable
remains unchanged.  Given gdb/testsuite/gdb.base/max-value-size.c if we set
a breakpoint at `main', run the program and then execute these commands:

  (gdb) print -elements 3 -- one_hundred
  $1 = {0, 1, 2...}
  (gdb) print -elements 3 -- $1
  $2 = {0, 1, 2...}
  (gdb) set $1[0] = -1
  (gdb) print -elements 3 -- $1
  $3 = {0, 1, 2...}
  (gdb) print -elements 3 -- one_hundred
  $4 = {-1, 1, 2...}
  (gdb)

we can see that while the value history itself does not get changed, but
the original variable does.  This is confusing to say the least.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug exp/30107] Value history entries not necessarily dissociated from the inferior

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30107

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
It would be great to have "principled" approach to this issue --
meaning one that is clear and can easily be explained and understood.
Right now gdb uses a mix of things.  In addition to the case you
found, if you print a structure, and that struct hold a char*,
gdb will read memory to print the string.  However, this memory
isn't stashed in the value, so later on you can 'print $2' and
see a different string.

-- 
You are receiving this mail because:
You are on the CC list for the bug.