From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127842 invoked by alias); 29 Aug 2015 22:31:02 -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 127826 invoked by uid 89); 29 Aug 2015 22:31:02 -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-f175.google.com Received: from mail-ob0-f175.google.com (HELO mail-ob0-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 29 Aug 2015 22:31:01 +0000 Received: by obkg7 with SMTP id g7so66750876obk.3 for ; Sat, 29 Aug 2015 15:30:59 -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=mUSbhAWYoC+2DAe7HCc0f/POqpU4LxIA/dHFVWP7uAc=; b=RHj+vetqbadmXfzDNdD5bwqTG4c6Ls9hTT/2PxaLKH8NyFBSIThRcE4c6AZfbqabh7 YxkbC38ZlsJNAfUsIZmgKNQs4iqJ1ocrNpio4nL2XoRTttZQsHhQEWOuIfr2rbIezEJM SsyBYMK5v+j9SeQ2eqRfMpgu1dtNlkHawcdLo4KNDHk2BFf5cwinxQi4GA4uGesME1so iWjJPbCZ4IgrSjldCxcGKECJsT1y2dF2UeBdni4WRRzg30JkPjHlEw6lzBJWf08MygmU Mh6gcwO+64c3OjB+eGWPU765RTQ8Rf508xajxg6uREcejNodINvf0qhnvREJT495Cx3F Lczw== X-Gm-Message-State: ALoCoQn0RdJwjYqu1HXT1Jz7Odc0q9uzByUqECZBAjAZbcQ9aboqycAxbJQBdn0sjxHTkw/micsE X-Received: by 10.182.142.39 with SMTP id rt7mr9307407obb.3.1440887459433; Sat, 29 Aug 2015 15:30:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.115.105 with HTTP; Sat, 29 Aug 2015 15:30:40 -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:31: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/msg00846.txt.bz2 On Sat, Aug 29, 2015 at 6:29 PM, Patrick Palka wrote: > 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. Er, sorry, I reverted and revised the 2nd patch, not this one.