Does -gc-section (garbage collection) works only with static linking ?

Does -gc-section (garbage collection) works only with static linking ?

[Valery Pykhtin]

Hi All, Nick :)

This is the continue to my previous topic about unreachable (uncalled
functions) code elimination by linker.

Firstly I want to say sorry about that mess that I've done in mailing list
(this is the first time I use it).
By the way I still don't know how to continue topics :) .... sorry, sorry,
sorry...

As I understand unreachable code elimination can be only achieved with
static linking. Am I right ?

Best regards,
Valery

Re: Does -gc-section (garbage collection) works only with static linking ?

[Nick Clifton]

Hi Valery,

> As I understand unreachable code elimination can be only achieved with
> static linking. Am I right ?

Essentially yes, but first lets be clear about one thing:  We are 
talking about the elimination of unreachable functions, and for 
languages like C++, unused constructors and destructors.  We are not 
talking about the elimination of unreachable code inside a particular 
function.  That is the job of the compiler.

With static linking all of the references to symbols are resolved at 
link-time and so the linker has the opportunity to detect and eliminate 
unused functions.  (It needs assistance from the compiler in order to do 
this, since the linker has no knowledge of flow control or program 
semantics).  With dynamically linked code, some of the symbol references 
are left unresolved until run-time and so the linker cannot know whether 
a particular function is unreachable.  Hence it cannot eliminate anything.

Cheers
   Nick

Re: Re: Does -gc-section (garbage collection) works only with static linking ?

[Valery Pykhtin]

Hi Nick,

> Essentially yes, but first lets be clear about one thing:  We are
> talking about the elimination of unreachable functions, and for
> languages like C++, unused constructors and destructors.  We are not
> talking about the elimination of unreachable code inside a particular
> function.  That is the job of the compiler.

Thank you for clarifiing this. This is exactly what I talked about :)
However why only destructors and constructors? This is not perfect world (I
mean not all of the programmers are guru) and not all classes has such high
cohesion to have no "unneeded" function members :)

> With static linking all of the references to symbols are resolved at
> link-time and so the linker has the opportunity to detect and eliminate
> unused functions.  (It needs assistance from the compiler in order to do
> this, since the linker has no knowledge of flow control or program
> semantics).  With dynamically linked code, some of the symbol references
> are left unresolved until run-time and so the linker cannot know whether
> a particular function is unreachable.  Hence it cannot eliminate anything.

I didn't understand that fully. How the dynamic library code can depend on
functions inside user (my) program if the program doesn't export any symbols
(entry points) ?  I suppose when I do not export any entry points, my code
can only call library functions and the library code cannot call ANY
function within my program... So what is the problem to resolve the flow
control ?

The only thing I can expect is if the library code use base classes
polimorhically and thus need virtual function from the user's program (if
the user's program extends that base class). But even in this case the
virtual table is constructed inside the contructor that must be called
within the program (as we know there is no virtual constructors) and thus
must have the reference from the flow control graph ?

I must confess that I'm the programmer with windows background and new to
GNU world. May be all symbols in a program considered to be exported? Or
what ? :)

Kind regards,
Valery

Re: Does -gc-section (garbage collection) works only with static linking ?

[Alan Modra]

On Tue, Sep 07, 2004 at 03:10:33PM +0100, Nick Clifton wrote:
> >As I understand unreachable code elimination can be only achieved with
> >static linking. Am I right ?
> 
> Essentially yes

Eric Botcazou added code to mainline CVS on 2004-04-21 to handle
garbage collection of dynamically linked applications.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Does -gc-section (garbage collection) works only with static linking ?

[Nick Clifton]

Hi Valery,

> However why only destructors and constructors? This is not perfect world (I
> mean not all of the programmers are guru) and not all classes has such high
> cohesion to have no "unneeded" function members :)

Well OK, other function-like things can also be eliminated by the 
linker.  I was trying not to get bogged down in the nitty gritty, 
especially since what is and is not eliminated can vary from target to 
target.

