From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27208 invoked by alias); 29 Apr 2003 16:51:34 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 27192 invoked from network); 29 Apr 2003 16:51:33 -0000 Received: from unknown (HELO mailhub.lss.emc.com) (168.159.2.8) by sources.redhat.com with SMTP; 29 Apr 2003 16:51:33 -0000 Received: from emc.com (lul1179.lss.emc.com [168.159.33.179]) by mailhub.lss.emc.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h3TGpOh14073; Tue, 29 Apr 2003 12:51:25 -0400 (EDT) Message-Id: <200304291651.h3TGpOh14073@mailhub.lss.emc.com> To: Andrew Cagney cc: gdb@sources.redhat.com Subject: Re: macros, debug information, and parse_macro_definition In-Reply-To: Your message of "Tue, 29 Apr 2003 10:55:58 EDT." <3EAE927E.4030005@redhat.com> References: <200304221640.h3MGelj05733@mailhub.lss.emc.com> <200304241512.h3OFCG518027@mailhub.lss.emc.com> <3EAE927E.4030005@redhat.com> Date: Tue, 29 Apr 2003 16:51:00 -0000 From: David Taylor X-SW-Source: 2003-04/txt/msg00330.txt.bz2 > Date: Tue, 29 Apr 2003 10:55:58 -0400 > From: Andrew Cagney > Have you thought about link time information compression? One of the > complaints leveled at the macro stuff is the size of the resultant debug > info. > > Andrew I've thought some about (link time) debug information compression; but, probably not as much as I should have. [We already do some compression of STABS w/o macro information because it's too voluminous as it is. (And DWARF is worse still.) I imagine I will have to solve the problem in-house when macro information is 'turned on', so yes, this is a problem I need to think about.] Since it's not in a separate section, you can't just say "oh, these are identical, only keep one copy". And you certainly (or, I certainly) don't want to tech LD about the internals of STABS (or any debug format, for that matter) -- to, for example, compare chunks that are bracketed by N_BINCL / N_EINCL (begin include, end include), never mind more serious knowledge. The choices that come immediately to mind are: . teach LD about the internals of the debug format -- major blech. . leave the information in the object files and have the executable file just 'reference' the object file information in some manner. [Sun does/did this with their compilers. And this has some appeal. I believe that it would satisfy needs during development; but, I believe that it would not satisfy support needs. So, I don't see us implementing it unless it turns out that its just a step along the way to the real solution.] . have a separate program do some post processing of the debug symbols to compress them. [Hmmm, what would it take to get GNU LD to support piping its output to a program? That way, the huge executable need never be stored on disk. And then, if you invoked it via the specs file, it could be made pretty transparent to the user... Just thinking out loud, mind you.] . somehow generate only one copy in the first place. Possibly by doing something with 'pre-compiled' header files? What exactly, is unclear. I believe that all of the above would require GDB work to support them.