From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26733 invoked by alias); 14 May 2013 14:38:42 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 26703 invoked by uid 89); 14 May 2013 14:38:41 -0000 X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_PASS,TW_KN autolearn=unavailable version=3.3.1 Received: from hop-nat-141.emc.com (HELO mexforward.lss.emc.com) (168.159.213.141) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 14 May 2013 14:38:41 +0000 Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4EEcYhZ029404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 May 2013 10:38:35 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 14 May 2013 10:38:04 -0400 Received: from usendtaylorx2l.lss.emc.com (usendtaylorx2l.lss.emc.com [10.243.10.188]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4EEc4mn017347; Tue, 14 May 2013 10:38:04 -0400 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id C41D15AFB53; Tue, 14 May 2013 10:38:02 -0400 (EDT) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id 0A79C5AF306; Tue, 14 May 2013 10:38:02 -0400 (EDT) To: Jakub Jelinek cc: "gcc@gcc.gnu.org" , "gdb@sourceware.org" , "binutils@zalov.cz" Subject: Re: stabs changes for 64 bit targets In-reply-to: <20130513145224.GY1377@tucnak.redhat.com> References: <18975.1368456346@usendtaylorx2l> <20130513145224.GY1377@tucnak.redhat.com> Comments: In-reply-to Jakub Jelinek message dated "Mon, 13 May 2013 10:52:24 -0400." Date: Tue, 14 May 2013 14:38:00 -0000 Message-ID: <15482.1368542282@usendtaylorx2l> From: David Taylor X-EMM-MHVC: 1 X-SW-Source: 2013-05/txt/msg00056.txt.bz2 Jakub Jelinek wrote: > On Mon, May 13, 2013 at 10:45:46AM -0400, David Taylor wrote: > > There are problems when using current STABS debug format for 64 bit > > targets. > > Why are you considering extending STABS at this point? > STABS support might very well be dropped altogether from GCC 4.9 or the next > release, people just should use DWARF[234] everywhere. There are multiple reasons. One of the big reasons is... Prior to GCC 4.7, DWARF is too verbose compared to STABS. In STABS, all strings go into the string table; identical strings get put into the table just once. In DWARF, prior to GCC 4.7, macro strings do not go into the string table. If 1000 files all include a given header file, each #define in that header gets its own string in the debug information -- so the string is present 1000 times. GCC 4.7 (DWARF4) fixes this. We have STABS extensions (posted years ago, but never merged) that record macros in the STABS debug information -- at the -g3 level, just like for DWARF. [Posting updated MACRO extensions and trying to get them merged in is on my plate as part of the internal upgrade from gdb 7.1 to gdb 7.6. The extensions predate 7.1.] We are currently using GCC 4.5.4 for most things; 4.6.x for others. I don't knbow the details, but 4.7 was (is?) considered unacceptable, so we're planning on skipping it and waiting for 4.8.1 or later. There are other reasons besides the DWARF verboseness, but they are solvable. The verboseness (over 10x increase in the size of the elf file) is a show stopper. So, for now, we're sticking with STABS. I would like the 16 bytes STABS to be done in a manner that they would be considered for inclusion.