From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-35094-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 27292 invoked by alias); 29 Jul 2009 22:39:01 -0000
Received: (qmail 27283 invoked by uid 22791); 29 Jul 2009 22:39:00 -0000
X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Jul 2009 22:38:51 +0000
Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) 	by smtp-outbound-1.vmware.com (Postfix) with ESMTP id AA9A613044; 	Wed, 29 Jul 2009 15:38:47 -0700 (PDT)
Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) 	by mailhost2.vmware.com (Postfix) with ESMTP id 8A9578EA49; 	Wed, 29 Jul 2009 15:38:47 -0700 (PDT)
Message-ID: <4A70CDB4.2040206@vmware.com>
Date: Wed, 29 Jul 2009 22:39:00 -0000
From: Michael Snyder <msnyder@vmware.com>
User-Agent: Thunderbird 1.5.0.12 (X11/20080411)
MIME-Version: 1.0
To: Andreas Schwab <schwab@linux-m68k.org>
CC: "tromey@redhat.com" <tromey@redhat.com>,   Vladimir Prus <vladimir@codesourcery.com>,  "gdb@sources.redhat.com" <gdb@sources.redhat.com>
Subject: Re: Private data members
References: <200907291245.32359.vladimir@codesourcery.com>	<m363dby071.fsf@fleche.redhat.com> <4A70854E.9080106@vmware.com> <m21vnzduh3.fsf@igel.home>
In-Reply-To: <m21vnzduh3.fsf@igel.home>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2009-07/txt/msg00235.txt.bz2

Andreas Schwab wrote:
> Michael Snyder <msnyder@vmware.com> writes:
> 
>> Define struct breakpoint in breakpoint.h, put any public members
>> in there, and then include a member "struct breakpoint_private"
>> that is only a forward declaration.
> 
> That only works if this member is a pointer.  You cannot have struct
> members with incomplete types.

Right.  But that can still be done, because we have a local allocator.
Breakpoint structs are created by set_raw_breakpoint_without_location,
a static function, and the exported interface is set_raw_breakpoint.

As long as nobody outside of breakpoint.c allocates a struct bp,
I don't see why it shouldn't work.