From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 304 invoked by alias); 20 Aug 2013 16:19:30 -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 32758 invoked by uid 89); 20 Aug 2013 16:19:29 -0000 X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.2 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 20 Aug 2013 16:19:28 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1VBoeS-0001te-To from Maciej_Rozycki@mentor.com ; Tue, 20 Aug 2013 09:19:24 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Aug 2013 09:19:24 -0700 Received: from [172.30.64.90] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Tue, 20 Aug 2013 17:19:23 +0100 Date: Tue, 20 Aug 2013 16:19:00 -0000 From: "Maciej W. Rozycki" To: Mark Kettenis , "Joseph S. Myers" CC: Tom Tromey , Stan Shebs , Subject: Re: [PATCH] remove ECOFF In-Reply-To: <201308201519.r7KFJwIa000280@glazunov.sibelius.xs4all.nl> Message-ID: References: <1376936369-30712-1-git-send-email-tromey@redhat.com> <87k3jgiege.fsf@fleche.redhat.com> <201308201519.r7KFJwIa000280@glazunov.sibelius.xs4all.nl> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-08/txt/msg00546.txt.bz2 On Tue, 20 Aug 2013, Mark Kettenis wrote: > > Maciej> The MIPS target wants to use minimal ECOFF debug information > > Maciej> that is stored in ELF binaries in the so called PDR or Procedure > > Maciej> Descriptor Record section [1]. > > > > Maciej> Support for PDR unwinding (mips-mdebug-tdep.[ch]) was removed a > > Maciej> while ago from GDB sources > > > > Maciej> I think this is a serious shortcoming of GDB on the MIPS target and a > > Maciej> good argument in favour to having this PDR unwinding support. > > > > It's fine by me if you want to resurrect all the code. I don't even > > mind dropping my patch. > > > > If you have a way to test the ECOFF code, then great. I'd appreciate it > > if you could volunteer to test whatever patches modify these readers. > > I think Maciej concerns for MIPS pretty much mirror my concerns for > Alpha. I should be able to test stuff on Alpha, but not in the next > three weeks. Following Stan's suggestion I had a look through mips-mdebug-tdep.[ch] we have and it seems to me its reliance on mdebugread.[ch] is minimal. It imports the definition of `struct mdebug_extra_func_info' from mdebugread.h, but otherwise handles .pdr sections itself. So it looks to me my concern may have been premature. I think moving the struct definition over to mips-mdebug-tdep.h shouldn't be a problem and the rest of ECOFF support can go then. I'll see yet if all this PDR stuff builds and works with your patch applied. I don't have a real ECOFF target to test with. On Tue, 20 Aug 2013, Joseph S. Myers wrote: > Rather than resurrecting this legacy MIPS-specific support, it would seem > a lot better on Linux to generate .eh_frame by default (as on various > other architectures) and phase out any remaining PDR generation there. > For glibc 2.18 the eh_frame CFI information is present in many assembly > sources and it could be added to the rest. That may be a long-term plan, however as I've noted, support for ECOFF function frame annotation in MIPS GAS has been there since forever and has been extensively documented in MIPS assembly manuals coming from various sources, and therefore is present in virtually all MIPS assembly code out there. OTOH CFI information is mostly lacking from handcoded assembly sources. Therefore while I think adding such CFI information will be valuable I also think there's value in having PDR unwinding handled as well. There are also the bare-iron targets whose users may not necessarily be happy to have extra .eh_frame data in their binaries. My understanding of the reason why mips-mdebug-tdep.[ch] were removed in the first place was the files had never been properly wired into the MIPS targets we keep supporting and their only users were obsoleted at one point, making mips-mdebug-tdep.[ch] orphan. Maciej