From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-72374-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 28511 invoked by alias); 21 Apr 2010 18:48:26 -0000
Received: (qmail 28493 invoked by uid 22791); 21 Apr 2010 18:48:23 -0000
X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 	tests=BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Apr 2010 18:48:19 +0000
Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) 	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o3LImHnm016419 	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) 	for <gdb-patches@sourceware.org>; Wed, 21 Apr 2010 14:48:17 -0400
Received: from qcore.mollernet.net (vpn-10-93.rdu.redhat.com [10.11.10.93]) 	by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o3LImGEn024580; 	Wed, 21 Apr 2010 14:48:16 -0400
Message-ID: <4BCF4870.8070706@redhat.com>
Date: Wed, 21 Apr 2010 18:48:00 -0000
From: Chris Moller <cmoller@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2
MIME-Version: 1.0
To: tromey@redhat.com
CC: gdb-patches@sourceware.org
Subject: Re: PR9167 Derived class static member CRTP infinite recursion on  print
References: <4BC7DDFC.3050506@redhat.com> <m3y6giezcs.fsf@fleche.redhat.com>
In-Reply-To: <m3y6giezcs.fsf@fleche.redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2010-04/txt/msg00693.txt.bz2

On 04/20/10 14:46, Tom Tromey wrote:
>>>>>> "Chris" == Chris Moller<cmoller@redhat.com>  writes:
>>>>>>              
>
> Chris>  You can't do that.  obstack_base() returns a pointer to the current
> Chris>  allocation, which may change depending on what's stuffed into the
> Chris>  obstack--by the time the obstack_free is hit, the base may have
> Chris>  changed.
>
> Why do we need to pop the stack at all?
> It seems to me that if we printed something once, during a given call
> into val_print, then we should never try to print it again.
> Am I missing something?
>    

You need the pop in situations like:

    class A
    {
         // whatever
    };

    class B
    {
         static A a1[] = ...;
         static A a2[] = ...;
    };

    B b;

In this example, printing a1 of 'b' will stick class A on the stack--if 
you don't pop the stack, a2 won't be printed at all.  What the stack 
does is record, at each stack level, what's been printed.  In this case, 
without the use of the stack, printing the members of a1 would print A, 
which would print the members of a1, which would print A,...