From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27580 invoked by alias); 8 Sep 2009 18:37:11 -0000 Received: (qmail 27527 invoked by uid 22791); 8 Sep 2009 18:37:10 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Sep 2009 18:36:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 26D9A2BABEC; Tue, 8 Sep 2009 14:36:57 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id B3di-4SzIny3; Tue, 8 Sep 2009 14:36:57 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id B24EC2BABA6; Tue, 8 Sep 2009 14:36:56 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id CEF98F589B; Tue, 8 Sep 2009 11:36:49 -0700 (PDT) Date: Tue, 08 Sep 2009 18:37:00 -0000 From: Joel Brobecker To: Paul Pluzhnikov Cc: Ulrich Weigand , Ulrich Weigand , gdb-patches ml , Tom Tromey , Jan Kratochvil Subject: What should we do re: "[patch] Speed up find_pc_section" Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ac60eac0909021002q74acb916kcd5d4e28ae5fb370@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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/msg00212.txt.bz2 Hello everyone, According to Tristan Gingold, this optimization is currently causing the Darwin debugger to fail completely (I think Paul knows). 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. 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). 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. 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. 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. Does removing the assertion bring us back to that situation? 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. -- Joel