RE: [MI400] running PowerPC instructions in a user space

["Steve Richter" <srichter@xxxxxxxxxxxxx>]

-----Original Message-----
From: mi400-bounces@xxxxxxxxxxxx [mailto:mi400-bounces@xxxxxxxxxxxx]On
Behalf Of Peter Colson
Sent: Wednesday, November 17, 2004 12:22 AM
To: MI Programming on the AS400 / iSeries
Subject: Re: [MI400] running PowerPC instructions in a user space


>I'm beginning to think that a port of the gc is not possible to the
>native environment.

Never say never!

Why not if there is a thunk type boundary between the ILE call stack and the
GC call stack?  The native ILE code calls what it sees as a service program
or is patched at the powerpc code level to branch to the GC code.  There
would have to be a 2nd entry point for the GC function that the ILE proc
would call.  This entry point would perform the thunk, that is the initial
setup of the GC run time environment. Once in the GC code the program runs
as PASE GC code runs.

> There just seems to be too many things preventing
>the ability to scan all possible types of memory for a "root set" as a
>starting point to be searched for possibly "live" pointers and objects.
>The current stumbling block is a test program packaged with the gc that
>tries to malloc a bunch of pointers in a function call and intersperses
>these with garbage collections:
>
>     uniq(GC_malloc(12), GC_malloc(12), GC_malloc(12),
>          (GC_gcollect(),GC_malloc(12)),
>          GC_malloc(12), GC_malloc(12), GC_malloc(12),
>          (GC_gcollect(),GC_malloc(12)),
>          GC_malloc(12), GC_malloc(12), GC_malloc(12),
>          (GC_gcollect(),GC_malloc(12)),
>          GC_malloc(12), GC_malloc(12), GC_malloc(12),
>          (GC_gcollect(),GC_malloc(12)),
>          GC_malloc(12), GC_malloc(12), GC_malloc(12),
>          (GC_gcollect(),GC_malloc(12)),
>          (void *)0);

>Now what happens is a routine called GC_push_regs (called within
>GC_malloc) attempts to "mark" pointers contained in registers (which
>are in all probability being used to pass parameters) in an attempt to
>protect those objects pointed to from being reclaimed. On most
>platforms a platform-specific inline assembler version of the routine
>examines registers and allows marking of objects pointed to by pointers
>contained in those registers. This can't be done in the native 400
>environment (inline assembler, register access, that is), however a
>generic version written in C and using a setjmp() trick which at least
>compiles on the 400 also fails to do the necessary marking.

I dont follow completely, but why would any of the pointers being passed
from ILE code be GC_malloc allocated data? So why would it matter what the
GC memory management did?  More broadly, at the powerpc assembler level, you
can do whatever you want with the PPC registers.

>(As regards your initial post of executing PPC code in a user space
>object, another e-mail directed to me suggested that this may be
>possible on earlier versions of OS/400, but on something like V5R3
>(which I'm using for teraspace enablement) it becomes nigh on
>impossible because of user space object pages being marked "not
>executable" by the OS and causing an exception when an attempt is made
>to branch to code within such a page. Don't know for sure because it's
>not something I've tried myself...)

would be good to know if this is a security level thing or not.

-Steve