>>With static linking all of the references to symbols are resolved at
>>link-time and so the linker has the opportunity to detect and eliminate
>>unused functions.  (It needs assistance from the compiler in order to do
>>this, since the linker has no knowledge of flow control or program
>>semantics).  With dynamically linked code, some of the symbol references
>>are left unresolved until run-time and so the linker cannot know whether
>>a particular function is unreachable.  Hence it cannot eliminate anything.

> I didn't understand that fully. How the dynamic library code can depend on
> functions inside user (my) program if the program doesn't export any symbols
> (entry points) ?  I suppose when I do not export any entry points, my code
> can only call library functions and the library code cannot call ANY
> function within my program... So what is the problem to resolve the flow
> control ?

Your code could call a dynamic library function and pass to that 
function a pointer to another function inside your application.  This 
second function does not have to be exported, since it is your code that 
computes its address, but nevertheless the function can be accessed from 
outside of your code.  Think of the atexit() function supported by the C 
library as an example of this.

Cheers
   Nick

Re: Re: Re: Does -gc-section (garbage collection) works only with static linking ?

[Valery Pykhtin]

Hi Nick,

> Your code could call a dynamic library function and pass to that 
> function a pointer to another function inside your application.  This 
> second function does not have to be exported, since it is your code that 
> computes its address, but nevertheless the function can be accessed from 
> outside of your code.  Think of the atexit() function supported by the C 
> library as an example of this.

Now I understand, thank you :)

Best regards,
Valery

Re: Re: Re: Does -gc-section (garbage collection) works only with static linking ?

[Valery Pykhtin]

Hi again Nick,

> Your code could call a dynamic library function and pass to that
> function a pointer to another function inside your application.  This
> second function does not have to be exported, since it is your code that
> computes its address, but nevertheless the function can be accessed from
> outside of your code.  Think of the atexit() function supported by the C
> library as an example of this.

Sorry if I bother you, but how this situation differs from the static link
case ? Would the linker remove such function with static linking ?

(i386 Intel syntax)

mov eax,myfxptr
...
call [eax]    // in user's program

Does GCC compiler tells the linker in this case that myfx is called ?

Best regards,
Valery

RE: Re: Re: Does -gc-section (garbage collection) works only with static linking ?

[Dave Korn]

> -----Original Message-----
> From: binutils-owner On Behalf Of Valery Pykhtin
> Sent: 08 September 2004 09:55

> Sorry if I bother you, but how this situation differs from 
> the static link
> case ? Would the linker remove such function with static linking ?
> 
> (i386 Intel syntax)
> 
> mov eax,myfxptr
> ...
> call [eax]    // in user's program
> 
> Does GCC compiler tells the linker in this case that myfx is called ?

  The linker will find a reloc pointing at the "mov eax" instruction above,
and so can deduce that myfx is referred to and knows not to discard it.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Re: Re: Re: Does -gc-section (garbage collection) works only with static linking ?

[Valery Pykhtin]

Hi Dave,

Its getting more and more interesting :)

> > (i386 Intel syntax)
> >
> > mov eax,myfxptr
> > ...
> > call [eax]    // in user's program
> >
> > Does GCC compiler tells the linker in this case that myfx is called ?
>
>   The linker will find a reloc pointing at the "mov eax" instruction
above,
> and so can deduce that myfx is referred to and knows not to discard it.

So what is the problem with pointers to functions that are passed to
external dynamic library? The linker could still find these relocates and
consider not to discard these functions?

Best regards,
Valery

RE: Re: Re: Re: Does -gc-section (garbage collection) works only with static linking ?

[Dave Korn]

> -----Original Message-----
> From: Valery Pykhtin  
> Sent: 08 September 2004 12:25

> Hi Dave,
> 
> Its getting more and more interesting :)
> 
> > > (i386 Intel syntax)
> > >
> > > mov eax,myfxptr
> > > ...
> > > call [eax]    // in user's program
> > >
> > > Does GCC compiler tells the linker in this case that myfx 
> is called ?
> >
> >   The linker will find a reloc pointing at the "mov eax" instruction
> above,
> > and so can deduce that myfx is referred to and knows not to 
> discard it.
> 
> So what is the problem with pointers to functions that are passed to
> external dynamic library? The linker could still find these 
> relocates and
> consider not to discard these functions?
> 
> Best regards,
> Valery

  I didn't really follow Nick's argument, and since Alan points out that it
