From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23855 invoked by alias); 10 Sep 2014 16:45:39 -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 23722 invoked by uid 89); 10 Sep 2014 16:45:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: e06smtp16.uk.ibm.com Received: from e06smtp16.uk.ibm.com (HELO e06smtp16.uk.ibm.com) (195.75.94.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 10 Sep 2014 16:45:29 +0000 Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 10 Sep 2014 17:45:25 +0100 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp16.uk.ibm.com (192.168.101.146) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 10 Sep 2014 17:45:24 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 5796B219005E for ; Wed, 10 Sep 2014 17:45:04 +0100 (BST) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s8AGjNet45547742 for ; Wed, 10 Sep 2014 16:45:24 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s8AGjMGo024097 for ; Wed, 10 Sep 2014 10:45:23 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id s8AGjLjg024077; Wed, 10 Sep 2014 10:45:21 -0600 Message-Id: <201409101645.s8AGjLjg024077@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 10 Sep 2014 18:45:21 +0200 Subject: Re: eliminate deprecated_insert_raw_breakpoint. what's left. To: macro@codesourcery.com (Maciej W. Rozycki) Date: Wed, 10 Sep 2014 16:45:00 -0000 From: "Ulrich Weigand" Cc: brobecker@adacore.com (Joel Brobecker), palves@redhat.com (Pedro Alves), gdb-patches@sourceware.org (GDB Patches) In-Reply-To: from "Maciej W. Rozycki" at Sep 10, 2014 04:12:49 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14091016-3548-0000-0000-0000015B07C8 X-SW-Source: 2014-09/txt/msg00335.txt.bz2 Maciej W. Rozycki wrote: > On Wed, 10 Sep 2014, Ulrich Weigand wrote: > > Once OSF/1 and IRIX are gone, I hope all of the ECOFF/mdebug debug > > format support can go as well (mipsread.c, mdebugread.c etc.) ... > > Some of that stuff will best stay, to support Procedure Descriptor > Records used on MIPS ELF targets, including but not limited to Linux. > > These records are the only way to get backtracing, and consequently any > reasonable control of the debuggee, to work from places that have debug > information stripped, such as often when you interrupt your debuggee while > waiting in a syscall (libc.so will often have no debug information > included, as usually won't other system-installed shared libraries). > Without that debugging is from my experience severely impeded -- you end > up in the middle of nowhere and virtually all you can do is `continue' or > `stepi', that'll in many cases merely put you back in the sleeping > syscall. > > All MIPS ELF binaries produced by the GNU toolchain carry these PDR > records along unless their exclusion has been explicitly requested from > GAS (which is not the default and in most cases undesirable, these records > are very lightweight and occupy little space). > > I have already identified `mdebugread.h' being the only piece required > though -- in addition to `mips-mdebug-tdep.h' and `mips-mdebug-tdep.c' > that were removed from our tree as a result of an unfortunate coincidence > and have been maintained outside it for years now; they need some > improvements at the time they are brought back too. Maybe `mdebugread.h' > can be stripped down a bit and actually folded into `mips-mdebug-tdep.h' > eventually. This confuses me a bit, which is probably because I don't see what's in mips-mdebug-tdep.c ... Looking at alpha-mdebug-tdep.c, which I had hoped would be mostly equivalent, this gets the PDR records from the magic MDEBUG_EFI_SYMBOL_NAME symbol, which is created by mdebugread.c while parsing the .mdebug section in an ELF file or while parsing an ECOFF file. So if we remove mdebugread.c, nobody will ever set MDEBUG_EFI_SYMBOL_NAME, which means alpha-mdebug-tdep.c is a no-op. Is this handled differently on mips? [ In general, it would be really good if mips-mdebug-tdep.c is brought back into the tree if it is actually being used in practice. Having people maintain stuff out-of-tree long-term makes it hard to see if common code features are no longer used ... ] Also, do you happen to know if on other (non- OSF/1) Alpha platforms the .mdebug debug format is ever used? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com