From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14969 invoked by alias); 11 Sep 2009 08:33:12 -0000 Received: (qmail 14954 invoked by uid 22791); 11 Sep 2009 08:33:11 -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; Fri, 11 Sep 2009 08:33:07 +0000 Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id n8B8X5KY022624 for ; Fri, 11 Sep 2009 01:33:05 -0700 Received: from an-out-0708.google.com (anab2.prod.google.com [10.100.53.2]) by wpaz21.hot.corp.google.com with ESMTP id n8B8X2QS003693 for ; Fri, 11 Sep 2009 01:33:03 -0700 Received: by an-out-0708.google.com with SMTP id b2so353796ana.31 for ; Fri, 11 Sep 2009 01:33:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.84.11 with SMTP id m11mr2854812anl.70.1252657982665; Fri, 11 Sep 2009 01:33:02 -0700 (PDT) In-Reply-To: References: <8ac60eac0908201340k6b759eb5o9bb73c8f473d8785@mail.gmail.com> <200908211130.n7LBUCJc011108@d12av02.megacenter.de.ibm.com> <8ac60eac0908231548x135edf2doa04fa59a49455bcd@mail.gmail.com> <8ac60eac0908260020l4200cf84v2686a76b5858d13@mail.gmail.com> <20090909055824.GB11738@adacore.com> <8ac60eac0909101036r101263e7qd11c1a69f13008f1@mail.gmail.com> Date: Fri, 11 Sep 2009 08:33:00 -0000 Message-ID: <8ac60eac0909110133q73435471od9b7b45b875a3838@mail.gmail.com> Subject: Re: [patch] Speed up find_pc_section From: Paul Pluzhnikov To: Tristan Gingold Cc: Joel Brobecker , Ulrich Weigand , Ulrich Weigand , gdb-patches ml , Tom Tromey , Jan Kratochvil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00312.txt.bz2 On Fri, Sep 11, 2009 at 12:53 AM, Tristan Gingold wro= te: >> >> [The separate debuginfo file is thus fundamentally different from the >> "bunch of .o files with debug info on MacOS", and extending the separate >> debuginfo to cover MacOS situation (mentioned elsewhere as a possible >> solution) is (IMHO) the wrong approach.] > > Can you elaborate ? > > IMHO this is not fundamentally different. =A0In both cases, one file cont= ains > the code and the other/others debug infos. As I said before, the "primary" and "secondary" objfiles in the separate debuginfo case have a common ancestor, and are almost like identical twins: same sections (except for the weird F11 prelinking case), same symbol tables, same file ELF file type, etc. That isn't at all the case for MacOS "bunch of .o files" -- now we have a "pile of parts" and a "completed engine". Certainly the sections from separate .o files should not appear in the section map; not sure whether symbols should, but likely not. It sounds to me as if you'd want to pick up just the debug bits from *.o, without turning them into full-blown objfiles. I should mention that on Solaris, Sun cc uses the same trick: leaves (stabs) debug info in the .o files and doesn't put any of them into the final linked image (unless '-xs' flag is given on command line). The name of the object file with debug info is recorded in N_OPT stab entries in the image, so DBX knows where to find them. It doesn't look like GDB supports this currently. Cheers, --=20 Paul Pluzhnikov