NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/os/linux/8330

Text File | 1992-08-15 | 3.7 KB | 78 lines

Newsgroups: comp.os.linux
Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!wupost!gumby!yale!mintaka.lcs.mit.edu!hal.gnu.ai.mit.edu!ericy
From: [e-mail] (Eric Youngdale)
Subject: Re: Jump Tables: A Mystery
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: /etc/organization
References: <[e-mail]>
Date: Sat, 15 Aug 1992 15:41:00 GMT
Lines: 66

In article <[e-mail]> [e-mail] (Sakari Aaltonen) writes:
>
>Several people responded to my recent whining about shared libraries
>by mentioning "jump tables".
>
>Jump tables?
>
>Is there a book or an article that explains the structure of shared
>libraries and of programs using them? I, too, would like to understand
>jump tables. I just can't find anything on them in Tanenbaum.

    Think of it in the following way.  The sharable library is nothing
more than some code that is guaranteed to be in a certain spot in virtual
memory (actually, the way it is set up, the name of the sharable library is
buried in your program startup code).  On linux, this address is the same for
every process, so every process can share the code pages for the sharable
libraries.

    When you link your program to the sharable library, the linker resolves
references to routines in the sharable library by using the actual addresses of
the routines.  This by itself works just fine, except for the fact that
when we update the library to fix bugs the addresses of the routines change
and the executables will no longer work.  This means that you have to relink
all of your programs.

    A jump table is just a series of jmp instructions, one right after
another.  This is usually placed right at the beginning of the sharable image,
and each jmp instruction jumps off to one of the routines in the sharable
image.  The idea is that when a new version of the library comes out, that
the jump table will still be in the same location in memory, and thus
all of the references in your program to the sharable library will still
effectively point to the correct routines.  Therefore you will still be able
to run your program without having to relink it.

    The cost is the extra indirection of the jmp instruction.  The benefit
is that you will not have to relink programs whenever you update the library.
In the past we have not had the jump tables, and it basically meant having to
keep the source code for *everything* on line, so that we could relink whenever
a new library comes out.  It appears as if we are on the verge of relinking for
the last time :-)

>My impression now is that shared libraries are something like MS-Windows
>dynamic link libraries. "Dynamic" seems a good description, as a matter
>of fact - code that is loaded into memory dynamically, at runtime.
>
>However, I think you can change MS-Windows DLL's as often as you like
>without recompiling or relinking the programs that use the libraries.
>You just have to keep the name of the DLL and the indexes of the functions
>therein the same, because the calling programs refer to the functions by
>library name (LINUX.DLL, say) and index (96, say). I don't know whether the
>name of the function matters.
>
>Why can't shared libraries be like that?

    That sounds very much like a jump table to me.  The index is nothing
more than the offset into the jump table, and you obviously need to know the
library name.  The idea behind both the DLLs and the jump tables is that you
can modify the library (i.e. fix bugs, add new functions, etc), without
invalidating any executables that are linked to the library.

-Eric
[e-mail]

(My regular new server is down right now, so I am using this address for the
time being).