home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / aix / 8124 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  2.2 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!swrinde!news.dell.com!uudell!pensoft!mike
  2. From: mike@pencom.com (Mike Heath)
  3. Newsgroups: comp.unix.aix
  4. Subject: Re: AIXv3 shared-library binding anomolies
  5. Message-ID: <1992Jul23.235023.5246@pencom.com>
  6. Date: 23 Jul 92 23:50:23 GMT
  7. References: <PRENER.92Jul19022217@prener.watson.ibm.com> <1992Jul20.223521.1080@ultra.com> <PRENER.92Jul21033506@prener.watson.ibm.com>
  8. Sender: usenet@pencom.com (Usenet Psuedo User)
  9. Distribution: comp
  10. Organization: Pencom Software, Austin, TX
  11. Lines: 39
  12.  
  13. In article <PRENER.92Jul21033506@prener.watson.ibm.com> prener@watson.ibm.com (Dan Prener) writes:
  14. >In article <1992Jul20.223521.1080@ultra.com> marc@mercutio.ultra.com (Marc Kwiatkowski {Host Software-AIX}) writes:
  15. >>There are two separate issues here.  First, the shared libc binds 
  16. >>local function calls at load time.  
  17. >
  18. >Actually, it binds them at link time.  Is that what you mean by "load time"?
  19. >I tend to think of load time as the time "exec" loads the program.
  20.  
  21. They are bound at link time, but the relocation information is retained.
  22. They could be rebound at load-time, but rebinding to an out-of-module
  23. routine would further complicate the program loader.  Also, how would
  24. the memory segment be shared among multiple processes?
  25.  
  26. >... Given the
  27. >lack of indirection in the current scheme, there is no way the bindings
  28. >can be changed at run time.
  29.  
  30. I don't see why not, but there would probably be a big price to pay.
  31.  
  32. >>I am a little skeptical about the claims of improved performance by 
  33. >>statically binding inter-library calls to exported functions.  What 
  34. >>percentage of all function calls within libc.a are calls to libc.a entry 
  35. >>points?
  36. >
  37. >The figure would depend on the application.  Statically, I think the
  38. >vast majority are.
  39.  
  40. Either I've misunderstood the question or the answer.  I think the question
  41. was refering to the shared part of the C library.  That shouldn't change
  42. with the application.  Sadly, the answer is more than you would have
  43. thought.  I count over 1000 different routines referenced within itself.
  44. Of course, damn near everything is exported.  The number of references
  45. for each routine is unimportant.
  46.  
  47. -- 
  48. Mike Heath        Pencom ...  We're not just headhunters anymore.
  49. Pencom Software        
  50. Austin, TX        
  51. mike@pencom.com
  52.