From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126511 invoked by alias); 29 Aug 2015 22:30:07 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 126501 invoked by uid 89); 29 Aug 2015 22:30:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-ob0-f176.google.com Received: from mail-ob0-f176.google.com (HELO mail-ob0-f176.google.com) (209.85.214.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 29 Aug 2015 22:30:05 +0000 Received: by obkg7 with SMTP id g7so66743436obk.3 for ; Sat, 29 Aug 2015 15:30:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Nri46LJLGGDaqO3wQkeiwGYX6jSOdmQDd4GbyvFnnCI=; b=HlUMCBidX6I7dSae99BwgYWuD/Ed6jZRWdsPN8VCQsvQZlU0Hi1tp4HLRhMDkd7FPy 77Swm4u2QScUI0TnMWru7YxWVycZXLkhi2n6JVBlv1RYfbAQBDJSB8fItSYLIxaU3ltM /AqpkfrGBEelbY9nrok6XRvpf0cX/zHZybu6YAz5W/c/4OetVGmoClFTNpE51eEX5ek2 HOFZ7rI3KOgnYQmFNJlmmDj6H7TNR69bvKbaz25uWgYh5m0AAGyTdvw+1/wJKwa0i4Mv Mo5MDreiuZNth6F0GJG/c51nk43W3GdUgG7XaiaG1ZQUihZeapMYW6mbAjVdBvEnbOk5 4Fzg== X-Gm-Message-State: ALoCoQmsg4hn+RxfKCrAJ9+r/dq2jCjrTLhbYrXI/26jsuwWeGIkbWxw0KA+EgZTvONmqXMNQYj1 X-Received: by 10.182.210.194 with SMTP id mw2mr9431211obc.59.1440887403919; Sat, 29 Aug 2015 15:30:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.115.105 with HTTP; Sat, 29 Aug 2015 15:29:44 -0700 (PDT) In-Reply-To: References: <1435631281-31970-1-git-send-email-patrick@parcs.ath.cx> From: Patrick Palka Date: Sat, 29 Aug 2015 22:30:00 -0000 Message-ID: Subject: Re: [PATCH 1/2] Use gdbarch obstack to allocate types in alloc_type_arch To: Doug Evans Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-08/txt/msg00845.txt.bz2 On Sat, Aug 29, 2015 at 5:35 PM, Doug Evans wrote: > On Sat, Aug 29, 2015 at 2:26 PM, Patrick Palka wrote: >>... >> Some background for this change: The TYPE_OBJFILE_OWNED macro tells us >> who owns a given type, and according to the macro's documentation a >> type is always owned either by an objfile or by a gdbarch. Given this >> binary encoding of ownership it doesn't seem to make much sense for >> _any_ type to be allocated by malloc. All types should be allocated >> on an objfile obstack or on a gdbarch obstack. > > I can imagine types being allocated by malloc and tracked via whatever > object "owns" them. All that matters is that when the owner is freed > all its owned objects are freed too. Whether those objects are > malloc'd or in an obstack is just an implementation detail. > > I know that that's not how arch-owned types worked prior to your patch. > I'm just saying they *could* have worked that way. > Moving them to an obstack obviates the need for keeping a copy of > the pointer so it can later be freed. That makes sense. > >> To support allocating a type by malloc, I think the type ownership >> scheme should have three possible cases: that a type is owned by an >> objfile, or that it's owned by a gdbarch, or that it's owned by the >> caller. This new last case could correspond to a type that's >> allocated by malloc instead of on an obstack. >> >> Does this make sense, or maybe I am misunderstanding what "owning" means here? > > I think you've got it right. > > There's still, technically, an open issue of "What happens if an arch > is freed and there's still a value in the history that uses that type? > Would we then have to preserve that type again? (bleah)" Ah, yeah.. > > I don't have too strong an opinion on what's right here. > If someone wants to allow for arches being freed and thus > "preserved" types have to be "owned" by something else, ok, > but I don't see it as an urgent need. We *could* just say that > arches are never freed for now. Makes sense. I reverted this patch, with a revised one incoming.