From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69756 invoked by alias); 10 May 2018 22:25:20 -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 42065 invoked by uid 89); 10 May 2018 22:24:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=1-7, shareable, noticeably, slowdown X-HELO: gateway32.websitewelcome.com Received: from gateway32.websitewelcome.com (HELO gateway32.websitewelcome.com) (192.185.145.102) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 May 2018 22:24:06 +0000 Received: from cm13.websitewelcome.com (cm13.websitewelcome.com [100.42.49.6]) by gateway32.websitewelcome.com (Postfix) with ESMTP id A155B57DC204 for ; Thu, 10 May 2018 17:24:04 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id GtymfLxMlQUwqGtymf47xM; Thu, 10 May 2018 17:24:04 -0500 X-Authority-Reason: nr=8 Received: from 97-122-176-117.hlrn.qwest.net ([97.122.176.117]:54520 helo=bapiya.Home) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1fGtym-001ijL-Ep for gdb-patches@sourceware.org; Thu, 10 May 2018 17:24:04 -0500 From: Tom Tromey To: gdb-patches@sourceware.org Subject: [RFA 00/15] Work toward making psymtabs reusable Date: Thu, 10 May 2018 22:25:00 -0000 Message-Id: <20180510222357.27332-1-tom@tromey.com> X-BWhitelist: no X-Source-L: No X-Exim-ID: 1fGtym-001ijL-Ep X-Source-Sender: 97-122-176-117.hlrn.qwest.net (bapiya.Home) [97.122.176.117]:54520 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-SW-Source: 2018-05/txt/msg00278.txt.bz2 Recently I realized that, while the full objfile splitting project is still a good idea, many of the potential gains from it could be had more immediately -- by making psymtabs shareable across objfiles. The idea behind this is that scanning psymbols is what is noticeably slow; expanding a given CU is ordinarily pretty fast. So, if psymbols could be shared, then the most user-visible slowdown could be avoided, at least in the multi-inferior case. As an aside, this case matters to me, because Firefox is now multi-process by default and each process uses the enormous libxul.so. Multi-inferior debugging still has a ways to go in gdb, but if you are working in this area, rest assured that there are people who want to use the results... This series does not actually achieve the goal of sharing psymbols. It is just a bunch of necessary-but-not-sufficient infrastructure. I figured I would send it as it is relatively self-contained and already pretty long. Also note that it is built on top of my earlier series to make psymbols independent of the program space. This series begins (patches 1-7) with some minor cleanups that I found while working in this area. Perhaps patches 6 and 7 aren't really needed; I wrote them when working toward a slightly different end goal, but I think they are reasonable so I left them in. Patch 8 is perhaps the ugliest of the bunch. Because backlinks from pymtabs to per-objfile objects will be disallowed, the psymtab->compunit_symtab link had to be broken. This patch does so via a map. The rest, I think, is reasonably straightforward. Various psymtab-related objects are moved to a new psymtab state-holding object, and finally, this object is given its own obstack, moving the psymbols into a shareable object. This is the series I referenced in reply to Simon's auto-indexing series -- I think with this it is pretty easy to picturing handing the psymtab_storage shared_ptr to a separate thread to write out the index file. Regression tested by the buildbot. There are still some remaining cleanups that could be done. psymtab.c uses ALL_OBJFILE_PSYMTABS_REQUIRED everywhere, but in some spots it doesn't make sense. Also, ~objfile (indirectly) calls psym_forget_cached_source_info, but really psymtab_storage should be handling this in its own destructor. Tom