home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8467 < prev    next >
Encoding:
Internet Message Format  |  1992-07-30  |  2.4 KB
  1. Path: sparky!uunet!paladin.american.edu!darwin.sura.net!mips!swrinde!sdd.hp.com!usc!sol.ctr.columbia.edu!destroyer!terminator!sinshan.citi.umich.edu!sarr
  2. From: sarr@sinshan.citi.umich.edu (Sarr J. Blumson)
  3. Newsgroups: comp.arch
  4. Subject: Re: Jump tables for shared libraries
  5. Message-ID: <1992Jul30.163048.16476@terminator.cc.umich.edu>
  6. Date: 30 Jul 92 16:30:48 GMT
  7. References: <1992Jul30.151301.27595@crd.ge.com>
  8. Sender: news@terminator.cc.umich.edu (Usenet Owner)
  9. Organization: University of Michigan, CITI
  10. Lines: 39
  11.  
  12. In article <1992Jul30.151301.27595@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
  13. >
  14. >  A recent post to comp.os.linux indicated that there would be a change
  15. >to jump tables for the shared libraries in the next release. WHile I
  16. >understand the convenience features of jump tables, it would seem that
  17. >there would be a better way to avoid relinking programs, which would
  18. >avoid the overhaed of the indirection.
  19. >
  20. >  Two thoughts come to mind. The first is to have some form of runtime
  21. >loader, which would do the linking at image activation time, rather than
  22. >at image store time. This would cause startup overhead, but would avoid
  23. >runtime overhead due to the indirect. The second would be to have the
  24. >jump table in unmapped memory, and have the o/s catch the call, modify
  25. >the image in memory to use the real address, and then restart the
  26. >program at the point of the call. This moves stuff down into the kernel,
  27. >and imposes a trap for each point in the image at which a library call
  28. >occurs.
  29. >
  30. Whether these are cost wins or loses depends on your model of program
  31. behavior.  Both of these are expensive compared to a single
  32. indirection, so if the call is only going to be executed once (eg a
  33. traditional UNIX tool which does something simple and exits) or if the
  34. linking will have to be redone every time the code is paged out
  35. (because the code is in a nominally read only segment and so is reread
  36. on page in and never paged out) you might actually lose.
  37.  
  38. >  My personal preference is to not have the jump table, and if I have to
  39. >relink programs when I upgrade my library, so be it. It's not that big a
  40. >deal, and programs without source (not in the linux world) could be
  41. >distributed as archives of objects and linked by the end user. This can
  42. >be automated with a tiny shell script.
  43. >
  44. This requires either very sophisticated users or application programs
  45. that KNOW they are using shared libraries, which ones, and how to
  46. check whether they've been updated.
  47.  
  48.  
  49.  
  50. (Sarr Blumson)
  51.