Re: calling my custom function same as library function

From: CBFalconer (cbfalconer_at_yahoo.com)
Date: 02/28/05 

Date: Mon, 28 Feb 2005 18:40:31 GMT

Walter Roberson wrote:
>
... snip ...
>
> In one pass linkers, if the user's object file defining [say]
> malloc() is placed between their other object files and the
> [possibly implicit] reference to the standard C library, then
> the user's definition will satisfy any malloc() references in
> the user's code; the one-pass linker will then "forget" that it
> has seen a definition of malloc() and will proceed onwards. When
> it then encounters an unsatisfied reference to malloc() inside the
> standard libraries, then it will either satisify the reference from
> the same library or will look further right for the definition,
> just as would normally be the case. That is, absent deliberate
> manipulation to cause otherwise, user definitions of library
> functions will [for one pass linkers] apply only to the user
> code, and the library definition will apply for anything further
> right such as the other libraries. One-pass linkers do not
> do "global" replacement of function references: only
> unsatisfied references to the left of the current object.
>
> I can't speak on what happens in practice with multipass linkers.
> I would, though, point out that it would be unusual for
> private interfaces to exist in library functions except at file
> scope, which would use internal linkage rather than external.

I think you are confused about the linker action. A multipass
linker will read all the object modules and resolve their addresses
on the first pass, and then resolve all references on the second
pass. This is much like the normal operation of an assembler.

A single pass linker will input code modules and prepare its own
internal list of fixups required, while recording the addresses of
defined modules. When a module is defined the existing fixups are
performed. How to get at the already linked code to perform that
fixup may be a problem.

However the linker treats libraries differently in that it does not
load a module, or record its address, unless it is needed to
resolve some existing reference. Thus the library loading order
becomes important, and even the module order within that library,
for single pass linkers. 

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

Relevant Pages

  • RE: unresolved symbols __eqd, __negd, __itod etc while building platform
    ... The __imp_ prefixes are references to the import table that the linker ... exported by various libraries like corecrt.lib, ...
    (microsoft.public.windowsce.embedded)
  • Re: strange linking problem
    ... I usually use C, and since strings ... the linker goes through the object ... files and looks for unsatisfied references to functions and variables. ... references by linking code from the libraries into the executable. ...
    (comp.lang.fortran)
  • Re: dynamically allocated memory
    ... >>linker object list the portable way to do this at link time? ... > separately from libc. ... > end up with malloc() and freefrom your own object, ... > This is less likely to be a problem with dynamic-linked libraries. ...
    (comp.unix.programmer)
  • Re: creating a Fortran library
    ... It is just how the Unix linker works... ... The main program has references ... which reference other libraries (quite common in all but pretty small ... You then need to specify the libraries in an appropriate ...
    (comp.lang.fortran)
  • Re: gcc linkage problems
    ... > references to symbols that are defined in the library. ... With your command line, the linker first opens ... I have extracted objects from ... > ordering for libraries objects with and without the static specifier. ...
    (comp.lang.cpp)