gmane.lisp.cmucl.devel

Snapshot tagged

Raymond Toy — 2008-09-02T17:09:56

The Labor Day snapshot (2008-09) has been tagged. Binaries will be uploaded soon. Ray

Re: run-program: find-a-pty: Newer systems do not support /dev/ttyXX PTYs

Carl Shapiro — 2008-08-18T06:48:55

Is there any reason not to use this method exclusively on Linux? According to the manual pages this functionality has been available for a while on Linux as well as all of the other operating systems CMUCL supports. Having a single code path through find-a-pty shared by all systems would be preferable.

run-program: find-a-pty: Newer systems do not support /dev/ttyXX PTYs

Madhu — 2008-08-17T14:31:16

Recent linux distributions (like os_11.0) which mount devpts on /dev/pts do not seem to support /dev/ttyp0 style ptys. This cause EXT:RUN-PROGRAM :PTY T to barf in FIND-A-PTY. The attached patch which supports opening a POSIX pty is ported over from SBCL. (In SBCL the new api is tried first) --Madhu diff --git a/code/run-program.lisp b/code/run-program.lisp index f465a74..bfdac84 100644 --- a/code/run-program.lisp +++ b/code/run-program.lisp < at >< at > -258,7 +258,6 < at >< at > (defvar *handlers-installed* nil "List of handlers installed by RUN-PROGRAM.") - ;;; FIND-A-PTY -- internal ;;; ;;; Finds a pty that is not in use. Returns three values: the file descriptor < at >< at > -297,7 +296,30 < at >< at > slave-fd slave-name))) (unix:unix-close master-fd)))))) - (error "Could not find a pty.")) + ;; could not find a PTY.. Try the unix98 api + (find-a-unix98-pty)) + +#-irix +(defun find-a-unix98-pty () + "Returns the master fd, the slave fd, and the name of the tty" + (let* ((master-name (coerce (format nil "/dev/ptmx") 'base-string)) + (master-fd (unix:unix-open master-name unix:o_rdwr #o666))) + (when master-fd + (alien-funcall (extern-alien "grantpt" (function int int)) + master-fd); check errno on error? + (alien-funcall (extern-alien "unlockpt" (function int int)) + master-fd) + (let* ((slave-name (alien-funcall + (extern-alien "ptsname" (function c-string int)) + master-fd)) + (slave-fd (unix:unix-open slave-name unix:o_rdwr #o666))) +(when slave-fd + (return-from find-a-unix98-pty + (values master-fd + slave-fd + slave-name))) +(unix:unix-close master-fd)) + (error "could not find a pty")))) #+irix (alien:def-alien-routine ("_getpty" c-getpty) c-call:c-string

Re: Solaris users?

Carl Shapiro — 2008-08-09T22:16:42

On Sat, Aug 9, 2008 at 10:38 AM, Chun Tian (binghe) gmail.com>wrote: Whatever you want, as long as it's available, is okay. I forgot to mention that you will need to update the x86-validate.h file with the parameters you specified in parms.lisp. However, I think you discovered this on your own. If you don't know what values to specify in those files (they should be the same) the best way to start is to look at the address space of a running program. I think you can retrieve this information with a call to "pmap -s " on Solaris systems. Look for the free regions of memory find unused space that can be reserved by CMUCL for its core file segments. After you have identified some candidate regions of memory you may want to write a small program that includes your x86-validate.h and tries to map all of those regions. Anyway, once you have confirmed those values are good you are ready to update parms.lisp and x86-validate.h and continue with the rest of your port. As part of the bootstrapping process, CMUCL builds a cross compiler that can target a different machine architecture and operating system that that of the system it is hosted on. The kernel.core is never run on the host. After the object code is built you need to transfer those bits over to the target machine to complete the bootstrapping.

Re: Solaris users?

