From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20968 invoked by alias); 23 Nov 2003 23:00:46 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20961 invoked from network); 23 Nov 2003 23:00:45 -0000 Received: from unknown (HELO tisch.mail.mindspring.net) (207.69.200.157) by sources.redhat.com with SMTP; 23 Nov 2003 23:00:45 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AO3DE-0003xl-00; Sun, 23 Nov 2003 18:00:16 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id C6B614B409; Sun, 23 Nov 2003 18:00:16 -0500 (EST) To: drow@mvista.com, gdb-patches@sources.redhat.com Subject: Re: [patch/testsuite/c++] test script for PR c++/186 Message-Id: <20031123230016.C6B614B409@berman.michael-chastain.com> Date: Sun, 23 Nov 2003 23:00:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2003-11/txt/msg00506.txt.bz2 Well, you have a point. The gdb user is attempting to look at an object after its last access from the source code. A C++ compiler has always had the right to fool around with such memory (so does a C compiler; gcc optimizes away local variables often). A test script can only observe behavior. When gdb prints "b1 = 12345678", the test script doesn't know if it's dealing with a conforming compiler that scribbled on the memory, or a gdb bug that causes gdb to print a value that is not in memory. We kinda rely on compilers being simple. As compilers grow more optimizations we get breakages like store.exp and have to fix them. Imagine a bug-catching compiler that scribbles bait-patterns into dead memory -- that would break this script. Hmmm, my test would be more clear if I made B::~B write something into the data fields. I will do that. And write some more comments about this. I will also add some tests like this: A alpha; ... (gdb) print (B *) α I think that's actually the heart and these issues with destructors and scope are peripheral. (But the destructor issue is interesting because the program is doing something important in memory that is not obvious to the programmer). Michael C