From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1231 invoked by alias); 19 Aug 2013 21:21:04 -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 1222 invoked by uid 89); 19 Aug 2013 21:21:03 -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; Mon, 19 Aug 2013 21:21:03 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VBWsm-0002yb-Q4 from Maciej_Rozycki@mentor.com ; Mon, 19 Aug 2013 14:21:00 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Aug 2013 14:21:00 -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; Mon, 19 Aug 2013 22:20:58 +0100 Date: Mon, 19 Aug 2013 21:21:00 -0000 From: "Maciej W. Rozycki" To: Tom Tromey CC: Subject: Re: [PATCH] remove ECOFF In-Reply-To: <1376936369-30712-1-git-send-email-tromey@redhat.com> Message-ID: References: <1376936369-30712-1-git-send-email-tromey@redhat.com> 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/msg00528.txt.bz2 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]. That information comprises function address ranges and stack frame information -- all produced by .ent, .end, .frame, .mask and .fmask MIPS GAS pseudo-ops (produced by GCC in generated code and also present in virtually all handcoded MIPS assembly sources). It is required for correct frame unwinding in functions that lack debugging information (PDR records are not normally removed by `strip'), that cannot be handled by our heuristic unwinders that get challenged more and more by the GCC optimiser getting more and more sophisticated (and able to produce essentially random code in function prologues these days). Support for PDR unwinding (mips-mdebug-tdep.[ch]) was removed a while ago from GDB sources, perhaps due to the shortcoming of the code in the handling of leaf frames -- while more outer frames were always accurately handled, the leaf ones were not. The reason was the PDR format does not record offsets into functions where individual registers are saved and the old code had no logic to figure out where this happens. Unlike the heuristic unwinders that have to make a full static analysis of code to figure out the structure of a function's frame, the heuristic for the PDR unwinder can be simple -- it's enough to recognise register stores as the frame layout is already described by the PDR. We have kept maintaining bare-iron MIPS PDR support in CodeBench and my intent is to enable it for Linux MIPS targets, add the heuristic outlined above and resurrect the old code GDB used to have with the improvements included. Without that debugging is often a challenge -- while the heuristic unwinders are good enough to handle stepping in to a function that has no debug information so that it's skipped over with the usual `step' or `next' CLI operations (and their MI equivalents), interrupting a program randomly within a function that has no debug information -- a common scenario e.g. where a Linux process is sleeping in a syscall invoked from stripped libc -- provides the user with no backtrace and therefore no access to any local state or the ability to control execution other than by instruction-level stepping (`stepi' or `nexti'). I think this is a serious shortcoming of GDB on the MIPS target and a good argument in favour to having this PDR unwinding support. References: [1] ftp://ftp.sgi.com/sgi/dev/davea/Mdebug.ps Maciej