Chun Tian (binghe — 2008-08-09T17:38:22

在 2008-8-10，上午1:18， Raymond Toy 写道： Thanks, replies from you and Carl in these days let me learn much about how CMUCL works:) I'm very confused about the address-map, is that OS-specific, CPU- specific, or just what ever you want is OK? I found CMUCL and SBCL's address-map definition are quite different, for example, the most common platform, x86/linux: SBCL: (src/compiler/x86/parms.lisp) #!+linux (progn (def!constant read-only-space-start #x01000000) (def!constant read-only-space-end #x010ff000) (def!constant static-space-start #x01100000) (def!constant static-space-end #x011ff000) (def!constant dynamic-space-start #x09000000) (def!constant dynamic-space-end #x29000000) (def!constant linkage-table-space-start #x01200000) (def!constant linkage-table-space-end #x012ff000)) CMUCL: (src/lisp/x86-validate.h) #ifdef __linux__ #define READ_ONLY_SPACE_START (SpaceStart_TargetReadOnly) #define READ_ONLY_SPACE_SIZE (0x0ffff000)/* 256MB - 1 page */ #define STATIC_SPACE_START(SpaceStart_TargetStatic) #define STATIC_SPACE_SIZE(0x0ffff000)/* 256MB - 1 page */ #define BINDING_STACK_START(0x20000000) #define BINDING_STACK_SIZE(0x07fff000)/* 128MB - 1 page */ #define CONTROL_STACK_START0x38000000 #define CONTROL_STACK_SIZE(0x07fff000 - 8192) #define SIGNAL_STACK_STARTCONTROL_STACK_END #define SIGNAL_STACK_SIZE8192 #define DYNAMIC_0_SPACE_START(SpaceStart_TargetDynamic) #ifdef GENCGC #define DYNAMIC_SPACE_SIZE(0x66000000)/* 1.632GB */ #else #define DYNAMIC_SPACE_SIZE(0x04000000)/* 64MB */ #endif #define DEFAULT_DYNAMIC_SPACE_SIZE(0x20000000)/* 512MB */ #ifdef LINKAGE_TABLE #define FOREIGN_LINKAGE_SPACE_START (LinkageSpaceStart) #define FOREIGN_LINKAGE_SPACE_SIZE (0x100000)/* 1MB */ #endif #endif Quite different, am I right? Why kernel.core from linux/x86 can be used to get macosx/ppc? Does this kernel.core make up with all byte-compiled fasls? (so that it can be load by "lisp" on ppc) --binghe

Re: Solaris users?

Raymond Toy — 2008-08-09T17:18:27

You will need to modify x86/parms.h (I think) and maybe x86-validate.h to select the right addresses for the linkage table area and for the addresses for all of the spaces. Perhaps a peek at sbcl could give some hints on the correct addresses. (I think sbcl has a solaris/x86 port.) FWIW, I have never been able to cross-compile from one architecture to another. But perhaps that's me. Obviously someone could, since linux/x86 was used to get macosx/ppc. I think Carl used x86 (FreeBSD?) to create macosx/x86. Ray

Re: Solaris users?

