home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8463 < prev    next >
Encoding:
Internet Message Format  |  1992-07-30  |  2.4 KB
  1. Xref: sparky comp.arch:8463 comp.os.linux:7039
  2. Path: sparky!uunet!crdgw1!rdsunx.crd.ge.com!ariel!davidsen
  3. From: davidsen@ariel.crd.GE.COM (william E Davidsen)
  4. Newsgroups: comp.arch,comp.os.linux
  5. Subject: Jump tables for shared libraries
  6. Message-ID: <1992Jul30.151301.27595@crd.ge.com>
  7. Date: 30 Jul 92 15:13:01 GMT
  8. Sender: usenet@crd.ge.com (Required for NNTP)
  9. Reply-To: davidsen@crd.ge.com (bill davidsen)
  10. Followup-To: comp.arch
  11. Organization: GE Corporate R&D Center, Schenectady NY
  12. Lines: 37
  13. Nntp-Posting-Host: ariel.crd.ge.com
  14.  
  15.  
  16.   A recent post to comp.os.linux indicated that there would be a change
  17. to jump tables for the shared libraries in the next release. WHile I
  18. understand the convenience features of jump tables, it would seem that
  19. there would be a better way to avoid relinking programs, which would
  20. avoid the overhaed of the indirection.
  21.  
  22.   Two thoughts come to mind. The first is to have some form of runtime
  23. loader, which would do the linking at image activation time, rather than
  24. at image store time. This would cause startup overhead, but would avoid
  25. runtime overhead due to the indirect. The second would be to have the
  26. jump table in unmapped memory, and have the o/s catch the call, modify
  27. the image in memory to use the real address, and then restart the
  28. program at the point of the call. This moves stuff down into the kernel,
  29. and imposes a trap for each point in the image at which a library call
  30. occurs.
  31.  
  32.   My personal preference is to not have the jump table, and if I have to
  33. relink programs when I upgrade my library, so be it. It's not that big a
  34. deal, and programs without source (not in the linux world) could be
  35. distributed as archives of objects and linked by the end user. This can
  36. be automated with a tiny shell script.
  37.  
  38.   Is there newer and/or better thinking on this problem? I estimated the
  39. overhead at up to 5%, and the original poster mentioned that he actually
  40. measured 2-4% on programs. While that makes me feel good about my
  41. estimating skills, I'm not overjoyed at the thought of a 2-4% drop in
  42. performance. Hopefully someone will suggest an alternative method which
  43. I can pass along for consideration.
  44.  
  45.   I x-posted this, follows are directed to comp.arch for any Linux-ers
  46. who want to follow it.
  47. -- 
  48. bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
  49.     It never ceases to amaze me that otherwise rational people, able to
  50.     understand calculus, compound interest, and the income tax form, can
  51.     continue to believe that poker is a game of chance.
  52.