From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14789 invoked by alias); 8 Sep 2009 20:16:12 -0000 Received: (qmail 14739 invoked by uid 22791); 8 Sep 2009 20:16:08 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Sep 2009 20:15:58 +0000 Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id n88KFtIe023128 for ; Tue, 8 Sep 2009 13:15:55 -0700 Received: from an-out-0708.google.com (anac38.prod.google.com [10.100.54.38]) by zps19.corp.google.com with ESMTP id n88KFNmB031223 for ; Tue, 8 Sep 2009 13:15:53 -0700 Received: by an-out-0708.google.com with SMTP id c38so1407559ana.29 for ; Tue, 08 Sep 2009 13:15:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.87.4 with SMTP id p4mr17395556anl.68.1252440953010; Tue, 08 Sep 2009 13:15:53 -0700 (PDT) In-Reply-To: <20090908183649.GS30677@adacore.com> References: <8ac60eac0908201340k6b759eb5o9bb73c8f473d8785@mail.gmail.com> <200908211130.n7LBUCJc011108@d12av02.megacenter.de.ibm.com> <8ac60eac0908231548x135edf2doa04fa59a49455bcd@mail.gmail.com> <8ac60eac0908260020l4200cf84v2686a76b5858d13@mail.gmail.com> <8ac60eac0909021002q74acb916kcd5d4e28ae5fb370@mail.gmail.com> <20090908183649.GS30677@adacore.com> Date: Tue, 08 Sep 2009 20:16:00 -0000 Message-ID: <8ac60eac0909081315o4d0a4d8bydf8b8df78d0a2eaa@mail.gmail.com> Subject: Re: What should we do re: "[patch] Speed up find_pc_section" From: Paul Pluzhnikov To: Joel Brobecker Cc: Ulrich Weigand , Ulrich Weigand , gdb-patches ml , Tom Tromey , Jan Kratochvil Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-IsSubscribed: yes 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 X-SW-Source: 2009-09/txt/msg00224.txt.bz2 On Tue, Sep 8, 2009 at 11:36 AM, Joel Brobecker wrote: > According to Tristan Gingold, this optimization is currently causing > the Darwin debugger to fail completely (I think Paul knows). I certainly do. I also have a fix in the works, and Tristan confirmed that what I have now fixes the problem for him. > Basically, > what happens is that, on Darwin, the debugging info is in the .o files, > and the sections there will necessarily overlap with the sections in > the executable. Rather, all the .o files are relocatable, so they all start at zero and overlap each other. > On MacOS, the way things are currently setup, I think > that we read the .o files as extra object files, rather than sources > of debug info (a-la .gnu_debug_link). Correct. > I don't know how dodgy it was in the first place to load the entire > .o as opposed to just its debugging info, but fixing this will require > a non-trivial effort. I don't believe there is non-trivial effort in fixing this. In fact, I believe (but have not yet confirmed) this may just be fixed by the other patch: http://sourceware.org/ml/gdb-patches/2009-08/msg00437.html Specifically, I believe all the .o files will have lma != vma and will get filtered out as if they are overlay sections: +static int +insert_section_p (const struct bfd *abfd, + const struct bfd_section *section) +{ + const bfd_vma lma = bfd_section_lma (abfd, section); + + if (lma != 0 && lma != bfd_section_vma (abfd, section) + && (bfd_get_file_flags (abfd) & BFD_IN_MEMORY) == 0) + /* This is an overlay section. IN_MEMORY check is needed to avoid + discarding sections from the "system supplied DSO" (aka vdso) + on Linux. */ + return 0; > Tristan has some ideas on how to do this, but > it would be too late for the release - we're probably looking at fixing > this for 7.1. In the meantime, the MacOS port is badly broken. > > I would like us to consider the idea of reverting that patch (and all > followup patches), only to re-apply it after the gdb-7.0 branch is cut. > The reason behind this suggestion is that we're still negotiating some > issues uncovered by this patch (I understand that some of the issues > were latent), and we're just so close to the branch time that I think > it would be less risky to release without it. > > Paul, before we discuss the merits of that suggestion, do you think > that it would be doable to revert? I know that several patches have > already been applied on top in order to fix some of the issues we > later uncovered. It appears to me that reverting this patch is more work than fixing the overlay and MacOS problems exposed by it. But I haven't looked in detail into what it will take to revert. > Other ideas? > > Perhaps one possiblity would be to remove that assertion from the code > and let it return one section at random that matches the PC? Paul seems > to say that, if the assertion is tripped, it means that, before his > patch, we were already potentially returning the wrong section anyway. I believe that's correct. > Does removing the assertion bring us back to that situation? Almost, but not exactly: before the patch, the order of adding objfiles mattered: the earlier objfile with overlapping section was the one that was always found. Now the order of objfiles doesn't matter, as sections are sorted independently. > One last suggestion that Tristan did make this morning, is to downgrade > Darwin support to DSYM files only, as opposed to automatically load > all .o files. That would be too bad, however, as this introduces an > extra step in the build that's inconvenient, and potentially time- > consuming. Note that the separate '*.o' addition has its own bug: the sections from all the .o files are added, but never removed (and this is unrelated to my patch in any way). This is in fact why Tristan said that my earlier patch "works, but makes GDB spend 10 minutes in CPU loop". What really happens there is that with lots of separate .o files to load for a shared library, the first run takes 10s (600+ *.o files loaded), the second 150s (1200+ *.o loaded), the third 600s. This is also the part I haven't finished fixing yet. Now that I am back from vacation, I will confirm that the gdb-find_pc_section-20090825.txt from http://sourceware.org/ml/gdb-patches/2009-08/msg00437.html in fact does also fix MacOS, and will work on eliminating unbounded growth of the separate .o files. If someone could just review the above patch, we'll be good to go :=) Thanks, -- Paul Pluzhnikov