static variables discarded by the VS.NET2003 linker

Hi Everyone,

I found a thread on that topic posted year 2004 but not satisfied with
the information there. So I decided to raise that issue once again.

In general the problem with VS.NET 2003 linker is that it will discard
an object file containing definitions of global variables of any type/
class if nothing else in this file is referenced by other files in the
project.

Now I have the following case. In given source file I have definitions
of several global variables that in contructor register itself in
another global container object. Later in code any of these variables
would be accessed via that global container. But what actually happens
is that the linker decides to discard the object files and instances
of these global variables are never created and registered in the
container.

I am not sure what should be the correct behaviour of the linker in
that case but could anyone let me know how to overcome that problem
and make the linker to include the needed object files without forcing
it to include any object files from given library even if not
referenced at all?

Can we say that in my case objects are not referenced at all since
even if they are not referenced directly still it is possible to be
reference via the container object?

Many thanks in advance!
Best regards,
Boris.

Ulrich
Thu Feb 22 04:37:57 CST 2007

bdachev@gmail.com wrote:
> In general the problem with VS.NET 2003 linker is that it will discard
> an object file containing definitions of global variables of any type/
> class if nothing else in this file is referenced by other files in the
> project.
>
> Now I have the following case. In given source file I have definitions
> of several global variables that in contructor register itself in
> another global container object. Later in code any of these variables
> would be accessed via that global container. But what actually happens
> is that the linker decides to discard the object files and instances
> of these global variables are never created and registered in the
> container.

Same problem here. I simply added artificial references to the code,
prefixed with a comment why it is there. I personally consider the
behaviour broken in an unfortunate way, but I guess not sorting out reverse
references would eventually lead to that much bloat that sorting out things
wouldn't make sense at all. Also, sometimes you have two implementations X
in the final link and explicitly want that only the first is taken, i.e. to
override the second. If X now had any back references, you would be stuck
because both have back references and the linker would thus try to include
both.

I'm not sure if that was with MS' compiler/linker or GCC, but I seem to
remember that you could add a property to an object telling the linker not
to discard it. Try looking into the docs for __declspec() and tell me if
you find anything. ;)

Uli

Waleri
Thu Feb 22 05:03:50 CST 2007

You have two solutions, both in linker options

a) Linker/Optimization/References, turn off "eliliminate unreferenced data"
or
b) Linker/Input/Force Symbol Reference, add your global vars there

<bdachev@gmail.com> wrote in message
news:1172139754.837798.197130@a75g2000cwd.googlegroups.com...
> Hi Everyone,
>
> I found a thread on that topic posted year 2004 but not satisfied with
> the information there. So I decided to raise that issue once again.
>
> In general the problem with VS.NET 2003 linker is that it will discard
> an object file containing definitions of global variables of any type/
> class if nothing else in this file is referenced by other files in the
> project.
>
> Now I have the following case. In given source file I have definitions
> of several global variables that in contructor register itself in
> another global container object. Later in code any of these variables
> would be accessed via that global container. But what actually happens
> is that the linker decides to discard the object files and instances
> of these global variables are never created and registered in the
> container.
>
> I am not sure what should be the correct behaviour of the linker in
> that case but could anyone let me know how to overcome that problem
> and make the linker to include the needed object files without forcing
> it to include any object files from given library even if not
> referenced at all?
>
> Can we say that in my case objects are not referenced at all since
> even if they are not referenced directly still it is possible to be
> reference via the container object?
>
> Many thanks in advance!
> Best regards,
> Boris.
>

Bruno
Thu Feb 22 07:49:34 CST 2007

> I am not sure what should be the correct behaviour of the linker in
> that case but could anyone let me know how to overcome that problem
> and make the linker to include the needed object files without forcing
> it to include any object files from given library even if not
> referenced at all?

You can force symbol references in the input section of the linker project
settings.
However, I found that adding dummy references and adding some comment as to
why I did so the easiest solution.


--

Kind regards,
Bruno van Dooren
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"

bdachev
Thu Feb 22 12:40:24 CST 2007

Thanks, Uli!

> Same problem here. I simply added artificial references to the code,
> prefixed with a comment why it is there.

We ended with the same workaround here! :)

> I personally consider the
> behaviour broken in an unfortunate way, but I guess not sorting out reverse
> references would eventually lead to that much bloat that sorting out things
> wouldn't make sense at all. Also, sometimes you have two implementations X
> in the final link and explicitly want that only the first is taken, i.e. to
> override the second. If X now had any back references, you would be stuck
> because both have back references and the linker would thus try to include
> both.

I just spend some time reading the C++ Standard and found a place
(3.7.1 -2) where it is clearly stated that static objects which have
an initialisation or a destructor with side effects shall not be
eliminated even if they appear to be unused.
So to me it is just a bug in M$ linker implementation.

>
> I'm not sure if that was with MS' compiler/linker or GCC, but I seem to
> remember that you could add a property to an object telling the linker not
> to discard it. Try looking into the docs for __declspec() and tell me if
> you find anything. ;)

I also checked __declspec() M$ extensions but did not find one for
that particular case. Maybe dllexport will do the job but it does not
make great sense to me in a context of a static library which is the
case that we have here.

B.

bdachev
Thu Feb 22 12:48:46 CST 2007

Hi, Waleri!

> You have two solutions, both in linker options
>
> a) Linker/Optimization/References, turn off "eliliminate unreferenced data"
> or
> b) Linker/Input/Force Symbol Reference, add your global vars there

