From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,6ff6ac051491e437
X-Google-Attributes: gid103376,public
From: dewar@cs.nyu.edu (Robert Dewar)
Subject: Re: GNAT Codesize
Date: 1996/06/26
Message-ID: <dewar.835838816@schonberg>#1/1
X-Deja-AN: 162401384
references: <31c8fdd4.5a455349@zesi.ruhr.de> <dewar.835359186@schonberg>
 <835637893.1349.0@assen.demon.co.uk>
organization: Courant Institute of Mathematical Sciences
newsgroups: comp.lang.ada
Date: 1996-06-26T00:00:00+00:00
List-Id: <comp.lang.ada>

John McCabe said

"By debugging information here are you referring to e.g. symbol tables
and that kind of thing? If so, is it not possible to keep this
information in a separate file akin to what embedded cross-development
systems tend to use? Obviously this would involve a lot of work and
I'm not suggesting that GNAT should be changed to behave like this,
I'm just curious as I too noticed that the GNAT executable for a
[small] program I wrote was more than 2x the size of an [functionally]
identical program compiled with Meridian's DOS Ada compiler."


Yes, exactly, symbol table type information. Yes you could keep it in
a separate file, but 

(a) it would not save any disk space to have two files instead of one
(b) you don't load the symbol information, so it would not save load time
(c) it would violate system standards, which are to keep debugging 
	information in the objects and executables. The GNAT approach
	is deliberately system standard compatible to allow use of
	standard debuggers.

Presumbaly Meridian kept debugging information in some non-standard
proprietary format (as did and do many other Ada compilers).