Subject: Re: HEADSUP: fwrappers, trace, profile - msg#00180

Previous Message by Date: click to view message preview

Re: "Standalone executables"

> Cool, I've always wanted to implement this capability myself, since it can > be useful in certain deployment situations, by simplifying isolated > stand-alone installations, and hence support hassles, or repeatability > issues. > > ... > > - I'd much rather like it if we were able to mmap the core sections > directly from the ELF executable... It would be really great if we > could convince the dynamic linker to do this for us on start-up, > but I think that's going to be tricky. Hence I'd be happy enough > if we could mmap the core out of the ELF binary itself... Is this > planned, or are there any deep problems along this direction that > I haven't thought of? I've been looking at this for some time. I think the latter suggestion above is really the way to go if we want to do this. If we do it right, all the memory mapping is automatic. The idea would be that saving an image would create an ELF executable that consists of sections copied from the "loader" (the lisp binary) and three extra elf sections (one for each core section: dynamic, static and read-only) that have program header entries that get them loaded automatically as segments in the runtime memory image. These program header entries have the load memory locations that the core sections usually have. Then when lisp is starting up, it could just look and see if its binary has a core section in it, and if so, and if there's no "core" flag given on the command line, just start running as if it had already mapped the core sections, because the OS will have done so. My idea to bootstrap this was to write a utility that could copy the executable and add the sections parsed from the core, and add the new program header entries. This is simple in concept, but the thing that has slowed me down is the grunt programming of copying the loader sections into a new executable and properly updating all the offsets. I intended to avoid using any vendor-specific ELF libraries because that creates a dependency on them, and just use the ELF documents as reference for implementing the code directly. However, to get the proof of concept up and running it might be easier to just bite the bullet and use the ELF libraries. -- Fred Gilham gilham@xxxxxxxxxxx I can't escape the sensation that I have already been thinking in Lisp all my programming career, but forcing the ideas into the constraints of bad languages, which explode those ideas into a bewildering array of details, most of which are workarounds for the language. --Kaz Kylheku

Next Message by Date: click to view message preview

Re: HEADSUP: fwrappers, trace, profile

Raymond Toy <toy@xxxxxxxxxxxxxxx> writes: > But this probably points to something else I must be doing wrong. My first > build has :pcl off and :no-pcl on. The second build has :pcl on and > :no-pcl off. However, since PCL wasn't built the first time, I can't > load pcl for the second build, but :pcl is on. Hm, it's probably not good if :PCL is a feature, but it's not there. It would be possible to change #+PCL to #+(and PCL (not NO-PCL)), but that looks slightly wrong. > Oh well, I guess I'll just always build pcl. Couldn't you arrange for :PCL to not be in *FEATURES*? How does it get there? [...] > But at least we know it can be done since SCL has an integrated CLOS. > But that might have been written from scratch, and I don't know if > bootstraps are easy or hard there. It would be interesting to learn more about this. In which parts of Lisp does it use CLOS? Is it PCL that runs in SCL, or some wannabe CLOS derived from Closette? (I tried to download SCL awhile ago, got a mail from Douglas Crosher that I'd better try CLISP or CMUCL, replied (nicely, I think) and didn't hear anything from him again. Maybe I pissed him off somehow, don't know :).)

Previous Message by Thread: click to view message preview

Re: HEADSUP: fwrappers, trace, profile

>>>>> "Gerd" == Gerd Moellmann <gerd.moellmann@xxxxxxxxxxx> writes: >> I normally don't build PCL because it takes a long time so I wait >> until the last build to get PCL included. However, it seems that this >> new encapsulation requires PCL to build CMUCL at all, because it >> uses functions from the PCL walker package. Gerd> It should do this only if :PCL is in *FEATURES*, unless I've screwed Gerd> up something, which I don't think because I tried a full Gerd> cross-compilation, which should build code: without PCL. Or maybe I Gerd> have a thinko somewhere? Well, I didn't do a cross-compile; just a normal compile But this probably points to something else I must be doing wrong. My first build has :pcl off and :no-pcl on. The second build has :pcl on and :no-pcl off. However, since PCL wasn't built the first time, I can't load pcl for the second build, but :pcl is on. Oh well, I guess I'll just always build pcl. >> Is this a step we really want to take? Would it be possible to >> incorporate the walker package into the core so the rest of PCL isn't >> needed to build cmucl? Gerd> That should be easy to do. Maybe it's even a good thing, dunno. Gerd> What do others think? I did not check for other errors/warnings, so other things might be needed. Let me try again.... Gerd> I'm afraid my cold-loaded PCL experiment is not a full success at the Gerd> end. It works fine, but from trying to redo some of the same changes Gerd> as in HEAD in a cold-loaded-PCL CMUCL, I fear it will make Gerd> bootstrapping CMUCL an even greater nightmare than it is now; I wasn't Gerd> able to bootstrap the recentish metaclass changes on top of an Gerd> existing PCL, for example. Ewww. Bootstrapping is hard enough as it is. But at least we know it can be done since SCL has an integrated CLOS. But that might have been written from scratch, and I don't know if bootstraps are easy or hard there. Ray

Next Message by Thread: click to view message preview

Re: HEADSUP: fwrappers, trace, profile

>>>>> "Paul" == Paul Werkowski <pw@xxxxxxxxxxxxx> writes: Paul> I have only :no-pcl for all cmucl only builds until I'm Paul> happy with the result. Only with the .core from the last Paul> build do I then remove :no-pcl, :no-clx, etc and compile Paul> that extra stuff. I haven't tried the new bits yet. I don't This is what I used to do too, until I started using Pierre's scripts. I'm probably doing something wrong. Ray