Nick Burrett nick at
Fri Jan 4 00:51:50 PST 2002

Alex Waugh <alex at> writes:

> Actually, that reminds me, I have a couple of questions about UnixLib's
> stack:
> In _syslib.s, there is a comment
> ; This line is needed for the GNU Objective-C runtime system.
> ; We need a safe 128 bytes of stack space to prevent a program
> ; crashing when the library does a direct copy off the stack.
> SUB sp, sp, #128
> How does the runtime system access this space, or should I just ignore
> it as Objective-C is not currently supported?

It occurs during the early initialisation phase of the Objective-C
runtime system. An object was being passed from function-to-function
but the memcpy thinks it has a larger footprint than it does in reality.
Don't expect anything less vague than that, since I added the hack back
in 1996/1997.
> Also in _syslib.s, a part of the stack (__sigstk) is allocated for the
> callback signal stack, but nothing apears to use this stack. Is this
> left over from some previous signal handler, or is it in preparation for
> some other changes, or have I just not found the code where it is used?

This stuff can be carefully unpicked and removed, you have to fix
_coredump.s though.  It might be better if I removed the hack.

I suggest that if you want to contribute any of your changes for pthreads,
then you submit code in small, logical patches, otherwise it will be
quite difficult for me to check it for any obvious errors.  You may
also want to post a complete diff to the list at some point so that we
can see if you are heading in the right direction and correct this at
an early stage.


More information about the gcc mailing list