Re: GNAT Codesize

[john@assen.demon.co.uk (John McCabe)]

dewar@cs.nyu.edu (Robert Dewar) wrote:

<..snip..>

>First, John, you are making some big deal about stripping, it is a trivial
>process, and it is no harder to strip a file than to copy it, either at
>the user level of at the implementation level.

It does appear that way doesn't it? Let's forget about strip from now
on - besides, someone mentioned the default behaviour of GNAT on DOS
was _not_ to leave debugging information in the executable which takes
me back to me originally mentioning that the GNAT executable was 2 to
3 times the size of the Meridian one for identical functionality.

>And you are ignoring the
>real advantages of efficiency that we have discussed of having a single file.

If you say so - the only efficency advantage I've seen shown is that
it reduces the directory lookup time. This is trivial.

>As to system standards, typically the ABI specifies the format of debugging
>information stored in object files and executables. By following this format,
>you will be compatible with all tools that use this format.

>For example, gprof, the profiling program, is driven by debugging 
>information in standard system format. If your compiler generates debugging
>information in this format, then gprof will work without modification.
>This is indeed true for GNAT, and many of our users are using gprof.
>\x1adp

Surely gprof though will depend on the program being operational in
the host system? How does this fit in with cross-compilation systems.
I need third party profiling tools for the compiler I use to
cross-compile MIL-STD-1750A code on a Sun SPARCstation. Are you saying
that if my compiler generated a MIL-STD-1750A program in the required
Sun Solaris ABI format, that I could use the gprof program to profile
it?

I don't think so.

Best Regards
John McCabe <john@assen.demon.co.uk>