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/30 Message-ID: #1/1 X-Deja-AN: 162980959 references: <31c8fdd4.5a455349@zesi.ruhr.de> <835637893.1349.0@assen.demon.co.uk> <835984668.12569.0@assen.demon.co.uk> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-06-30T00:00:00+00:00 List-Id: John McCabe said (speaking of symbol information in executables) "Good point, however there would be the advantage that when you wanted to ditch it, you just have to delete the symbol file without touching the executable." Seems irrelevant, it is perfectly easy to strip the executable. There may be some systems in which you cannot strip an executable, but the best thing would be to fix this obvious lack of functionality. ">(b) you don't load the symbol information, so it would not save load time But don't you still have to decide which bits to load and not to load? If you didn't have to make that decision, there presumably would be some [probably unnoticeable] reduction in the load time. Well I suppose you have to store and read one extra word of information in the file, which might take a few extra microseconds. However, from a performance point of view it is much better to keep all the information in one file than two, since you save directory search time, as someone else already pointed out. ">(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. Yes, that appears reasonable. Obviously this tends not to be so important in the cross-compilation systems I mentioned as they must provide their own proprietary debuggers and processor simulators. Actually in my experience this is exactly wrong. It is for cross-development that it is most critical to generate debugging information in standard system format. For example, many of the hardware emulators provide builtin debugging capability based on generation of symbol information in object files and executables in the standard format. Such systems will typically have utilities to strip/remove/process this information in a form that is suitable for the emulator use, but it is critical that it be generated in standard format. In fact thinking about cross-systems is one of the strong arguments in favor of the GNAT approach of using standard debugging info.