Chun Tian (binghe — 2008-08-09T16:21:43

Hi again, OK, I've found LINKAGE_TABLE_DATA, it's in "internals.h". Now I know more: LINKAGE_TABLE_DATA is generated the same time with "kernel.core" on cross host. But since the address map on darwin is completely different from solaris, this bootstrap path maybe wrong... I'll try bootstrap from solaris/sparc to solaris/x86 to see other possibility. --binghe

Re: Solaris users?

Chun Tian (binghe — 2008-08-09T15:44:39

Thanks, and I've started to do this port (just a try). I did a cross-compile from x86-darwin to x86-solaris. After modify and guess out many lines of code, now I have a kernel.core and a "lisp" execute file on Solaris 10 (x86) platform: bash-3.00$ gdb x86-target/lisp/lisp GNU gdb 6.2.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-pc-solaris2.10"... (gdb) run -core x86-target/lisp/kernel.core Starting program: /mnt/lisp/cmucl/trunk/x86-target/lisp/lisp -core x86- target/lisp/kernel.core WARNING: startup-code version (9) different from core version (8). You may lose big. Strange ... dynamic space lossage. Program received signal SIGSEGV, Segmentation fault. os_foreign_linkage_init () at ../../src/lisp/os-common.c:153 153 table_size = fixnum_value(linkage_data->fill_pointer); (gdb) display linkage_data 1: linkage_data = (struct array *) 0x0 Now my problem is that: linkage_data is NULL, I don't know why. By check it source code: unsigned long os_link_one_symbol(long entry) { #ifdef LINKAGE_TABLE lispobj linkage_data_obj = SymbolValue(LINKAGE_TABLE_DATA); struct array *linkage_data = 0; long table_size = 0; struct vector *data_vector = 0; struct vector *symbol_name; long type; void *target_addr; long table_index = entry * LINKAGE_DATA_ENTRY_SIZE; linkage_data = (struct array *) PTR(linkage_data_obj); I think the problem is LINKAGE_TABLE_DATA, I don't know its value and even don't know where is it. How can I find and check it? Regards, Chun Tian (binghe)

Re: Solaris users?

Raymond Toy — 2008-08-07T12:54:01

Chun> More questions: Chun> Q1) I saw x86::*control-stacks*, an array with 10 elements in Chun> multiproc.lisp. What's this variable used for? It seems that it's only Chun> defined in this file: Chun> * (describe 'x86::*control-stacks*) In addition to what Carl said, the C code also has access to this variable so it can GC the thread stacks appropriately. It's been a while since I looked, but I think these are the actual stacks for each thread. Chun> working together? I mean I don't know how your lisp code get access to Chun> some variable or function living in C code. Can you tell something, or Chun> any links I should see first? Carl has answere the other parts. Lisp gets access to variables and functions in C using the alien interface. The details are a little messy, but in essense, a table is maintained for C variables and functions and the table is used to either provide the address to a variable or to jump to the desired C function. Ray

Re: Solaris users?

Carl Shapiro — 2008-08-07T09:56:12

On Wed, Aug 6, 2008 at 10:23 PM, Chun Tian (binghe) gmail.com>wrote: It is a vector of pointers to thread stacks. Q2) I'm very curious in general CL's implement design. I saw almost all CLs This is a very open ended question. Here is something to get you started: The lisp executable provides certain runtime services such as signal handling and memory management including garbage collection. Initially, the C code in the lisp executable will memory map the various parts of the core file into the address space at startup time. It will then transfer control to lisp code in the core file. The lisp executable will then mostly be used for memory management: allocation, garbage collection, saving the heap, etc.. For starters, you will need to update the following files with information about Solaris x86... src/code/sunos-os.lisp src/code/x86-vm.lisp src/compiler/x86/parms.lisp You will need to create a new configuration file for the C code build called "Config.x86_solaris". You will then need to cruise through the C code and remove a lot of assumptions about Solaris that only pertain to the SPARC. All things considered, this should be a relatively easy port to complete.

Re: Solaris users?

Chun Tian (binghe — 2008-08-07T05:23:11

More questions: Q1) I saw x86::*control-stacks*, an array with 10 elements in multiproc.lisp. What's this variable used for? It seems that it's only defined in this file: * (describe 'x86::*control-stacks*) *CONTROL-STACKS* is an internal symbol in the X86 package. It is a special variable; its value is #(#() NIL NIL NIL NIL ...). #(#() NIL NIL NIL NIL ...) is a vector of length 10. It has no fill pointer. It is defined in: target:code/multi-proc.lisp Q2) I'm very curious in general CL's implement design. I saw almost all CLs are written in mainly two languages in their source code: C and Lisp itself. For CMUCL, I mean the "lisp" and "code" directories. When CMUCL was built, a "lisp" runtime execute file built from C source code in lisp directory, and a lisp image "lisp.core" built from other Lisp source code, ... My question is: how does these two parts working together? I mean I don't know how your lisp code get access to some variable or function living in C code. Can you tell something, or any links I should see first? Q3) CMUCL already has support on SPARC/solaris and X86/Linux, I think that means: CMUCL knows these two CPU-type at its compiler level, and these two OSs at runtime (and interface) level. If you try to port CMUCL to a new platform: X86/solaris, which part of CMUCL source code should be touched? What's the hardest point will be when doing this port?

Re: Solaris users?

Chun Tian (binghe — 2008-08-06T17:25:09

And, 3) If I want to bootstrap CMUCL on sparc, which C compiler should I use, GCC or SunStudio compilers? --binghe 在 2008-8-7，上午1:19， Chun Tian (binghe) 写道：

Re: Solaris users?

Raymond Toy (RT/EUS — 2008-08-06T17:28:44

Yes, that's correct. But all versions of solaris support 32-bits apps just fine. That's also correct. I think it's possible to add MP, but I've never needed it, so I never did. Don't think it would be too hard to do; basically port over a few vops for stack switching/copying, and update some of the stuff in multiproc.lisp to handle alien objects correctly. I thinnk. Ray

Re: Solaris users?

Raymond Toy (RT/EUS — 2008-08-06T17:32:15

I've been using SunStudio 11 compilers for a while now instead of gcc, but gcc is supposed to work. But according to comments in Config.sun4_solaris_gcc, debugging is painful with gdb > 4.18 and gdb 4.18 doesn't like binaries produced by gcc 3.3.3 or later. I haven't actually built with gcc for a while now. Ray

Re: Solaris users?

Chun Tian (binghe — 2008-08-06T17:19:48

Hi, rtoy I tried to run CMUCL on Solaris 10 today. The downloaded cmucl-2008-08- sparcv9-solaris8.tar.bz2 works fine, but I have some questions: 1) CMUCL on sparc is a 32-bit application (though Solaris 10 only support 64-bit SPARC CPU), am I right? 2) There's no MP support on sparc (because I see no :MP in *features*), am I right? Regards, Chun Tian (binghe) 在 2008-4-24，下午10:15， Raymond Toy (RT/EUS) 写道：

FreeBSD binaries [ re: Snapshot 2008-08 ]

Alex Goncharov — 2008-08-01T02:21:06

The 2008-08 binaries have been uploaded for FreeBSD 7.0 and 8.0. My 6.3 machine has been a bit busted recently and I decided not to struggle bringing it to life, which means I have no plans of producing the 6.3 binary for this snapshot and will try not to build on FreeBSD 6.3 in the future. I may resume the 6.3 builds if somebody really needs them.

Snapshot 2008-08

Raymond Toy (RT/EUS — 2008-07-31T17:45:42

The August snapshot has been tagged. Binaries will be uploaded soon. Ray

Re: [patch] Networking: bind to local-host/local-port when connect

Raymond Toy (RT/EUS — 2008-07-30T14:33:43

I didn't mean for you to fix this for me, but I'm grateful that you did. I've incorporated the changes, and updated the docs a little. These should be available in the next monthly snapshot due out in a day or so. Thanks, Ray

Re: [patch] Networking: bind to local-host/local-port when connect

Chun Tian (binghe — 2008-07-30T06:08:53

OK, what you thought is just another approach. It's OK to me, but this will change BIND-INET-SOCKET into a API interface function, so you have to export it. And since it's not internal function anymore, it must deal with string-like HOST argument. Follow your idea, I've made another patch (in both unix diff and lisp patch format), see it. Also, you will have to update the User Manual to add the new API function.

Re: [patch] Networking: bind to local-host/local-port when connect

Erik Huelsmann — 2008-07-29T21:53:38

On Tue, Jul 29, 2008 at 11:34 PM, Raymond Toy (RT/EUS) ericsson.com> wrote: Yes. It does. Bye, Erik.

Re: [patch] Networking: bind to local-host/local-port when connect

Raymond Toy (RT/EUS — 2008-07-29T21:34:32

Chun> CMUCL's networking API do not have standalone BIND function. And it's Chun> EXT:CONNECT-TO-INET-SOCKET and EXT:CREATE-INET-SOCKET function do not Chun> have any LOCAL-HOST/LOCAL-PORT argument. So a client socket is Chun> IMPOSSIBLE to bind to specific local host/port when CONNECT to remote Chun> address. I'm not sure create-inet-socket should take the additional args. According to the user's guide, section 10.7, create-inet-socket is supposed to create unbound sockets. This should be ok, because you've added bind-inet-socket, so you can bind to the local address if desired. But, connect-to-inet-socket, of course, needs the args to bind to the local host/port before connecting to the remote address. Does that sound right? Ray