From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22823 invoked by alias); 11 Sep 2014 11:50:47 -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 22812 invoked by uid 89); 11 Sep 2014 11:50:46 -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: e06smtp13.uk.ibm.com Received: from e06smtp13.uk.ibm.com (HELO e06smtp13.uk.ibm.com) (195.75.94.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 11 Sep 2014 11:50:43 +0000 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 11 Sep 2014 12:50:40 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 11 Sep 2014 12:50:38 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 68BE817D8045 for ; Thu, 11 Sep 2014 12:52:39 +0100 (BST) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s8BBobHm6750426 for ; Thu, 11 Sep 2014 11:50:37 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 s8BBoZmq001540 for ; Thu, 11 Sep 2014 05:50:37 -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 s8BBoXiL001461; Thu, 11 Sep 2014 05:50:34 -0600 Message-Id: <201409111150.s8BBoXiL001461@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 11 Sep 2014 13:50:33 +0200 Subject: Re: eliminate deprecated_insert_raw_breakpoint. what's left. To: macro@codesourcery.com (Maciej W. Rozycki) Date: Thu, 11 Sep 2014 11:50: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 08:11:05 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: 14091111-2966-0000-0000-0000011895D5 X-SW-Source: 2014-09/txt/msg00354.txt.bz2 Maciej W. Rozycki wrote: > Now that you mention it there is this statement: > > sym = lookup_symbol (MDEBUG_EFI_SYMBOL_NAME, b, LABEL_DOMAIN, 0, NULL); > > in `mips-mdebug-tdep.c' (in `non_heuristic_proc_desc') indeed, however > it's just a fallback in the case where no PDR record has been found. > This part can be removed if IRIX support was dropped, we don't expect to > have a `.mdebug' section on non-IRIX MIPS ELF targets, so that would > become dead code. The structure of PDR itself is documented in [1] and is > only a subset of what a `.mdebug' section would include. OK, I see. Looking at gas sources, I can now see that it will create a .pdr section instead of .mdebug (unless ECOFF debugging is enabled). > > Also, do you happen to know if on other (non- OSF/1) Alpha platforms the > > .mdebug debug format is ever used? > > On Alpha/Linux you'll get it with `-gstabs', although that'll be along > some DWARF information for some reason, at least in the somewhat dated > version of Alpha GCC I have, e.g.: Thanks for the info! Looking through GCC and GAS sources, this is triggered by GCC passing the -mdebug flag to GAS when it gets -gstabs. In fact, there is also a code path on Mips to pass -mdebug to GAS; but this needs the -gcoff GCC option ... So in any case, it seems that once IRIX and OSF are gone, we no longer need to support the ECOFF file format, but there are still ways to generate the ECOFF *debug* format (even though non-default) on two Linux platforms. Well, I guess there's currently no need to remove GDB support for that ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com