home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / aix / 8183 < prev    next >
Encoding:
Text File  |  1992-07-25  |  2.0 KB  |  43 lines
  1. Newsgroups: comp.unix.aix
  2. Path: sparky!uunet!newsgate.watson.ibm.com!yktnews!admin!yktnews!prener
  3. From: prener@watson.ibm.com (Dan Prener)
  4. Subject: Re: AIXv3 shared-library binding anomolies
  5. Sender: news@watson.ibm.com (NNTP News Poster)
  6. Message-ID: <PRENER.92Jul25200813@prener.watson.ibm.com>
  7. In-Reply-To: mike@pencom.com's message of 25 Jul 92 06:34:51 GMT
  8. Date: Sun, 26 Jul 1992 01:08:13 GMT
  9. Distribution: comp
  10. Disclaimer: This posting represents the poster's views, not necessarily those of IBM
  11. References: <PRENER.92Jul21033506@prener.watson.ibm.com> <1992Jul23.235023.5246@pencom.com>
  12.     <PRENER.92Jul24025541@prener.watson.ibm.com>
  13.     <1992Jul25.063451.6994@pencom.com>
  14. Nntp-Posting-Host: prener.watson.ibm.com
  15. Organization: IBM T.J. Watson Research Center, Hawthorne, New York
  16. Lines: 25
  17.  
  18. In article <1992Jul25.063451.6994@pencom.com> mike@pencom.com (Mike Heath) writes:
  19.  
  20. >What's to prevent the program loader from roping off a segment of memory
  21. >for each process at the same address (it's already pretty strict about
  22. >addresses), shoving in a TOC that contains an entry for each local symbol
  23. >referenced in the shared object, and using the TOC to determine where to
  24. >branch?  Granted, another level of indirection takes a performance hit,
  25. >but it can be done.  You could even have ld put in the glink code when
  26. >the library is built.  Not very pretty, though.
  27.  
  28. >How do other platforms do it?
  29.  
  30. >Playing devil's advocate today...
  31.  
  32. A fine devil's advocate, too.  Nothing is to prevent that, though
  33. it is not done today.  If the calls among shared library routines were
  34. treated like calls to imported routines, i.e., they went through the
  35. glink (glue linkage) code, then anyone could substitute a private
  36. version of a shared library routine.  The cost would be exactly what
  37. you indicated, namely that every process using the shared library
  38. would suffer the performance hit of going through glue code for calls
  39. between library routines, even those processes that didn't substitute
  40. any private versions of shared routines.
  41. --
  42.                                    Dan Prener (prener@watson.ibm.com)
  43.