Article on Unixlib

Alex Waugh alex at alexwaugh.com
Mon Jan 24 13:40:33 PST 2005


In message <216ef5314d.Jo at hobbes.bass-software.com>
          John Tytgat <John.Tytgat at aaug.net> wrote:

> In message <31edf8304d.ajw498 at caramel.cp15.org>
>           Alex Waugh <alex at alexwaugh.com> wrote:
> 
> > To put a bit more substance to my proposal, I think the process
> > structure should be something along the lines of the following.
> > [...]
> 
> The thing I'm still unsure of is if we really have a clear boundary
> what will move into SUL and what not with your proposal.  E.g. I
> understand that e.g. sys/_vfork.s will be part of it, but this imports
> several variables and routines so how will SUL have access to them ?

Sorry, I hadn't really explained that very much.

Much of the code in _vfork.s is just wrapping the bits that do the real
work. All the pthreads bits of that file would remain.
In vfork.c, the bits in __vfork() would disappear, although there would
be similar code added to SUL to handle duplicating relevant parts of
the process structure. Lots of __vexit would similarly disappear, the
rest would remain in UnixLib. The setjmp/longjmp bits of _vfork.s would
be replaced by the call to SUL's vfork, which would then store the
contents of the registers (much of the work done by setjmp/longjmp is
not needed for this, so the code will be a lot simpler then the longjmp
code), create the child's process structure and return. When the program
exits, it will call sul_exit (which I forgot to add to the process
stucture), and SUL will know if it was a child program or not. If it
was then it will restore the saved registers, and return to the program
as the parent again.

To support fork(), the code in UnixLib would be virtually identical to
the vfork code, but when it calls SUL's fork, SUL will additionally
increase the wimpslot and take a copy of the programs memory, which will
be restored when the child exits.

For exec(), most of the code in exec.c would remain the same, but the
code to shift pointers would disappear. All the code in _exec.s would
disappear, and it would be replaced by a similar amount of code in SUL.
If sul_exec is called from a vforked process then sul will move the
program to the top of the wimpslot before calling OS_CLI, if it is a
forked process then this won't be necessary as the copy would have
already been done at the time of the fork.

> > struct __sul_process
> > {
> >   void *(*sul_malloc)(size_t size); /* May be called in USR or SVC mode */
> >   void (*sul_free)(void *ptr);      /* May be called in USR or SVC mode */
> >   __pid_t pid;
> >   __pid_t ppid;
> >   __mode_t umask;
> >   void (*undef_handler)(void); /* Called by SUL (as the handler would normally
> >                                   be called, not APCS) */
> 
> I don't understand this comment.  The environment handler in SUL will be
> called.  Then that one will call the undef_handler routine.  But APCS-32
> compliant ?

It would be called with the same conditions as RISC OS called the
environment handler, i.e. it is not APCS compliant.

The handler in SUL would be something like:

undef_handler
  LDR    r12, [r12, #PROC_UNDEFHANDLER]
  TEQ    r12, #0
  MOVNE  pc, r12
  B  panic


Where OS_ChangeEnvironment was called with r2 set to the address of the
process structure, and PROC_UNDEFHANDLER is the offset the undef
handler within the process structure.

Actually, I'm having second thoughts about moving the environment
handlers to SUL. I think the same effect could be achieved within
UnixLib, provided that the old environment handlers were restored
before calling sul_(v)fork or sul_exec, then reregistered after the
call.
 
> BTW, will struct __sul_process live in RMA or in the application space ?

RMA. It has to be allocated by the SUL and not move if the program is
shifted up the wimpslot. It could potentially be in a dynamic area, but
I think that is overkill.

Alex

-- 
Alex Waugh                                           alex at alexwaugh.com

PHP, Roots, Subversion, WebJames and more from http://www.alexwaugh.com/



More information about the gcc mailing list