[Openmcl-devel] Unable to run linuxppc version on Ubuntu Hardy Heron

Gary Byers gb at clozure.com
Fri Sep 5 06:14:59 PDT 2008


The PPC offers addressing modes which make it easy to deal with 16-bit
constants and 16-bit absolute addresses.  CCL exploits this: things
like NIL and T are 16-bit constants (and the addresses of things
that are mapped into low memory); conditional calls to runtime 
support routines can use "branch absolute" instructions to call
those routines (which are also mapped into the low 16 bits of
the address space.)  Apple uses a similar scheme to reference
critical library routines in OSX (since the addressing mode
generally involved signed 16-bit addresses, Apple's scheme uses
addresses in the high 16 bits of the address space.)  That sort
of thing is what the addressing modes are for, after all.

Recent Linux kernels can be configured to enforce an upper limit on the
range of addresses that a (non-root) process is allowed to map
into its address space; this is intended (if I understand correctly)
to avoid problems having to do with NULL pointer references in the
Linux kernel.  It's not clear how effective this is in dealing
with those problems, but at least Ubuntu 8.04 and Fedora 9 ship
with the feature enabled and with a tunable parameter set to
restrict a process's access to the low 64K of its address space.
Whether this makes sense or not on other architectures is debatable;
on the PPC, it means that applications that want to exploit 16-bit
PPC addressing are prohibited from doing so.  I honestly don't
know if anyone involved in this decision thought about this issue
or what they concluded if so.  It's a little hard to believe
that much thought went into that decision.

Fortunately, there are a few workarounds:

- the restriction doesn't apply to processes running as root,
   so something like:

shell> sudo ccl

should allow the lisp to exercise control over its own address space.
(What a concept.)

- the "tunable parameter" is likely exposed as the contents of
the pseudofile "/proc/sys/vm/mmap_min_addr".  In the systems
that I've seen, cat'ing this file returns

shell> cat /proc/sys/vm/mmap_min_addr
65536

which has the effect of restricting a non-root process's access
to the low 64K of its address space.  Writing a smaller value
to that file (as root) will remove this restriction

# echo 4096 > /proc/sys/vm/mmap_min_addr

until the system is rebooted.

- it -may- be possible to change this value via 'sysctl', either until
the next reboot

# /sbin/sysctl -w vm.mmap_min_addr=4096

or by adding a line of the form

vm.mmap_min_addr=4096

to /etc/sysctl.conf

(which will take effect on the next and subsequent reboots.)

(The 4K value in the examples above makes NULL pointers impossible
but does make it possible for applications to use low-memory
addresses.)

On X86[64], there's no architectural advantage to using 16-bit
addresses (when it's even possible to do so.)   Version 1.1 of
CCL/OpenMCL happened to use very similar/very low addresses
(there was no reason not to); 1.2 and later use addresses
above 64K (mostly because Windows restricts address to the low
64K for other reasons.)

It might be possible to rearchitect PPC CCL to not try to
exploit architectural features, but it's not particularly
attractive.

On Fri, 5 Sep 2008, Bruce O'Neel wrote:

> Hi,
>
> On my Debian ppc systems ppccl runs fine.  I have to build it from source, but, no
> problem.
>
> A uname -a shows:
>
> Linux gnosca 2.6.18-6-powerpc #1 Tue Aug 19 04:51:39 UTC 2008 ppc GNU/Linux
>
> On my ubuntu hardy heron system the downloaded one, or, one built from source, doesn't run.
> It doesn't matter whether one tries the trunk svn checkout or the 1.2 release.
>
> edoneel at jungfrau:~/tmp/ccl$ ./ppccl
> Killed
> edoneel at jungfrau:~/tmp/ccl$ strace ./ppccl
> execve("./ppccl", ["./ppccl"], [/* 21 vars */]) = -1 EACCES (Permission denied)
> +++ killed by SIGKILL +++
> Process 6042 detached
> edoneel at jungfrau:~/tmp/ccl$
>
> I do have permission to read, write, and execute the ppccl
> executable.
>
> Any ideas?
>
> Thanks!
>
> cheers
>
> bruce
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>



More information about the Openmcl-devel mailing list