Yes I am also aware of these solutions but neither is acceptable for
us:
a) will also include all other unreferenced entities which will
unnecessary increase the size of the executable.
b) we have too many instances of these globals that it looks
ridiculous to explicitly state them in linker options.

Regards,
B.

Waleri
Thu Feb 22 14:23:30 CST 2007

Well, you can't expect linker to guess itself which globals are unreferenced
but needed, can't you?

Just create one "superclass" that will contain your globals as members, then
create static instance of that class and pass it to the linker...

<bdachev@gmail.com> wrote in message
news:1172170126.104361.285140@l53g2000cwa.googlegroups.com...
> Hi, Waleri!
>
> > You have two solutions, both in linker options
> >
> > a) Linker/Optimization/References, turn off "eliliminate unreferenced
data"
> > or
> > b) Linker/Input/Force Symbol Reference, add your global vars there
>
> Yes I am also aware of these solutions but neither is acceptable for
> us:
> a) will also include all other unreferenced entities which will
> unnecessary increase the size of the executable.
> b) we have too many instances of these globals that it looks
> ridiculous to explicitly state them in linker options.
>
> Regards,
> B.
>

Alexander
Thu Feb 22 22:52:35 CST 2007

Are the files in question pulled from a .LIB, or linked in explicitly?

Are those static (file scope) or global scope? If they are file-scoped, then
the linker doesn't have to even consider then, if the file doesn't have any
globally-scoped function. Because constructors of those objects don't have
to be called until any function in the file gets executed.


<bdachev@gmail.com> wrote in message
news:1172169618.333542.290400@a75g2000cwd.googlegroups.com...
> Thanks, Uli!
>
>
> I just spend some time reading the C++ Standard and found a place
> (3.7.1 -2) where it is clearly stated that static objects which have
> an initialisation or a destructor with side effects shall not be
> eliminated even if they appear to be unused.
> So to me it is just a bug in M$ linker implementation.
>

Tom
Fri Feb 23 04:31:47 CST 2007

bdachev@gmail.com wrote:

> I just spend some time reading the C++ Standard and found a place
> (3.7.1 -2) where it is clearly stated that static objects which have
> an initialisation or a destructor with side effects shall not be
> eliminated even if they appear to be unused.
> So to me it is just a bug in M$ linker implementation.

The standard explicitly allows initialization to be delayed until you
call another function or access an object from the same translation unit
(in this case, you never do that, so initialization may be deferred
indefinitely which is equivalent to eliminating the object). See 3.6.2/3.

This is a well known problem that affects various linkers that attempt
to eliminate unused references.

Tom

bdachev
Fri Feb 23 08:55:15 CST 2007

> The standard explicitly allows initialization to be delayed until you
> call another function or access an object from the same translation unit
> (in this case, you never do that, so initialization may be deferred
> indefinitely which is equivalent to eliminating the object). See 3.6.2/3.
>
> This is a well known problem that affects various linkers that attempt
> to eliminate unused references.

Yes. I will have to admit with that I deliberately did not quote that
topic in the C++ standard in my previous reply to avoid the
confusion! :)
But please note that in both 3.6.2/3 and 3.7.1/2 topics there is a
note that objects initialisation or destruction should not have so
called "side effects". I was not able to find definition of that term
in the C++ standard document about that but my explanation about the
"side effect" is that contstructor or destructor should alter other
places of the execution unit. That is exactly my case where each
instance of the global object register itself to another global object
thus affecting other place in the execution unit.

I still insist that the Microsoft implementation is not correct!

B.

bdachev
Fri Feb 23 08:56:23 CST 2007

> Well, you can't expect linker to guess itself which globals are unreferenced
> but needed, can't you?

If you have read my reply to Uli you can see what I found in C++
Standard Documentation. It is stated that if global variables have
initialisation or destructor they should not be eliminated by the
linker even if they are not referenced by any other piece of code.
That is what the standard tells and to me Microsoft implementation is
not correct.

> Just create one "superclass" that will contain your globals as members, then
> create static instance of that class and pass it to the linker...

Globals are defined in several different object files depending on
other content of the file and inside their constuctor register
themselves in a global map object. I am not sure your suggestion could
be applied in this case.

Thanks anyway for your proposals!
Best regards,
B.

Alexander
Fri Feb 23 10:33:12 CST 2007

So are those globals or statics (as the thread subject says)?

<bdachev@gmail.com> wrote in message
news:1172242583.707227.189070@q2g2000cwa.googlegroups.com...
>> Well, you can't expect linker to guess itself which globals are
>> unreferenced
>> but needed, can't you?
>
> If you have read my reply to Uli you can see what I found in C++
> Standard Documentation. It is stated that if global variables have
> initialisation or destructor they should not be eliminated by the
> linker even if they are not referenced by any other piece of code.
> That is what the standard tells and to me Microsoft implementation is
> not correct.
>
>> Just create one "superclass" that will contain your globals as members,
>> then
>> create static instance of that class and pass it to the linker...
>
> Globals are defined in several different object files depending on
> other content of the file and inside their constuctor register
> themselves in a global map object. I am not sure your suggestion could
> be applied in this case.
>
> Thanks anyway for your proposals!
> Best regards,
> B.
>

bdachev
Fri Feb 23 11:12:12 CST 2007

On Feb 23, 6:33 pm, "Alexander Grigoriev" <a...@earthlink.net> wrote:
> So are those globals or statics (as the thread subject says)?

Objects are global in the context you are asking about.
They are defined in the global scope of given source file and do NOT
have "static" storage modifier infront of the definition to make them
local for the file.