75008378%VAX2.NIHED.IE@cunyvm.cuny.edu (11/07/88)
Here's a funny thing:
I'm finally trying to get V1.3 running, and the first job, naturally,
to to get a clean libc.a. I had a couple of miscellaneous problems
(fgetc/fputc multiply defined because getc.c/putc.s both #include
stdio.c which promptly redefines getc/putc to fgetc/fputc...)
but all in all, everything compiled very nicely. So now I use
lorder/tsort to get a good ordering. Some problems getting
lorder to work (too many files to feed in on the command line,
in 1.2 at least, and building a libc.a and letting lorder extract
the files fails cause libupack doesn't handle pipes too well - again
in 1.2 at least; but a little hacking of lorder fixed that), but
I eventually got it going and then tsort decided there was a cycle in the
ordering.
tsort didn't actually tell me which modules were (allegedly) involved,
but a look at the tsort code, and some more hacking, seemed to show
that there were just two fishy modules, and they would be the last ones in
the tsort output. Another slight detour to split up the tsort output into
separate lines so I could actually *see* what was at the end (who says
"well behaved" programs wouldn't benefit from auto line wrap???) and the
suspects turn out to be rand.s and something else (I can't remember the
latter, but it doesn't matter too much - I didn't find anything else
wrong with it). A quick gander at the lorder output, grepping for
rand.s, shows the suspicious fact that there are two identical lines
showing uniqport.s depending on rand.s. Delete one of these and,
hey presto, tsort is happy, and the ordering looks sensible
(at least rand.s isn't at the end anymore...).
My question is this: *should* lorder/tsort behave like this? The only
reason I can see for the duplicate entry in the lorder output is that
uniqport separately references two different functions in rand - but that
hardly seems a reason for duplicating the entry?
If nayone wants to try and reproduce this, just run lorder on uniqport.s
and rand.s alone: this should do it, if my sources are close enough to the
genuine V1.3 sources (I can't quite vouch for this: my V1.3 sources are
mainly courtesy of Richard Hesketh - thanks again Richard - and, of
course, my versions of lorder and tsort were somewhat mutilated to make
them run under my antique V1.2).
This isn't actually holding me up anymore, but I'd still be interested
in hearing any comments/explanations...
[PS: Der Tynan: sorry for the delay - you *did* get thru to me once,
and I quote:
(To: amid!decwrl!ucbvax!cunyvm.cuny.edu!75008378%vax2.nihed.ie)
but, for the life of me I couldn't get back to you, no matter what
variation I seemed to try.... thanks anyway for trying.]
Barry McMullin, NIHED, Dublin, IRELAND.
<MCMULLINB@VAX2.NIHED.IE>wan@cory.Berkeley.EDU (Hank S. Wan) (11/08/88)
from <5225@louie.udel.EDU> >I eventually got it going and then tsort decided there was a cycle in the >ordering. > >tsort didn't actually tell me which modules were (allegedly) involved, There is a fix to tsort.c that was not applied to the 1.2 to 1.3 files from bugs.nosc.mil. Unfortunately, there are actually 2 versions of the fix to the same problem: <4207@killer.uucp> and <5760@killer.dallas.tx.us>. See if the change log at the head of your tsort.c contains: from <4207@killer.uucp>: > * readnode(): s1 & s2 should not keep using - 5/25/88 - mrw or from <5760@killer.dallas.tx.us> > * stupid error causing overlay of s1 & s2 in readnode - 9/12/88 - mrw I used the first fix and the above cycle problem went away. There does exists 1 cycle: catchsig.s and signal.s depending on each other. Since signal is the one that's usually used, I deleted the catchsig.s -> signal.s dependency. 2 questions: 1. There is no provision for the routines in libc.a not to contain any cycles. What does asld do when this happens? Does it read libc.a twice? :-( 2. As mentioned in the appendix in THE book, some linkers stop reading the whole libc.a when it has gathered all the necessary routines. What does asld do? If it does stop reading then we should place the most often used routines in libc.a first (which tsort has no way of doing). One solution to the above 2 problems which also speeds up the linking process is a bsd-like ranlib that builds an index at the beginning of an archive file. One would need to modify asld to do this. Is asld, just like the compiler, not public domain? If so is anyone working on a public domain version? -Hank Wan wan@cory.berkeley.edu
frank@morgan.com (Frank Wortner) (11/08/88)
Hank Wan <wan@cory.berkeley.edu> writes: > There does exists 1 cycle: catchsig.s and signal.s depending on each other. > Since signal is the one that's usually used, I deleted the > catchsig.s -> signal.s dependency. > > > > -Hank Wan > wan@cory.berkeley.edu Perhaps the problem Hank encounters here implies that signal.s and catchsig.s should actually be one source file. I don't have the code here to confirm this, but doesn't catchsig.s simply provide vectors signal? The vectors lead to a routine which builds a C stack frame so that a C routine can function as an interupt processor. This is what I remember --- PDP-11 Unix had a similar arrangement. Enough babble from me. ;-) Frank