[Openmcl-devel] create an executable from openmcl

Gary Byers gb at clozure.com
Fri Apr 18 13:47:51 PDT 2003

On Thu, 17 Apr 2003, Gary Byers wrote:
> >
> On a slightly-related note: the 'header' which describes the layout
> of an OpenMCL memory image is actually a 'trailer': it's at the end
> of the file.  As long as one is careful to observe certain alignment
> constraints (or uses tools that observe them for you), you can prepend
> pretty much anything to the front of a heap image (such as a shell
> script that calls the kernel with its own pathname as an image file
> argument or, in theory at least, the kernel itself.)
> Somewhere or other I have some code that does this and some examples
> of how it can be used; I'll try to find it and post it somewhere.

Suppose that we had a little shell script (not unlike the following)
that would prepend an arbitrary file on the front of something that
was presumed to be an openmcl heap image (observing alignment constraints)
and saved the result to a third file.  (We can also stretch our imaginations
a bit and ignore the fact that this looks suspiciously like something that
was hastily cobbled together ...)

------ Let's call this "prepend-to-image" and assume that it's chmod +x ----
if [ $# -ne 3 ] ; then
  echo "usage: $0 <infile> <image-file> <outfile>"
  exit 1

dd if=$1 of=$3 bs=4096 conv=sync
cat $2 >> $3
chmod +x $3
exit 0
------- EOF

Armed with such a shell script (or an equivalent ability to remember the
obscure arguments that the "dd" program takes), we can confidently
create an adder heap image, then prepend the openmcl kernel to it:

[ccl-0.13/ccl] gb at dervish> ./dppccl
Welcome to OpenMCL Version (Beta: Darwin) 0.13.5!
? (defun add3 (x) (+ x 3))
? (save-application "adder.image"
[ccl-0.13/ccl] gb at dervish>
[ccl-0.13/ccl] gb at dervish> ~/prepend-to-image ./dppccl ./adder.image ./adder
141+1 records in
142+0 records out
581632 bytes transferred in 0.055731 secs (10436407 bytes/sec)
[ccl-0.13/ccl] gb at dervish> file adder
adder: Mach-O executable ppc
[ccl-0.13/ccl] gb at dervish> ./adder ./adder

and we're back in terra cognito, wondering how to get this program
to stop asking us to type numbers to it ...

Note that we had to type the program name twice: once to invoke
it, and once to tell it where to map its image from.  It'd only be a matter
of time before adder users start clamoring for a "real" adder program
that they can invoke more easily.

------ cut here -----
diff -u -r1.39 pmcl-kernel.c
--- lisp-kernel/pmcl-kernel.c   6 Feb 2003 10:20:50 -0000       1.39
+++ lisp-kernel/pmcl-kernel.c   18 Apr 2003 20:18:34 -0000
@@ -1344,7 +1344,11 @@
   initial_stack_size = ensure_stack_limit(initial_stack_size);
   if (image_name == NULL) {
-    image_name = default_image_name(argv[0]);
+    if (check_for_embedded_image(argv[0])) {
+      image_name = argv[0];
+    } else {
+      image_name = default_image_name(argv[0]);
+    }

@@ -2083,6 +2087,23 @@

 #include "image.h"
+check_for_embedded_image (char *path)
+  int fd = open(path, O_RDONLY);
+  Boolean image_is_embedded = false;
+  if (fd >= 0) {
+    openmcl_image_file_header h;
+    if (find_openmcl_image_file_header (fd, &h)) {
+      image_is_embedded = true;
+    }
+    close (fd);
+  }
+  return image_is_embedded;

 load_image(char *path)
------------- cut here ------------

That change tells the lisp kernel that if an image name wasn't provided
as an argument it should see whether or not there's a heap image embedded
in the application itself.  One could imagine other policies (such as
ignoring a specified image argument if an embedded image was detected).

If that change is made to the kernel and we repeat the "prepend-to-image"
step, we seem to be firmly in the ranks of real adder applications.
(Whatever they are ...):

I'm afraid that it'll just have to be our little secret that there's
a lisp image embedded in that application; I hope that no one finds
out, and decides that it's somehow less "real" as a result.

[ccl-0.13/ccl] gb at dervish> ./adder

Whoops.  I suppose that it may be difficult to keep a lid on this

Openmcl-devel mailing list
Openmcl-devel at clozure.com

More information about the Openmcl-devel mailing list