Skip to content
Snippets Groups Projects
Forked from cmucl / cmucl
Source project has a limited visibility.
  • pw's avatar
    efd9aa3b
    I just finished making load-foreign work on SGIs, along with fixing calling of · efd9aa3b
    pw authored
    foreign functions taking floating-point arguments after integer arguments but
    before the fourth argument (more or less; mips has unusual C calling
    conventions), and making cmucl work on IRIX 6.2 on the Onyx (where the system
    page size has changed). I've included the patches below, along with some
    discussion of the changes and a couple of problems with cmucl's interaction with
    dynamic loading. Also, there's a misc change to make ioctls work (I'm not sure
    for what version the released code worked, but it doesn't work on anything I
    have). The patches do not fix the R10000; cmucl continues to not work on it (O2
    and Octane).
    
    The fixes make cmucl on the sgi use shared libraries so it can use dlopen et al
    in load-foreign; this is based on the solaris implementation. The problem with
    this is that the addresses of foreign variables are included directly in the
    dumped lisp image (without relocation on loading), which might result in a
    problem if cmucl is run with newer shared libraries than those it was compiled
    and dumped with. As far as I can tell, for the SGI at least, this does not
    affect function calls because the addresses used (and included in the dumped
    image) are those of stub routines that jump to the actual routines, thus are
    located in the executable proper rather than in the shared libraries, and so
    shouldn't be changed by a new version of the shared library.
    
    Unfortunately, this is not the case for global variables. Fortunately, there
    appear to only be two foreign variables used by cmucl in any of its system code
    winding up in the dumped image: errno and tzname. Apparently, Solaris relocates
    data references in dsos to match the program, while IRIX relocates data
    references in the program to match the dso. Thus, on Solaris, you don't need to
    do anything special for cmucl to work with a newer runtime libc, but on IRIX it
    gets the wrong value of errno and tzname. Unfortunately, the address of errno is
    different between irix 6.2, 6.3, and 6.4 (all of which we have to have because
    SGI doesn't have a single cross-platform OS version yet), which would require a
    different lisp.core for each machine (you just need to run mk-lisp, not
    recompile) if it weren't for the hack below. But fortunately again, a lisp
    compiled for one version seems to be able to run on another version well enough
    to generate the new lisp.core (presumably the worst that would happen is that
    error messages could be confusing). It would be really nice to avoid this
    problem. Perhaps some kind of relocation table could be added to the dumped
    image format? I don't know enough about the system to know how possible or
    ridiculous that suggestion is, unfortunately. Is the Solaris behavior guaranteed
    to be the same in future releases? If not, or if any other platforms have the
    irix behavior, this might become a more general problem. In the meantime, we use
    a hack: we *define* errno in undefineds.c rather than just referencing it; this
    results in warnings from the linker, but it resolves the conflict in favor of
    the definition in the program, relocating libc to match, thus fixing this
    problem for errno. The other global variables, tzname et al, can't be fixed this
    way as easily because they're listed as weak symbols, essentially aliases for
    the real symbol, so redefining them wouldn't cause libc to reference the new
    version. Thus, as long as you don't use tzname, there's no problem right now
    (although there may be if any other library global variables are used in cmucl
    in the future). The definition of tzname is in a progn preceeded by a comment
    which says not to use it, so hopefully it's not in fact used and therefore not a
    problem.
    
    
    These patches have been tested on an R5000 O2 running irix 6.3 and a dual R4400
    Onyx running irix 6.2. A previous version of these patches (for 17f) was tested
    on the onyx when it was running 5.3 (I think, maybe 5.2). The patches here are
    from the main branch of the CVS tar as of August 13. Incidentally, it was quite
    painful figuring out how to compile and bootstrap the current sources under the
    distributed irix 18a binary, even without trying :new-random or :signed-array
    (which I haven't tried to do yet); it might be nice to put a newer binary up...
    efd9aa3b
    History
    I just finished making load-foreign work on SGIs, along with fixing calling of
    pw authored
    foreign functions taking floating-point arguments after integer arguments but
    before the fourth argument (more or less; mips has unusual C calling
    conventions), and making cmucl work on IRIX 6.2 on the Onyx (where the system
    page size has changed). I've included the patches below, along with some
    discussion of the changes and a couple of problems with cmucl's interaction with
    dynamic loading. Also, there's a misc change to make ioctls work (I'm not sure
    for what version the released code worked, but it doesn't work on anything I
    have). The patches do not fix the R10000; cmucl continues to not work on it (O2
    and Octane).
    
    The fixes make cmucl on the sgi use shared libraries so it can use dlopen et al
    in load-foreign; this is based on the solaris implementation. The problem with
    this is that the addresses of foreign variables are included directly in the
    dumped lisp image (without relocation on loading), which might result in a
    problem if cmucl is run with newer shared libraries than those it was compiled
    and dumped with. As far as I can tell, for the SGI at least, this does not
    affect function calls because the addresses used (and included in the dumped
    image) are those of stub routines that jump to the actual routines, thus are
    located in the executable proper rather than in the shared libraries, and so
    shouldn't be changed by a new version of the shared library.
    
    Unfortunately, this is not the case for global variables. Fortunately, there
    appear to only be two foreign variables used by cmucl in any of its system code
    winding up in the dumped image: errno and tzname. Apparently, Solaris relocates
    data references in dsos to match the program, while IRIX relocates data
    references in the program to match the dso. Thus, on Solaris, you don't need to
    do anything special for cmucl to work with a newer runtime libc, but on IRIX it
    gets the wrong value of errno and tzname. Unfortunately, the address of errno is
    different between irix 6.2, 6.3, and 6.4 (all of which we have to have because
    SGI doesn't have a single cross-platform OS version yet), which would require a
    different lisp.core for each machine (you just need to run mk-lisp, not
    recompile) if it weren't for the hack below. But fortunately again, a lisp
    compiled for one version seems to be able to run on another version well enough
    to generate the new lisp.core (presumably the worst that would happen is that
    error messages could be confusing). It would be really nice to avoid this
    problem. Perhaps some kind of relocation table could be added to the dumped
    image format? I don't know enough about the system to know how possible or
    ridiculous that suggestion is, unfortunately. Is the Solaris behavior guaranteed
    to be the same in future releases? If not, or if any other platforms have the
    irix behavior, this might become a more general problem. In the meantime, we use
    a hack: we *define* errno in undefineds.c rather than just referencing it; this
    results in warnings from the linker, but it resolves the conflict in favor of
    the definition in the program, relocating libc to match, thus fixing this
    problem for errno. The other global variables, tzname et al, can't be fixed this
    way as easily because they're listed as weak symbols, essentially aliases for
    the real symbol, so redefining them wouldn't cause libc to reference the new
    version. Thus, as long as you don't use tzname, there's no problem right now
    (although there may be if any other library global variables are used in cmucl
    in the future). The definition of tzname is in a progn preceeded by a comment
    which says not to use it, so hopefully it's not in fact used and therefore not a
    problem.
    
    
    These patches have been tested on an R5000 O2 running irix 6.3 and a dual R4400
    Onyx running irix 6.2. A previous version of these patches (for 17f) was tested
    on the onyx when it was running 5.3 (I think, maybe 5.2). The patches here are
    from the main branch of the CVS tar as of August 13. Incidentally, it was quite
    painful figuring out how to compile and bootstrap the current sources under the
    distributed irix 18a binary, even without trying :new-random or :signed-array
    (which I haven't tried to do yet); it might be nice to put a newer binary up...