guy@auspex.auspex.com (Guy Harris) (11/23/89)
"doload_preset" in all the versions of "doload.c" in the R4 beta version of Andrew (except the Apollo one, which doesn't have to bother with all that stuff since the Apollo OS already has a dynamic loading mechanism) handles commons in a ".do" file by "malloc"ing up some space. However, it doesn't zero out that space, which means it doesn't have the UNIX semantics of commons. I suspect this may ultimately be the cause of the hang in "help", reported a while ago and fixed by a workaround involving moving some YP and RPC stuff into "libcx.a". The problem appeared ultimately to have been caused by some BSS location not being zero, so this points in the direction of this bug; moving the YP/RPC stuff into "runapp" left it up to "ld", not "doload", to zero its commons out, which it does. It may also be the cause of some problems I saw with "console", which also appeared to have been caused by some BSS location not being zero and which were fixed by explicitly initializing some items in "console/lib/initglbs.h" to zero, so that they're no longer commons. It appears that the whole reason "console/lib/initglbs.h" exists in the first place is to move a bunch of stuff out of BSS, perhaps so that it *is* zeroed properly. Is it the intent that "doload" *not* zero out BSS? If so, this can certainly be worked around by Andrew code, using that very technique, but it can't be worked around by code pulled in from "libc", etc., since you have no control over that code; it would therfore seem that not having "doload" zero out BSS would be undesirable. Is this a performance issue? It already calls "malloc" for each common anyway; does adding a call to "bzero" make things noticeably worse?
zs01+@ANDREW.CMU.EDU (Zalman Stern) (11/25/89)
auspex!guy@uunet.uu.net (Guy Harris) writes: [ Bug report indicating that the class dynamic loader doesn't zero common storage blocks. ] > > Is this a performance issue? It already calls "malloc" for each common > anyway; does adding a call to "bzero" make things noticeably worse? Thanks for finding this. It is certainly not a performance issue. Rather it is a bug inherited from the orignal coding of the dynamic loader which I have looked for a number of times but never found. Either the bug was sufficiently subtle, or I wasn't looking hard enough... I think think this explains a lot of problems we have had. I'll see if I can get the fix on to the tape up at MIT. If not we will try to do it as a patch I guess. Sincerely, Zalman Stern Internet: zs01+@andrew.cmu.edu Usenet: I'm soooo confused... Information Technology Center, Carnegie Mellon, Pittsburgh, PA 15213-3890