Import of InfoZIP
nick at dsvr.net
Wed Dec 19 08:55:23 PST 2001
Ian Jeffray <ian at jeffray.co.uk> 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
I have just completed installing Peter's patch.
More information about the gcc