From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 6758B3858C5F; Fri, 10 Feb 2023 01:44:18 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6758B3858C5F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1675993458;
	bh=Lt4kp+AqsZIaRkR5i4E4g14+ovavrWQUTGx7EYw7wc4=;
	h=From:To:Subject:Date:From;
	b=VMbIWQ0HNq6vpvrLOyRebnbTgSUrWa5FrP02uRGjxbMzU7AKVya83WLs2HeLaxwnW
	 dUX9nShuPa3OG8d9+A5m/52BoxpOCFFEWQ6CEmmGaL/zqxfBRDLXwkBs6CEN4lWVSv
	 ypA0JljMluo34TwU0R0W0qWgdrk1PxqiSxThtkYA=
From: "macro at orcam dot me.uk" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug exp/30107] New: Value history entries not necessarily
 dissociated from the inferior
Date: Fri, 10 Feb 2023 01:44:17 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: exp
X-Bugzilla-Version: HEAD
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: macro at orcam dot me.uk
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-30107-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gdb-prs.sourceware.org>

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

            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 =3D 50" should not affect the variable from wh=
ich
      the value was taken, and fast watchpoints should be able to assume th=
at
      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 =3D {0, 1, 2...}
  (gdb) print -elements 3 -- $1
  $2 =3D {0, 1, 2...}
  (gdb) set $1[0] =3D -1
  (gdb) print -elements 3 -- $1
  $3 =3D {0, 1, 2...}
  (gdb) print -elements 3 -- one_hundred
  $4 =3D {-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.

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