has been implemented, I guess it must be possible after all.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Re: Re: Re: Does -gc-section (garbage collection) works only with static linking ?

[Valery Pykhtin]

>   I didn't really follow Nick's argument, and since Alan points out that
it
> has been implemented, I guess it must be possible after all.

I'm just two curious, sorry for disturbing,

Thanks to All of you,
Valery

Re: Does -gc-section (garbage collection) works only with static linking ?

[Nick Clifton]

Hi Valery,

> Sorry if I bother you, but how this situation differs from the static link
> case ? Would the linker remove such function with static linking ?


> mov eax,myfxptr
> ...
> call [eax]    // in user's program
> 
> Does GCC compiler tells the linker in this case that myfx is called ?

Effectively yes.  GCC creates the "mov eax,myfxptr" instruction.  GAS 
assembles it, generating a reference to the "myfxptr" symbol in the 
process.  [GAS has to generate a reference to "myfxptr" because it does 
not know its location - it is being defined in another source file].

When LD performs a static link it sees the reference to myfxptr and so 
it knows that the section containing that symbol has to be included in 
the output.

Now of course you could argue that this logic applies to dynamically 
linked code as well.  If the  linker sees that there are no references 
to the symbol "myfxptr" and that this is the only symbol in a particular 
input section then that input section cannot be used by any code.  So it 
could throw the section away.  This is actually true in theory, but in 
practice there is a problem.  All sections have a name.  This name is 
globally visible, and therefore it can be seen by things outside of the 
dynamically linked code.  So in theory something could want to use the 
contents of that section, accessing it via its section-name, even though 
there are no other references to any symbols inside that section.  So 
the linker has to keep the section present in the dynamic 
executable/library.

Cheers
   Nick

Re: Does -gc-section (garbage collection) works only with static linking ?

[Valery Pykhtin]

Hi agian Nick,

> Now of course you could argue that this logic applies to dynamically
> linked code as well.  If the  linker sees that there are no references
> to the symbol "myfxptr" and that this is the only symbol in a particular
> input section then that input section cannot be used by any code.  So it
> could throw the section away.  This is actually true in theory, but in
> practice there is a problem.  All sections have a name.  This name is
> globally visible, and therefore it can be seen by things outside of the
> dynamically linked code.  So in theory something could want to use the
> contents of that section, accessing it via its section-name, even though
> there are no other references to any symbols inside that section.  So
> the linker has to keep the section present in the dynamic
> executable/library.

So if I understand you right, my program compiled by GCC (or whatever in GNU
environment) contains a lot of entry points (one for each section) and any
person can build dynamic library that expects such entry points from my
program...
Nothing to say here... I just want to cry...

Finally when our discussion gets to its logic end I want to say the
following:

Without this kind of this optimization (thanks to you for it became
available now) you give one additional argument to those people who argue to
use C instead of C++. Let the C++ be ! :)

This can be treated horrible for some people, but I'm using C++ for embedded
programming in RTEMS environment. I've used static linking with
garbage-collection and saved yesterday about 15% of the size of my program.
Currently I'm going to rebuild RTEMS and STL with -ffunction-sections
expecting better results.

Sorry again for disturbing you Nick, but I suppose there are a lot of C++
programs now in Linux environment that could and must have smaller size.

Best regards,
Valery

Re: Re: Re: Re: Does -gc-section (garbage collection) works only with static linking ?

[Valery Pykhtin]

>   No apology is needed!

Hello Dave,Nick

I, Valery Pykhtin, apologize for that I've already got the message about
Alan about this optimization is on (since april 2004)still asked questions
to Nick.

I'm sorry that I've disturbed you and get you off your work, because instead
of answering to my stupid questions (containing a lot of grammatic mistakes)
you can spend this brilliant time for example to enhance the same
garbage-collection algorithm.

SORRY, SORRY, SORRY !!!

Best, kindest regards to you,
Valery