From: Yaroslav K. <kav...@je...> - 2006-02-10 09:04:29
Attachments:
win32.patch.gz
|
Announce: (user-homedir-pathname); filenames/pathnames with non-ASCII chars; support windows ANSI/OEM codepages. Modified Files: src/code/fd-stream.lisp Log Message: pick-backup-name - change parameter type on win32 for non-ASCII filenames Modified Files: src/code/filesys.lisp Log Message: remove-backslashes, maybe-make-pattern, extract-name-type-and-version, directory-lispy-filenames, %enumerate-matches, %enumerate-directories, %enumerate-files, quick-integer-to-string, ensure-directories-exist - change parameter and/or variable type on win32 for non-ASCII filenames user-homedir-pathname - use on win32 (posix-getenv "HOME") or (sb-win32::get-folder-path SB-WIN32::CSIDL_PROFILE) Modified Files: src/code/octets.lisp Log Message: default-external-format - on win32 set to OEM codepage from windows (default codepage for terminal I/O) when use unicode Modified Files: src/code/toplevel.lisp Log Message: toplevel-init - on win32 search sbclrc as (sb-win32::get-folder-path SB-WIN32::CSIDL_COMMON_APPDATA) & "/sbcl/sbclrc" search .sbclrc in (user-homedir-pathname) Modified Files: src/code/unix.lisp Log Message: disable on win32 (c-strings->string-list... - define it in win32.lisp; on win32 change unix-pathname from simple-base-string to simple-string for non-ASCII filenames; disable on win32 (define-alien-routine ("getenv"... and (defun unix-rename... - define it in win32.lisp; unix-open - encoding name from windows ANSI codepage on win32 when use unicode; unix-access - encoding path from windows ANSI codepage on win32 when use unicode; disable on win32 (defun unix-mkdir.. and (defun posix-getcwd.. - define it in win32.lisp; unix-unlink, unix-stat, unix-lstat - encoding name from windows ANSI codepage on win32 when use unicode; unix-file-kind, unix-simplify-pathname - change parameter and/or variable type on win32 for non-ASCII filenames; unix-resolve-links - change parameter and/or variable type and concatenate type on win32 for non-ASCII filenames Modified Files: src/code/win32-pathname.lisp Log Message: extract-device, split-at-slashes-and-backslashes - change parameter type on win32 for non-ASCII filenames; parse-win32-namestring, parse-native-win32-namestring - change coerce type on win32 for non-ASCII filenames; unparse-win32-piece, unparse-win32-directory-list, unparse-win32-file, unparse-win32-namestring - change concatenate type on win32 for non-ASCII filenames; unparse-native-win32-namestring - change coerce type on win32 for non-ASCII filenames; unparse-win32-enough - change typep type on win32 for non-ASCII filenames. Modified Files: src/code/win32.lisp Log Message: add alien-types UINT and tchar; add constant +default-environment-length+; define alien function LocalFree (kernel32.dll); define *ANSI-CP* and *OEM-CP* variables; when use unicode define hash-table *cp-to-external-format* and filling it; define ansi-cp and oem-cp functions for access to variables or filling it; define some macros and functions to encode to/from UCS-2/OEM/ANSI codepages; define function get-error-message and macro win32-error; define function get-folder-path from SHGetFolderPath; define posix-getcwd, unix-mkdir, unix-rename, posix-getenv and c-strings->string-list with using windows system or/and sb-win32 functions; define set-current-directory (analog `cd` shell command); define setenv; add some alien types and functions for run-progarm (in progress). Modified Files: src/runtime/win32-os.c Log Message: add some windows system function calls. Modified Files: tools-for-build/grovel-headers.c Log Message: define some constants for windows system functions. |
From: Rudi S. <ru...@co...> - 2006-02-13 11:53:57
Attachments:
PGP.sig
|
Hi Yaroslav, Unfortunately, the build fails for me with symptoms similar to when I accidentally linked with cygwin1.dll: a failure in VirtualAlloc right at the start of make-target-2 (when starting the fresh cold-sbcl.core the first time). I'm suspecting shell32.dll is sitting somewhere in sbcl's address space. Since this may be a problem on my pc only, calling out to windows- using people: can you build win32 with the patches and report back? Thanks! Two comments from a slightly sleep-deprived rudi: - The win32-specific filename arg types are unfortunate, but I think can go in until a general solution for non-ascii filenames gets implemented. - Am I right that a utf-16 (or at least ucs-2) external format would enable you to remove the manual encoding/decoding you do in win32.lisp ? Sorry for the bad news, and thanks for all the work, Rudi |
From: Alastair B. <nye...@li...> - 2006-02-13 12:13:38
|
Rudi Schlatte writes: > Unfortunately, the build fails for me with symptoms similar to when I > accidentally linked with cygwin1.dll: a failure in VirtualAlloc right at > the start of make-target-2 (when starting the fresh cold-sbcl.core the > first time). I'm suspecting shell32.dll is sitting somewhere in sbcl's > address space. This sort of thing is going to happen more and more often on various different windows boxes as time goes by, since we can't easily play the same games with the linker and re-executing ourselves under different emulation environments and whatnot as we do on other systems. So far as I know, there is one permanent solution, and one workaround. The workaround is to bind against a minimal set of DLLs in the executable and load extra DLLs after loading the core file. This will reduce (but not eliminate) these problems. You will probably need working linkage-tables for this. The permanent solution number is relocatable cores. 'Nuff said. --Alastair Bridgewater |
From: David L. <da...@li...> - 2006-02-16 15:36:52
|
Hi, Quoting Alastair Bridgewater (nye...@li...): > The permanent solution number is relocatable cores. 'Nuff said. core file relocation has been mentioned often as a solution for issues on OS X and now on Windows. But so far nobody proposed anything specific. If the problem does not occur often, solving it is probably not worth the maintenance hassle. If, on the other hand, it occurs very often, users will have to live with the cost of a larger startup time (say, about the time for a full GC to relocate dynamic space; about 100ms for a 35 MB core for me). So are those mysterious relocatable cores everyone wants really worth it? Perhaps a technical proposal helps: I have a patch to relocate dynamic space at startup time if it cannot be mapped to its default location. I have not really used this patch yet, but it starts up and passes the tests[*]. Changes: * rename DYNAMIC_SPACE_START to DEFAULT_DYNAMIC_SPACE_START * replace most uses with a new variable dynamic_space_start * map dynamic space without MAP_FIXED, set dynamic_space_start to the actual location * If dynamic_space_start != DEFAULT_DYNAMIC_SPACE_START, rewrite all addresses in dynamic and static space that point to dynamic space to account for the move. Steps 1-4 are mostly trivial. Step 5 is what I had already written for sb-heapdump. This does not help with a heap that is too fragmented to map a block of DYNAMIC_SPACE_SIZE. An easy workaround could be to try smaller chunks until mapping succeeds, as suggested by foom on #lisp, although a highly fragmented heap would still be problematic then, as it could drastically reduce the available heap size. (More clever schemes for a fragmented dynamic space could probably be invented but would have to involve changes to the page table that might not be popular, I think.) The patch makes no attempt at relocation of the other spaces. Would this help on Windows? David [*] with the exception of core.test.sh and foreign.test.sh, because save-lisp-and-die doesn't work in a relocated image yet. Simple to fix though. |
From: Juho S. <js...@ik...> - 2006-03-04 21:32:43
|
<da...@li...> wrote: > If the problem does not occur often, solving it is probably not worth > the maintenance hassle. If, on the other hand, it occurs very often, > users will have to live with the cost of a larger startup time (say, > about the time for a full GC to relocate dynamic space; about 100ms for > a 35 MB core for me). > > So are those mysterious relocatable cores everyone wants really worth it? I think the increased robustness would definitely be worth it, as the extra startup cost only occurs in cases that would've normally failed completely. > Perhaps a technical proposal helps: > > I have a patch to relocate dynamic space at startup time if it cannot be > mapped to its default location. I have not really used this patch yet, > but it starts up and passes the tests[*]. Cool, the approach seems sound. One style nit, validate.c shouldn't be using mmap directly. Maybe: * Remove the MAP_FIXED flags also from the non-Linux implementations of os_validate * Move the "addr != actual" check in the linux os_validate to the callers that pass non-zero addrs * Use os_validate instead of the raw mmap in validate.c And of course saving a core from relocated images needs to work. But other than the above, this looks committable. (It would be nice to make the cheneygc dynamic spaces movable too, but it's orthogonal to this patch, and at least from my point of view not a showstopper). > This does not help with a heap that is too fragmented to map a block of > DYNAMIC_SPACE_SIZE. An easy workaround could be to try smaller chunks > until mapping succeeds, as suggested by foom on #lisp, although a highly > fragmented heap would still be problematic then, as it could drastically > reduce the available heap size. (More clever schemes for a fragmented > dynamic space could probably be invented but would have to involve > changes to the page table that might not be popular, I think.) Fragmentation as such seems like a non-problem in practice. But trying smaller chunks would be pretty cool for environments with aggressive memory limits. > The patch makes no attempt at relocation of the other spaces. That's fine, IMO. -- Juho Snellman |
From: James Y K. <fo...@fu...> - 2006-03-22 18:44:23
|
On Mar 4, 2006, at 3:44 PM, Juho Snellman wrote: > * Remove the MAP_FIXED flags also from the non-Linux > implementations of > os_validate > * Move the "addr != actual" check in the linux os_validate to the > callers that pass non-zero addrs As I recall, some OSes (FreeBSD perhaps?) ignore the passed in address if MAP_FIXED isn't given. Thus doing a non-MAP_FIXED mmap followed by address validation won't work for them. You should at least watch out for it if making this change... James |
From: David L. <da...@li...> - 2006-03-23 19:11:11
|
Quoting James Y Knight (fo...@fu...): > > * Remove the MAP_FIXED flags also from the non-Linux > >implementations of > > os_validate > > * Move the "addr != actual" check in the linux os_validate to the > > callers that pass non-zero addrs > As I recall, some OSes (FreeBSD perhaps?) ignore the passed in > address if MAP_FIXED isn't given. Thus doing a non-MAP_FIXED mmap > followed by address validation won't work for them. You should at > least watch out for it if making this change... Thanks for the warning. Here is a new patch: os_validate gets a new argument `fixedp'. Dynamic space is mapped without fixedp, all other callers use fixedp==1. Behaviour by operating system: * linux-os.c: make the address assertion conditional on fixedp * bsd-os.c: Use MAP_FIXED to implement fixedp, necessary because (at least) the read-only space is in an area that mmap would not otherwise give to us. No MAP_FIXED necessary for the default dynamic space location though, so relocation works as intended. * sunos-os.c: Always use MAP_FIXED if an address is given, because the kernel does not actually seem to use our address hints at all otherwise (even though the manpage implies otherwise). Since we do not want to relocate on every startup, no relocation support at all on Solaris. I guess this being solid and stable commercial software, we do not have to expect random memory layout changes anyway. ;-) * osf1-os.c: no idea. * win-os.c: fixedp not implemented yet, please help! http://www.lichteblau.com/blubba/relocate-4.diff Tested on Linux and FreeBSD 6. Solaris is unchanged, so should be unharmed. It would be nice if someone could check that this still builds on Darwin and older FreeBSD. d. |
From: Edi W. <ed...@ag...> - 2006-02-13 12:33:10
|
On Mon, 13 Feb 2006 12:53:19 +0100, Rudi Schlatte <ru...@co...> wrote: > Since this may be a problem on my pc only, calling out to windows- > using people: can you build win32 with the patches and report back? I won't have much time for it this week, but just in case: I downloaded the 0.9.9 source tarball and it was not immediately clear to me how one would build SBCL on Win32. Do I need make and other tools from Cygwin? Do I have to cater for Cygwin pathnames? Do you guys build from CLISP (Win32 native or Cygwin?) or from the SBCL Win32 binary? (Can I use LispWorks?) Sorry if I'm just too dumb or didn't find the right part of the fine manual. Cheers, Edi. |
From: Yaroslav K. <kav...@je...> - 2006-02-13 13:39:25
|
Rudi Schlatte wrote: > Hi Yaroslav, > > Unfortunately, the build fails for me with symptoms similar to when I > accidentally linked with cygwin1.dll: a failure in VirtualAlloc right > at the start of make-target-2 (when starting the fresh cold-sbcl.core > the first time). I'm suspecting shell32.dll is sitting somewhere in > sbcl's address space. > > Since this may be a problem on my pc only, calling out to windows- > using people: can you build win32 with the patches and report back? > Thanks! > On Windows-2000 I do not get this error. But on Windows XP build fails. I use editbin.exe for overcoming this trouble. > Two comments from a slightly sleep-deprived rudi: > - The win32-specific filename arg types are unfortunate, but I think > can go in until a general solution for non-ascii filenames gets > implemented. But it is work... > - Am I right that a utf-16 (or at least ucs-2) external format would > enable you to remove the manual encoding/decoding you do in win32.lisp ? > Hmm, UCS-2 external format have some overhead - it take 2 byte and build 1 (UNSIGNED-BYTE 16), but my manual encoding/decoding read/write data at once on (UNSIGNED-BYTE 16). Maybe, this is nothing... > Sorry for the bad news, and thanks for all the work, > It is not the reason to stop :) > Rudi -- WBR, Yaroslav Kavenchuk. |
From: Rudi S. <ru...@co...> - 2006-02-13 14:09:38
Attachments:
PGP.sig
|
On 13. Feb 2006, at 14:40, Yaroslav Kavenchuk wrote: > Rudi Schlatte wrote: >> Since this may be a problem on my pc only, calling out to windows- =20= >> using people: can you build win32 with the patches and report =20 >> back? Thanks! > > On Windows-2000 I do not get this error. But on Windows XP build =20 > fails. I use editbin.exe for overcoming this trouble. That's interesting; can you describe your solution? (As you can =20 guess, I'm not familiar with editbin ...) >> Two comments from a slightly sleep-deprived rudi: >> - The win32-specific filename arg types are unfortunate, but I =20 >> think can go in until a general solution for non-ascii filenames =20 >> gets implemented. > > But it is work... Ah, sorry, I didn't mean to imply that you personally should do the =20 work! It might also be an sbcl/os x user who gets sufficiently =20 annoyed that (open "=DCber.txt") throws an error ... As I said, I'm =20 willing to merge this part of the patch if there is no veto from =20 other developers, and record an entry in BUGS to the effect of "open =20 fails with non-base-strings on all systems but win32". >> - Am I right that a utf-16 (or at least ucs-2) external format =20 >> would enable you to remove the manual encoding/decoding you do in =20= >> win32.lisp ? > > Hmm, UCS-2 external format have some overhead - it take 2 byte and =20 > build 1 (UNSIGNED-BYTE 16), but my manual encoding/decoding read/=20 > write data at once on (UNSIGNED-BYTE 16). Maybe, this is nothing... Personally, I'd go with consistency and source code size over speed =20 if the code isn't on a fast path. But this is very much a question of =20= taste ... >> Sorry for the bad news, and thanks for all the work, > > It is not the reason to stop :) Glad to hear! Cheers, Rudi |
From: Yaroslav K. <kav...@je...> - 2006-02-13 14:34:38
|
Rudi Schlatte wrote: > On 13. Feb 2006, at 14:40, Yaroslav Kavenchuk wrote: > That's interesting; can you describe your solution? (As you can > guess, I'm not familiar with editbin ...) > $ editbin.exe Microsoft (R) COFF Binary File Editor Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. usage: EDITBIN [options] [files] options: /BIND[:PATH=path] /HEAP:reserve[,commit] /LARGEADDRESSAWARE[:NO] /NOLOGO /REBASE[:[BASE=address][,BASEFILE][,DOWN]] /RELEASE /SECTION:name[=newname][,[[!]{cdeikomprsuw}][a{1248ptsx}]] /STACK:reserve[,commit] /SUBSYSTEM:{NATIVE|WINDOWS|CONSOLE|WINDOWSCE|POSIX}[,#[.##]] /SWAPRUN:{[!]CD|[!]NET} /VERSION:#[.#] /WS:[!]AGGRESSIVE I set HEAP. I do not remember concrete numbers - WinXP on home. Resume: I have understood, that now my patches will not apply. Well, I shall continue work ith win32 port. I regret about I remain "in own juice" (excuse me my bad English). -- WBR, Yaroslav Kavenchuk. |
From: Ivan B. <bol...@cg...> - 2006-02-14 03:07:12
|
On 9384 day of my life Yaroslav Kavenchuk wrote: >> - Am I right that a utf-16 (or at least ucs-2) external format would >> enable you to remove the manual encoding/decoding you do in >> win32.lisp ? > > Hmm, UCS-2 external format have some overhead - it take 2 byte and > build 1 (UNSIGNED-BYTE 16), but my manual encoding/decoding read/write > data at once on (UNSIGNED-BYTE 16). UCS-2 ext. format is under development. 5 minutes ago you was right, but now you are wrong: under x86 UCS-2LE ext. format reads and writes 2 bytes at once :) It seems that there in no special *FEATURE* for little-endian/big-endian machines; thus it will be x86-only optimization. Platforms like Spark would be benefit from same optimization for UCS-2BE. -- Ivan Boldyrev XML -- new language of ML family. |
From: Yaroslav K. <kav...@je...> - 2006-02-14 07:17:27
|
Ivan Boldyrev wrote: > UCS-2 ext. format is under development. 5 minutes ago you was right, > but now you are wrong: under x86 UCS-2LE ext. format reads and writes > 2 bytes at once :) > > It seems that there in no special *FEATURE* for > little-endian/big-endian machines; thus it will be x86-only > optimization. > > Platforms like Spark would be benefit from same optimization for > UCS-2BE. > Thanks! I very glad. I go to correct the my addons... Oops, where new version of enc-ucs.lisp? -- WBR, Yaroslav Kavenchuk. |
From: Rudi S. <ru...@co...> - 2006-02-13 12:42:44
Attachments:
PGP.sig
|
On 13. Feb 2006, at 13:33, Edi Weitz wrote: > I won't have much time for it this week, but just in case: I > downloaded the 0.9.9 source tarball and it was not immediately clear > to me how one would build SBCL on Win32. Do I need make and other > tools from Cygwin? Do I have to cater for Cygwin pathnames? Do you > guys build from CLISP (Win32 native or Cygwin?) or from the SBCL Win32 > binary? (Can I use LispWorks?) Sorry for that; sbcl on win32 is still in a state of flux, so there's not much documentation yet. You need gcc (either mingw or cygwin should work fine; please report if they don't) and sbcl itself (binaries are up at sbcl.org). the way I build is I copy sbcl.exe and sbcl.core from the downloaded archive to the parent directory of the sbcl source tree, then (from a cygwin shell) execute sh make.sh "../sbcl.exe --core ../sbcl.core" I built and self-built the then-current cvs version with cygwin yesterday, so it should all work. Building with LispWorks has not been attempted yet as far as I know; I suspect it will turn up interesting bugs/ansi conformance issues/hidden assumptions in both LW and sbcl itself. Cheers, and looking forward to the meeting in Hamburg, Rudi |
From: Edi W. <ed...@ag...> - 2006-02-13 13:42:19
|
On Mon, 13 Feb 2006 13:42:29 +0100, Rudi Schlatte <ru...@co...> wrote: > Sorry for that; sbcl on win32 is still in a state of flux, so > there's not much documentation yet. You need gcc (either mingw or > cygwin should work fine; please report if they don't) and sbcl > itself (binaries are up at sbcl.org). > > the way I build is I copy sbcl.exe and sbcl.core from the downloaded > archive to the parent directory of the sbcl source tree, then (from > a cygwin shell) execute > > sh make.sh "../sbcl.exe --core ../sbcl.core" > > I built and self-built the then-current cvs version with cygwin > yesterday, so it should all work. Thanks Rudi, I'll see if I find some time to give it a try in the next days. I have the SBCL 0.9.9 binary and it works fine here (WinXP pro SP2). > Building with LispWorks has not been attempted yet as far as I know; > I suspect it will turn up interesting bugs/ansi conformance > issues/hidden assumptions in both LW and sbcl itself. OK... :) > Cheers, and looking forward to the meeting in Hamburg, Yeah, same here. I just returned from the phone trying to organize the dinners. Looks like we'll have everything settled in a day or two. Cheers, Edi. |
From: Yaroslav K. <kav...@je...> - 2006-02-13 13:44:30
|
Rudi Schlatte wrote: > On 13. Feb 2006, at 13:33, Edi Weitz wrote: > > Sorry for that; sbcl on win32 is still in a state of flux, so there's > not much documentation yet. You need gcc (either mingw or cygwin > should work fine; please report if they don't) and sbcl itself > (binaries are up at sbcl.org). > > the way I build is I copy sbcl.exe and sbcl.core from the downloaded > archive to the parent directory of the sbcl source tree, then (from a > cygwin shell) execute > > sh make.sh "../sbcl.exe --core ../sbcl.core" > It is work on mingw/msys too -- WBR, Yaroslav Kavenchuk. |
From: Christophe R. <cs...@ca...> - 2006-03-10 12:25:23
|
Yaroslav Kavenchuk <kav...@je...> writes: > Announce: > (user-homedir-pathname); > filenames/pathnames with non-ASCII chars; > support windows ANSI/OEM codepages. Hi. Would it be possible to split this patch up into logical self-contained pieces? I now have a mostly-working windows mingw environment, and built sbcl CVS on it today, so potentially I could do a very limited amount of merging. However, my access to this environment is limited to two hours a week, so I don't have time to edit failing patches, or even ones that I don't like; additionally, breaking it up into pieces will help us work out if there is something systematic about failure to map our dynamic space in the place we want it. Regarding the patch that you sent itself: I'm not happy with the pathname stuff. I am happy that someone is looking at it, but I don't think you've gone about it the right way, unfortunately. You have introduced things like VECTOR->STRING and VECTOR->STRING&FREE which I think the alien FFI should be dealing with directly; I'm aware that there is probably still a division between the stream and alien/octet treatments and definitions of external formats, and I would think that fixing will make the rest of your patch much simpler. I agree, I think, that also pathnames need to be able to handle general characters rather than the restrictive base-char that is presently implemented, and I think I've even been convinced that a dynamic variable *pathname-external-format* is a sensible way to implement this: it can default to :utf-8 on darwin, (ansi-cp) on windows and some locale-dependent value under the other unixes. Thank you for developing your patch, in any case; I'm not comfortable with merging it directly, and I don't have the resources to develop sensibly on Windows, but I hope that the functionality you've developed will make it into SBCL CVS given a little more work. Cheers, Christophe |
From: Yaroslav K. <kav...@tu...> - 2006-03-10 21:22:34
|
Christophe Rhodes wrote: > Would it be possible to split this patch up into logical > self-contained pieces? Yes, of course! > I now have a mostly-working windows mingw > environment, and built sbcl CVS on it today, so potentially I could do > a very limited amount of merging. I am happy :) > However, my access to this > environment is limited to two hours a week, so I don't have time to > edit failing patches, or even ones that I don't like; additionally, > breaking it up into pieces will help us work out if there is something > systematic about failure to map our dynamic space in the place we want > it. > Ok, I have understood > Regarding the patch that you sent itself: I'm not happy with the > pathname stuff. I am happy that someone is looking at it, but I don't > think you've gone about it the right way, unfortunately. You have > introduced things like VECTOR->STRING and VECTOR->STRING&FREE which I > think the alien FFI should be dealing with directly; I'm aware that > there is probably still a division between the stream and alien/octet > treatments and definitions of external formats, and I would think that > fixing will make the rest of your patch much simpler. > Ok, but the majority of my functions depends on this encoding/decoding. Converting string to UCS-2 allien array and converting data from sap (or alien array) in UCS-2 encoding to string - only this is necessary for me. I shall be glad to similar conversion for the any encoding also :) > I agree, I think, that also pathnames need to be able to handle > general characters rather than the restrictive base-char that is > presently implemented, and I think I've even been convinced that a > dynamic variable *pathname-external-format* is a sensible way to > implement this: it can default to :utf-8 on darwin, (ansi-cp) on > windows and some locale-dependent value under the other unixes. > Hmm, I shall make converting base-string to string for pathanmes in the separate patch. I should limit it only for win32? And again sap(or alien array)<->string conversion is required > Thank you for developing your patch, in any case; I'm not comfortable > with merging it directly, and I don't have the resources to develop > sensibly on Windows, but I hope that the functionality you've > developed will make it into SBCL CVS given a little more work. > Patches follow this letter! Thanks for your nice work! And excuse me bad english. -- WBR, Yaroslav Kavenchuk. |
From: Yaroslav K. <kav...@je...> - 2006-03-21 10:28:30
Attachments:
alien-external-format.patch.gz
|
Christophe Rhodes wrote: > Regarding the patch that you sent itself: I'm not happy with the > pathname stuff. I am happy that someone is looking at it, but I don't > think you've gone about it the right way, unfortunately. You have > introduced things like VECTOR->STRING and VECTOR->STRING&FREE which I > think the alien FFI should be dealing with directly; I'm aware that > there is probably still a division between the stream and alien/octet > treatments and definitions of external formats, and I would think that > fixing will make the rest of your patch much simpler. This is part of patch for directly encoding c-string to string with *alien-external-format*. This patch demands addition of symbol <encoding>->STRING-SAP-REF-8 in the end of all corresponding lists from *external-format-functions*. It will approach? I shall search where strings are encoded in c-strings :) -- WBR, Yaroslav Kavenchuk. |
From: Yaroslav K. <kav...@je...> - 2006-03-21 11:39:15
Attachments:
alien-external-format.patch.gz
|
The full corrected version (without back encoding) |
From: David L. <da...@li...> - 2006-03-22 18:08:39
|
Hi, Quoting Juho Snellman (js...@ik...): > * Remove the MAP_FIXED flags also from the non-Linux implementations of > os_validate Done. > * Move the "addr != actual" check in the linux os_validate to the > callers that pass non-zero addrs > * Use os_validate instead of the raw mmap in validate.c Hmm, what I have done is to rename os_validate to os_validate_movable (without the check). A new function os_validate calls it and checks before returning. Is that OK? > And of course saving a core from relocated images needs to work. Yes, I had fixed that before putting up the first patch. > But other than the above, this looks committable. (It would be nice to > make the cheneygc dynamic spaces movable too, but it's orthogonal to > this patch, and at least from my point of view not a showstopper). Works now, at least on linux/ppc/cheneygc. Updated patch: http://www.lichteblau.com/blubba/relocate-3.diff Questions: It would be nice to check that relocation works in SBCL's test suite. Right now I am testing the patch manually using the TEST_START, _END environment variables, but obviously that should go away before committing the patch. Is there a clever way to make SBCL start up with parts of its dynamic space blocked? Also, what do you think about the "kludge"s in process_directory? Thanks for the review, d. |
From: Juho S. <js...@va...> - 2006-03-23 10:13:18
|
David Lichteblau <da...@li...> writes: > Works now, at least on linux/ppc/cheneygc. > Updated patch: http://www.lichteblau.com/blubba/relocate-3.diff Great! Thanks. > Questions: > > It would be nice to check that relocation works in SBCL's test suite. > Right now I am testing the patch manually using the TEST_START, _END > environment variables, but obviously that should go away before > committing the patch. Is there a clever way to make SBCL start up with > parts of its dynamic space blocked? LD_PRELOAD a .so that does a suitable mmap in its constructor function? > Also, what do you think about the "kludge"s in process_directory? The new ordering/directory constraints seem quite acceptable. It's not like we need to remain compatible with loads of existing software which generates SBCL-format core files ;-) But maybe the constraints should be explicitly checked in coreparse, just in case. -- Juho Snellman |
From: Yaroslav K. <kav...@je...> - 2006-03-23 10:56:21
|
David Lichteblau wrote: > Works now, at least on linux/ppc/cheneygc. > Updated patch: http://www.lichteblau.com/blubba/relocate-3.diff Where get relocate.c? In http://www.lichteblau.com/sb-heapdump-04.tgz? Thanks! -- WBR, Yaroslav Kavenchuk. |
From: David L. <da...@li...> - 2006-03-23 11:49:17
|
Hi, Quoting Yaroslav Kavenchuk (kav...@je...): > >Updated patch: http://www.lichteblau.com/blubba/relocate-3.diff > Where get relocate.c? In http://www.lichteblau.com/sb-heapdump-04.tgz? no, sorry. This should be the stripped-down version for the .diff: http://www.lichteblau.com/blubba/relocate.c And I forgot to mention that I didn't touch the os_relocate_movable() function in win-os.c. See the comment in front of it. d. |