Import of InfoZIP

Nick Burrett nick at
Wed Dec 19 08:55:23 PST 2001

Ian Jeffray <ian at> writes:
> It may run fine, but I'm afraid I may annoy Peter by saying I don't
> think the design is best as it provides no obvious way to expand the
> module to have any real workspace as the workspace pointer [r12] is used
> as the head of the linked list of upcall handlers.  Not the best basis
> for a "SharedUnixLib" module, but fine for an "UpcallHandlerBodge" module.
> The relationship between the r12 passed to the upcall handler and the
> module's workspace pointer (it's private word) is too tight.  To fix
> that, a large-ish rewrite of the module would be needed.
> Once we start having parts of unixlib that the user could (and no doubt
> will) mix-and-match then there's gonna be shedloads of backwards-
> compatibility issies.  Ie, they might have an older or newer module than
> we were expecting at a given rev of unixlib when their app binary was
> built.  I think the way that works needs perhaps somewhat more thought
> than just what's been whipped up now (we've been thinking hard for a while,
> but never put a structure in place) and to imagine that it's correct
> right off could be a mistake.  We're leaving our cosy all-or-nothing
> library world and I forsee large dragons.

I agree with what you are saying, but for the time being we should be
OK treating this has a quick hack.  I think we would need to spend a
fair amount of time designing a stable API for the SharedUnixLibrary
before we could properly release it to the public.

This module patch allegedly fixes the UpCall crash, so I am happy to
see the bodge in place.  We can think carefully about a proper implementation
after Xmas.

I have just completed installing Peter's patch.


More information about the gcc mailing list