comp.lang.ada
 help / color / mirror / Atom feed
From: Adam Beneschan <adam@irvine.com>
Subject: Re: Typical handling of packages through compilers
Date: Wed, 22 Jul 2009 07:29:58 -0700 (PDT)
Date: 2009-07-22T07:29:58-07:00	[thread overview]
Message-ID: <4c52e11d-891d-4019-a849-8824f4f5c5c5@b25g2000prb.googlegroups.com> (raw)
In-Reply-To: a2f32a27-1137-4f10-a2af-877c4e0d4707@a7g2000yqk.googlegroups.com

On Jul 22, 5:21 am, Hibou57 (Yannick Duchêne)
<yannick_duch...@yahoo.fr> wrote:
> Hi all,
>
> I've noticed that the inclusion of a package, turns into the inclusion
> of all of its content, despite just a few part of it is really used
> (taking into account, internal dependencies). Using seperate data and
> function sections and then the linker gc-section option, does not
> change anything (the executable is even a bit bigger using these
> options).
>
> There is indeed no implementation requirement about it.
>
> But I would like to know more on the handling of package through
> various Ada compilers (including Janus if possible, if there are some
> Janus users in the place).
>
> By the way, on most compilers, is an inner package handled the same
> way a child package is ? I mean... child packages are included only
> when withed, but what about inner packages ? Are they tipically
> included in whole as there are part of another package body or are
> they tipically included only when explicitely referenced (althought
> inner packages does not need to be withed) ?

I think that typically, when a single source file is compiled, the
result is a single object file; and for many linkers, either that
object file gets included in the final executable or it doesn't, in an
all-or-nothing fashion.

One of our compilers (for a particular target processor) comes with a
linker that is able to eliminate unused sections.  The code for each
procedure, function, or other routine generated by the compiler is in
a separate section, and the linker doesn't include sections that
aren't referenced.  So if you have a procedure Proc1 in a package, but
it's never called (or referenced via 'Access, etc.) anywhere in the
program, then Proc1 won't be included in the executable.  Furthermore,
if Proc1 is the only procedure in the program that calls Proc2, then
if Proc1 isn't included then Proc2 won't be included either.  I think
the same applies to global variables---if there are no references to a
variable then by default it never gets allocated.  I'm not sure if
this is similar to what Gautier was referring to.  I know there are
other linkers out there that do a similar optimization (e.g. Analog
Devices' linker for 21000 series).

By the way, "inner packages" don't have any effect at all on this, and
I'd guess that that is true for other compilers as well.  Inner
packages are not at all reflected in the structure of the object
file.  Our linker considers each code or data item individually to see
if it can be eliminated; it doesn't care at all about whether they've
been grouped into another package.

                                           -- Adam




  parent reply	other threads:[~2009-07-22 14:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-22 12:21 Typical handling of packages through compilers Hibou57 (Yannick Duchêne)
2009-07-22 12:57 ` Gautier write-only
2009-07-22 13:12   ` Hibou57 (Yannick Duchêne)
2009-07-22 20:06   ` tmoran
2009-07-22 21:27     ` Hibou57 (Yannick Duchêne)
2009-08-14 22:06     ` Randy Brukardt
2009-07-22 14:29 ` Adam Beneschan [this message]
2009-07-22 21:25   ` Hibou57 (Yannick Duchêne)
2009-07-22 21:55     ` Adam Beneschan
2009-07-22 23:15 ` Jeffrey Creem
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox