From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8802 invoked by alias); 19 Aug 2013 23:22:07 -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 8789 invoked by uid 89); 19 Aug 2013 23:22:07 -0000 X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD autolearn=ham version=3.3.2 Received: from elasmtp-kukur.atl.sa.earthlink.net (HELO elasmtp-kukur.atl.sa.earthlink.net) (209.86.89.65) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 19 Aug 2013 23:22:06 +0000 Received: from [68.96.200.16] (helo=macbook2.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VBYlw-0005IB-Pz for gdb-patches@sourceware.org; Mon, 19 Aug 2013 19:22:04 -0400 Message-ID: <5212A898.3010606@earthlink.net> Date: Mon, 19 Aug 2013 23:22:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [PATCH] remove ECOFF References: <1376936369-30712-1-git-send-email-tromey@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da940ddd68cd5616b47e274dad21e8d5d862b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-SW-Source: 2013-08/txt/msg00529.txt.bz2 On 8/19/13 2:20 PM, Maciej W. Rozycki wrote: > On Mon, 19 Aug 2013, Tom Tromey wrote: > >> The others are in mips_find_abi_section. I don't know what the impact >> would be of removing this code, so I did not touch it. > > The MIPS target wants to use minimal ECOFF debug information that is > stored in ELF binaries in the so called PDR or Procedure Descriptor Record > section [1]. mdebugread.c is a lot of code to maintain for just this one use. Would it be possible to do a selective restore of the section reader when you bring back the rest of PDR handling? Right now mdebugread.c is unknowingly getting more and more broken (no way to test PDR regressions because there is no code using it now, right?), and so your revival plan is going to be complicated by having to figure out which generic patches need to be undone. Another possible bonus is that a future redesigned PDR reader can be more on-demand, only activate if one needs prologue analysis and DWARF info is missing. Stan stan@codesourcery.com