From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16618 invoked by alias); 29 Sep 2016 02:44:10 -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 16535 invoked by uid 89); 29 Sep 2016 02:44:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=management X-HELO: gproxy6-pub.mail.unifiedlayer.com Received: from gproxy6-pub.mail.unifiedlayer.com (HELO gproxy6-pub.mail.unifiedlayer.com) (67.222.39.168) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with SMTP; Thu, 29 Sep 2016 02:43:56 +0000 Received: (qmail 14828 invoked by uid 0); 29 Sep 2016 02:43:54 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy6.mail.unifiedlayer.com with SMTP; 29 Sep 2016 02:43:54 -0000 Received: from box522.bluehost.com ([74.220.219.122]) by cmgw2 with id pEjp1t00b2f2jeq01Ejsq4; Wed, 28 Sep 2016 20:43:53 -0600 X-Authority-Analysis: v=2.1 cv=VdJkYjZ9 c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=GW1xBdLrtEIA:10 a=V82Az2P4AAAA:8 a=U9Y6H24oGfgH3SpBbvoA:9 a=GUYa6fla-me-Zpd7-Uj-:22 Received: from 71-218-192-86.hlrn.qwest.net ([71.218.192.86]:57862 helo=bapiya) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1bpL4w-0005EO-9B; Wed, 28 Sep 2016 14:03:42 -0600 From: Tom Tromey To: Trevor Saunders Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFA 01/22] Change selttest.c to use use std::vector References: <1474949330-4307-1-git-send-email-tom@tromey.com> <1474949330-4307-2-git-send-email-tom@tromey.com> <20160927084049.naw5nx64smlzpqxg@ball> <87twd1z6a7.fsf@tromey.com> <20160928125425.l2c33kotjcixy7q4@ball> Date: Thu, 29 Sep 2016 08:59:00 -0000 In-Reply-To: <20160928125425.l2c33kotjcixy7q4@ball> (Trevor Saunders's message of "Wed, 28 Sep 2016 08:54:25 -0400") Message-ID: <87a8erhjvn.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Exim-ID: 1bpL4w-0005EO-9B X-Source-Sender: 71-218-192-86.hlrn.qwest.net (bapiya) [71.218.192.86]:57862 X-Source-Auth: tom+tromey.com X-Email-Count: 0 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-SW-Source: 2016-09/txt/msg00408.txt.bz2 >>>>> "Trevor" == Trevor Saunders writes: Tom> That would be nice; though we could probably use std::set and std::map Tom> in gdb as well. One wrinkle with hash tables is that they're sometimes Tom> allocated on obstacks; would gcc's handle this? Trevor> No, they don't support that at the moment, though I suppose it Trevor> would be fine for keys or values to point into obstacks. Is Trevor> there a good reason for this other than using obstacks to Trevor> provide a sort of automatic memory management? Sometimes it's just to avoid more work -- cleaning up an obstack is easy. E.g., see dwarf2loc.c:func_verify_no_selftailcall Uses like this can easily be replaced. There are also spots that allocate a hash table on the objfile obstack. Now, this is a bit unfortunate because it means that hash table resizes will create a kind of "leak" -- not a true leak (the memory is tracked and will be freed), but basically some chunk of memory will no longer be useful. It's possible to address these cases in other ways, though more difficult. Tom