Linker REFERENCE directive

Discussion:

(too old to reply)

Robert McConnell

2013-09-22 02:32:56 UTC

While trying to track down a particularly elusive bug I found that the
bug disappeared when I forced a link to a certain otherwise unneeded
library I had created. The functions in the unneeded library were never
used but examination of the map showed that they in turn caused about 32
additional functions to be linked from the OW libraries.

In pursuit of the bug I'd like to see whether just the act of linking
the functions from the OW library without the unneeded library will
either cause the bug to disappear or show it is related to my own library.

According to the (1996) Watcom Linker User's Guide the REFERENCE
directive can force a library module to link. Since I am using the OW
1.9 IDE, I edited the corresponding automatically created .lk1 file
which was:

FIL dtsplot_d.obj
LIBR ..\dtsutil.lib,dtsplotlib.lib,dtsuilib.lib,numdatlib.lib
RES dtsplot_d.res

and added a line so it became

FIL dtsplot_d.obj
LIBR ..\dtsutil.lib,dtsplotlib.lib,dtsuilib.lib,numdatlib.lib
RES dtsplot_d.res
REF printf

The objective was to force printf, one of the additional functions
linked together with my extraneous library, to be linked without the use
of said extraneous library. If that worked, I planned to load about half
of the 32 OW functions at a time to start do a binary search to see
whether one particular function is responsible for the effect.

Unfortunately printf still does not appear in the map. Either I don't
understand what REF is supposed to do, I'm not using it properly, or it
does not work as specified since

Any help would be appreciated.

Thanks,

-rob

Hans-Bernhard Bröker

2013-09-22 11:11:38 UTC

Permalink

Post by Robert McConnell
While trying to track down a particularly elusive bug I found that the
bug disappeared when I forced a link to a certain otherwise unneeded
library I had created. The functions in the unneeded library were never
used but examination of the map showed that they in turn caused about 32
additional functions to be linked from the OW libraries.

But since those would be unused, too, the effect you see can conceivably
only be caused by a side effect of this change, most likely that of
moving around in memory space the parts of your program that you do use.
I.e. this linking in of additional stuff is most likely a red herring.
It just brushes the bug under a different corner of the carpet, where
you're less likely to tread on it.

There's a solid chance you could achieve a similar effect just by
changing the ordering of .obj files in the link. BUt I don't think the
IDE lets you change that ordering.

Post by Robert McConnell
Since I am using the OW 1.9 IDE, I edited the corresponding
FIL dtsplot_d.obj
LIBR ..\dtsutil.lib,dtsplotlib.lib,dtsuilib.lib,numdatlib.lib
RES dtsplot_d.res
and added a line so it became
FIL dtsplot_d.obj
LIBR ..\dtsutil.lib,dtsplotlib.lib,dtsuilib.lib,numdatlib.lib
RES dtsplot_d.res
REF printf

Editing the IDE's automatically generated files is hardly ever a good
use of your time. The IDE overwrites its *.lk1 every time it runs the
linker. There's an entry field for REFERENCE options in the linker
options dialog (Page 3 "Advanced Switches"). You should use that instead.

Post by Robert McConnell
Unfortunately printf still does not appear in the map.

Are you sure it shouldn't have been "_printf" or "printf_" you
referenced? The linker operates on the object files' internal
representation, not on source code names.

Robert McConnell

2013-09-22 12:37:35 UTC

Permalink

Many thanks. That did it. I don't know how I missed the IDE linker
option -must have been bug hunting fatigue.

The correct reference was indeed printf_ rather than printf.

-rob

Post by Hans-Bernhard BrÃ¶ker

But since those would be unused, too, the effect you see can conceivably
only be caused by a side effect of this change, most likely that of
moving around in memory space the parts of your program that you do use.
I.e. this linking in of additional stuff is most likely a red herring.
It just brushes the bug under a different corner of the carpet, where
you're less likely to tread on it.
There's a solid chance you could achieve a similar effect just by
changing the ordering of .obj files in the link. BUt I don't think the
IDE lets you change that ordering.

Post by Robert McConnell
Unfortunately printf still does not appear in the map.

Are you sure it shouldn't have been "_printf" or "printf_" you
referenced? The linker operates on the object files' internal
representation, not on source code names.

Wilton Helm

2013-09-25 16:40:01 UTC

Permalink

It's always so easy to assume something wrong with the tool chain, but most
often that turns out to be a distraction. In this case, the linker pulls in
functions because something already being linked before the file in question
is examined has created a dependency (an unresolved symbol listing).
Sometimes in the course of resolving that dependency (pulling in one or more
functions from the library file) new dependencies are created. These may be
resolved later in the same library file or in another library file (which
would have to be examined after this point--ordering can be very important).

The process gets started by one or more unresolved references created in the
startup file (or sometimes in an object file from a compiled module of the
application). That gets resolved from a library, forcing part of that
library to be loaded which in turn may require other things. For any
reasonably complex program, this process is rather convoluted and
interesting to observe. One hint at observing it is to look at the map
file, because functions show up there in the order they are linked which
sheds light on the order library files are examined.

Wilton