From: <da...@ft...> - 2001-03-13 01:46:56
|
[telent.net is having hardware problems, hence alternate address while new MX records spread around the net] So I'm still having Fun With GC (the first 10% is 90% of the work, and the second 90% is another 90% of the work...) but I happened to notice the FIXME comment in interrupt_handle_pending (runtime/interrupt.c) /* FIXME: How come we unconditionally copy from pending_mask into * the context, and then test whether pending_signal is set? If * pending_signal wasn't set, how could pending_mask be valid? */ And the answer is - or appears to be - because interrupt_maybe_gc set it that way (look in the #ifndef __i386__ bit). We can't GC during a pseudo-atomic, so we set maybe_gc_pending=1 and arch_set_pseudo_atomic_interrupted(..) When we come out of pseudo_atomic we're marked as interrupted, so we call interrupt_handle_pending, which does the GC using the pending context (it needs a context so that it has registers to use as GC roots) then notices there's no actual interrupt handler to call, so doesn't. That's the second question answered, anyway. Why we still need to copy the pending_mask into the context given that we're now done with the context anyway, I couldn't say. Or maybe I'm just completely off the wall (it is, after all, late). Who's to say? -dan -- http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources |
From: <ade...@ya...> - 2001-06-14 03:07:08
|
(let ((*print-length* nil)=0D (*print-pretty* nil))=0D (print #S(...)))=0D produces=0D debugger invoked on condition of type TYPE-ERROR:=0D The value NIL is not of type (OR SINGLE-FLOAT DOUBLE-FLOAT RA= TIONAL).=0D =0D Error is in `src/code/target-defstruct.lisp', in function=0D `default-structure-print':=0D (and (not *print-readably*)=0D (>=3D index *print-length*)))=0D It should be=0D (and (not *print-readably*)=0D *print-length*=0D (>=3D index *print-length*)))=0D =0D Alexey Dejneka=0D =0D --=0D =F3=C5=C7=CF=C4=CE=D1 =D5=C4=C1=DE=CE=D9=CA =C4=C5=CE=D8 =C4=CC=D1 =D4=CF= =C7=CF, =DE=D4=CF=C2=D9 =DA=C1=D7=C5=D3=D4=C9 =D0=CF=DE=D4=D5 =CE=C1 =F1= =CE=C4=C5=CB=D3=C5!=0D =E2=C5=D3=D0=CC=C1=D4=CE=C1=D1, =D5=C4=CF=C2=CE=C1=D1 =C9 =C2=C5=DA=CF=D0= =C1=D3=CE=C1=D1 =D0=CF=DE=D4=C1 =CE=C1 http://www.yandex.ru=0D =0D |
From: William H. N. <wil...@ai...> - 2001-06-16 13:19:08
|
On Thu, Jun 14, 2001 at 07:06:50AM +0400, Alexey Dejneka wrote: > (let ((*print-length* nil) > (*print-pretty* nil)) > (print #S(...))) > produces > debugger invoked on condition of type TYPE-ERROR: > The value NIL is not of type (OR SINGLE-FLOAT DOUBLE-FLOAT RATIONAL). > > Error is in `src/code/target-defstruct.lisp', in function > `default-structure-print': > (and (not *print-readably*) > (>= index *print-length*))) > It should be > (and (not *print-readably*) > *print-length* > (>= index *print-length*))) Thank you. I've merged your fix into sbcl-0.6.12.35, just checked in. -- William Harold Newman <wil...@ai...> pending patches from sbcl-devel: none PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Rob M. <Rob...@ra...> - 2002-03-08 22:47:11
|
- (**current-segment** - ;; FIXME: I can't see why we have to use - ;; (MACROLET ((LOSE () (ERROR ..))) (LOSE)) - ;; instead of just (ERROR "..") here. - (macrolet ((lose () - (error "You can't use INST without an ~ - ASSEMBLE inside emitters."))) - (lose)))) Hmmn, SYMBOL-MACROLET on a special is a little twisted, and I guess other Lisps don't like it? And the macrolet/macroexpand of ..inherited-labels.. is a bit precious too, since we're defining a macro that we never have any intention of evaluating just to squirrel some info away in the lexical environment. In the old days the manly macro hackers had COMPILER-LET to do this sort of thing, but then ANSI took it away... Anyway, the reason for the rather peculiar LOSE local macro is to cause a compile-time ERROR if any reference to **current-segment** appears in the code without being shadowed by the correct definition. If you simply said (error ...) then the error would only happen at runtime. I think that what happened is that someone got burned by forgetting to use an ASSEMBLE form, and then some code quietly went into *the wrong segment*. This is not good, but the if the symbol macrolet had a different name than the special, then you would at least have gotten undefined variable error on the symbol macro reference. It appears that there is in fact no reason for the special binding of **current-segment**, and this is what should be flushed, not the symbol macrolet. If I am correct that INST, EMIT-LABEL, etc. are always called in the lexical scope of an ASSEMBLE, then the special can be dispensed with entirely. However, it is possible that somewhere someone is calling a function from a vop generator that calls INST, making use of the special binding. This is easily enough found by removing the special and looking for undefined var warnings, and easily enough fixed by passing the segment in and adding an ASSEMBLE. Referencing a special is, needless to say, more costly than a local, and the assembler is one of the more performance critical parts of the compiler. Does it make a big difference? You won't know without testing, and just timing an entire compile probably isn't going to give you enough signal-to-noise to see this effect. You have to time something like GENERATE-CODE. The difference may be not so big on an x86 as long as the code is compiled unsafe, since with 8 registers, it's probably on the stack already, so you've got one memory reference. Adding another to get the symbol only doubles it. Doing a boundp check also hurts. Rob |
From: Christophe R. <cs...@ca...> - 2002-03-09 12:52:30
|
On Fri, Mar 08, 2002 at 05:46:25PM -0500, Rob MacLachlan wrote: > Hmmn, SYMBOL-MACROLET on a special is a little twisted, and I guess other > Lisps don't like it? It's actually specifically forbidden by ANSI... "an error of type PROGRAM-ERROR is signalled." > Anyway, the reason for the rather peculiar LOSE local macro is to cause a > compile-time ERROR if any reference to **current-segment** appears in the > code without being shadowed by the correct definition. If you simply said > (error ...) then the error would only happen at runtime. I think that what > happened is that someone got burned by forgetting to use an ASSEMBLE form, > and then some code quietly went into *the wrong segment*. Ah, yes, of course! Thanks, that makes more sense now. > It appears that there is in fact no reason for the special binding of > **current-segment**, and this is what should be flushed, not the symbol > macrolet. If I am correct that INST, EMIT-LABEL, etc. are always called in > the lexical scope of an ASSEMBLE, then the special can be dispensed with > entirely. However, it is possible that somewhere someone is calling a > function from a vop generator that calls INST, making use of the special > binding. This is easily enough found by removing the special and looking > for undefined var warnings, and easily enough fixed by passing the segment > in and adding an ASSEMBLE. Yes, I thought of this possibility during the night (who says we can't be productive 24 hours a day...), but thanks for giving me a little more impetus into following it up. I'll report back as and when I've given it a spin. Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) |
From: Rudi S. <ru...@co...> - 2003-09-21 11:10:38
Attachments:
bug.lisp
|
Hi, The attached file is a reduced test case for a compile warning in portable allegroserve that started happening some time this month. Removing either of call-next-method or symbol-macrolet makes the symptoms go away, as does simplifying the class slot to hold a number instead of the structure (with accompanying changes to the index symbol-macro). Is anyone familiar with this area of sbcl and could point me to relevant files? Thanks, Rudi ; compiling DEFMETHOD FROB (BUFFERED-STREAM-MIXIN): ; file: /Users/rudi/Source/bug.lisp ; in: DEFMETHOD FROB (BUFFERED-STREAM-MIXIN) ; (DEFMETHOD FROB ; ((STREAM BUFFERED-STREAM-MIXIN)) ; (SYMBOL-MACROLET ((INDEX #)) ; (SETF INDEX 0)) ; (CALL-NEXT-METHOD)) ; --> PROGN SB-PCL::LOAD-DEFMETHOD SB-PCL::LOAD-DEFMETHOD LIST* ; --> SB-INT:NAMED-LAMBDA FUNCTION MACROLET ; --> SB-PCL::FAST-LEXICAL-METHOD-FUNCTIONS ; --> SB-PCL::BIND-FAST-LEXICAL-METHOD-MACROS MACROLET ; --> SB-PCL::BIND-LEXICAL-METHOD-FUNCTIONS SB-PCL::CALL-NEXT-METHOD-BIND LET ; --> FLET SB-PCL::WITH-REBOUND-ORIGINAL-ARGS LET SB-PCL::BIND-ARGS LET* ; --> SB-PCL::PV-BINDING SB-PCL::PV-BINDING1 SB-PCL::PV-ENV LET LET ; --> SB-PCL::GET-SLOTS-OR-NIL BLOCK WHEN COND IF ; ==> ; (COND) ; ; caught WARNING: ; The binding of ARRAY is not a SIMPLE-VECTOR: ; NIL |
From: Christophe R. <cs...@ca...> - 2003-09-23 11:47:08
|
Rudi Schlatte <ru...@co...> writes: > The attached file is a reduced test case for a compile warning in > portable allegroserve that started happening some time this month. > Removing either of call-next-method or symbol-macrolet makes the > symptoms go away, as does simplifying the class slot to hold a number > instead of the structure (with accompanying changes to the index > symbol-macro). Is anyone familiar with this area of sbcl and could > point me to relevant files? Here's a patch (X marks the spot; similar is wanted in instance-write-internal and instance-boundp-internal). The warning appears to be genuine, but warning about PCL-internal code, not user code. The attached patch probably doesn't do wonders to performance, though it might be relatively neutral; better might be to write a GET-SLOTS-OR-LOSE function and use that in the appropriate place. (defmacro instance-read-internal (pv slots pv-offset default &optional type) (unless (member type '(nil :instance :class :default)) (error "illegal type argument to ~S: ~S" 'instance-read-internal type)) (if (eq type :default) default (let* ((index (gensym)) (value index)) `(locally (declare #.*optimize-speed*) (when (null ,slots) (bug "Argh, SLOTS is NULL!")) ; X (let ((,index (pvref ,pv ,pv-offset))) (setq ,value (typecase ,index ,@(when (or (null type) (eq type :instance)) `((fixnum (clos-slots-ref ,slots ,index)))) ,@(when (or (null type) (eq type :class)) `((cons (cdr ,index)))) (t +slot-unbound+))) (if (eq ,value +slot-unbound+) ,default ,value)))))) Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Christophe R. <cs...@ca...> - 2003-11-30 15:21:45
|
Rudi Schlatte <ru...@co...> writes: > The attached file is a reduced test case for a compile warning in > portable allegroserve that started happening some time this month. > Removing either of call-next-method or symbol-macrolet makes the > symptoms go away, as does simplifying the class slot to hold a number > instead of the structure (with accompanying changes to the index > symbol-macro). Is anyone familiar with this area of sbcl and could > point me to relevant files? Sorry for the delay. I've merged what I think is a fix for this (with what I think is minimal collateral damage) into sbcl-0.8.6.17. Be aware that I'm not at all sure that my fix is right, so please shout if you observe any weird clos-related behaviour. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Brian M. <bma...@cs...> - 2004-05-28 15:45:35
Attachments:
sbcl-darwinbuild.patch
|
Howdy all, In followup to earlier discussion of SBCL / Darwin building, the attached patch should make everything OK by backing the optimization off to O2 (not O3). It also cleans up the linker flags, many of which were extraneous. -- Brian Mastenbrook http://www.cs.indiana.edu/~bmastenb/ bma...@cs... |
From: Nikodemus S. <tsi...@cc...> - 2004-05-30 20:05:56
|
On Fri, 28 May 2004, Brian Mastenbrook wrote: > In followup to earlier discussion of SBCL / Darwin building, the attached > patch should make everything OK by backing the optimization off to O2 (not > O3). It also cleans up the linker flags, many of which were extraneous. Thank you, this has been merged in 0.8.10.65. Cheers, -- Nikodemus "Not as clumsy or random as a C++ or Java. An elegant weapon for a more civilized time." |
From: Mike T. <mi...@pa...> - 2006-02-14 23:09:18
|
Hi all. Thanks for porting SBCL to Windows. I have successfully built SBCL from the 0.9.9 source tarball using the 0.9.9 binary provided under MSYS with MinGW32 gcc 3.4.5. While trying to add Win32 support for run-program to the released 0.9.9 source I had some bizarre trouble with my newly modified "src/runtime/run-program.c". During the build with the _modified_ file, it is overwritten _before_ gcc is called with an error message as follows: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Microsoft (R) File Expansion Utility Version 5.1.2600.0 Copyright (C) Microsoft Corp 1990-1999. All rights reserved. No destination specified for: ./src/runtime/run-program.c. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D which in turn causes gcc to barf as follows: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D .... gcc -g -Wall -O3 -mno-cygwin -I. -c -o purify.o purify.c purify.c: In function `ptrans_boxed': purify.c:522: warning: implicit declaration of function `bcopy' gcc -g -Wall -O3 -mno-cygwin -I. -c -o regnames.o regnames.c gcc -g -Wall -O3 -mno-cygwin -I. -c -o run-program.o run-program.c run-program.c:1: error: syntax error before "File" run-program.c:1:47: too many decimal points in number make: *** [run-program.o] Error 1 make: Leaving directory `/c/lang/source/sbcl/sbcl-0.9.9/src/runtime' =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I'm finding the SBCL build system a little obscure at this early stage in my exposure to it so I thought I'd ask the experts. Any ideas? Cheers Mike Thomas. |
From: Rudi S. <ru...@co...> - 2006-02-14 23:23:55
Attachments:
PGP.sig
|
On 15. Feb 2006, at 00:09, Mike Thomas wrote: > While trying to add Win32 support for run-program to the released > 0.9.9 > source I had some bizarre trouble with my newly modified > "src/runtime/run-program.c". > > During the build with the _modified_ file, it is overwritten _before_ > gcc is called with an error message as follows: > > ====================================================================== > Microsoft (R) File Expansion Utility Version 5.1.2600.0 Copyright (C) > Microsoft Corp 1990-1999. All rights reserved. > > No destination specified for: ./src/runtime/run-program.c. > ====================================================================== My guess is that cygwin/msys binaries are after Windows' expand.exe in your path. Does it work if you comment out the line tools-for-build/canonicalize-whitespace in make.sh? Cheers, Rudi |
From: Juho S. <js...@ik...> - 2006-02-14 23:24:11
|
<mi...@pa...> wrote: > During the build with the _modified_ file, it is overwritten _before_ > gcc is called with an error message as follows: make.sh calls tools-for-build/canonicalize-whitespace to remove tabs and trailing whitespace from .lisp and .c files. This is done by calling "expand". Unfortunately on Windows "expand" names some sort of obsolete backup utility, which destroys the file. You can either: * Not write tabs into the file in the first place * Comment out the call to canonicalize-whitespace in make.sh -- Juho Snellman |
From: James Y K. <fo...@fu...> - 2007-04-30 04:22:31
|
Looks like sbcl doesn't compile on sparc: From http://sbcl.static.net/buildbot/sbcl-linux-sparc/builds/5/step- compile/1: > /usr/lib/gcc/sparc-linux-gnu/4.1.2/collect2 --eh-frame-hdr -m > elf32_sparc -Y P,/usr/lib -export-dynamic -dynamic-linker /lib/ld- > linux.so.2 -relax -o sbcl /usr/lib/gcc/sparc-linux-gnu/ > 4.1.2/../../../../lib/crt1.o /usr/lib/gcc/sparc-linux-gnu/ > 4.1.2/../../../../lib/crti.o /usr/lib/gcc/sparc-linux-gnu/4.1.2/ > crtbeginS.o -L/usr/lib/gcc/sparc-linux-gnu/4.1.2 -L/usr/lib/gcc/ > sparc-linux-gnu/4.1.2 -L/usr/lib/gcc/sparc-linux-gnu/ > 4.1.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib alloc.o > backtrace.o breakpoint.o coreparse.o dynbind.o funcall.o gc- > common.o globals.o interr.o interrupt.o largefile.o monitor.o os- > common.o parse.o print.o purify.o pthread-futex.o pthread-lutex.o > regnames.o run-program.o runtime.o save.o search.o thread.o time.o > util.o validate.o vars.o wrap.o sparc-arch.o linux-os.o sparc-linux- > os.o cheneygc.o sparc-assem.o ldso-stubs.o -ldl -lm -lgcc --as- > needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as- > needed /usr/lib/gcc/sparc-linux-gnu/4.1.2/crtend.o /usr/lib/gcc/ > sparc-linux-gnu/4.1.2/../../../../lib/crtn.o > > interrupt.o: In function `handle_trap': > /home/sbclbot/sparc/sbcl-linux-sparc/build/src/runtime/interrupt.c: > 1344: undefined reference to `arch_handle_single_step_trap' > collect2: ld returned 1 exit status > make[1]: *** [sbcl] Error 1 This code in params.lisp: > ;; Stepper actually not implemented on Sparc, but these constants > ;; are still needed to avoid undefined variable warnings during sbcl > ;; build. > single-step-around > single-step-before) And this in interrupt.c (which was changed in "1.0.4.13: refactor trap handling"): > #ifdef trap_SingleStepAround > case trap_SingleStepAround: > case trap_SingleStepBefore: > arch_handle_single_step_trap(context, trap); > break; > #endif appear to be in conflict. James |
From: Christophe R. <cs...@ca...> - 2007-04-30 12:06:06
|
James Y Knight <fo...@fu...> writes: > Looks like sbcl doesn't compile on sparc: I think in fact it might not compile on anything that's not a PPC or an x86oid, as the lack of arch_handle_single_step_trap (even though the traps are defined) seems to be common. (It's possible that something in genesis could save the other platforms, but I can't see it; I've only verified this on sparc/linux, though). There are several possible fixes: * don't export the SINGLE-STEP-{AROUND,BEFORE}-TRAP symbols on platforms that don't use them, then genesis won't #define them; * write null arch_handle_single_step_trap() definitions on currently failing platforms; * conditionalize the lisp code which uses single-step-around or single-step-before, so that the symbols don't need to be defined on platforms where single-stepping doesn't work; * (my preferred solution) implement single-stepping on all platforms. So, firstly, am I right that the build is hosed on minority platforms? And secondly, what needs to be done? (Aside: the powerpc code in call.lisp which seems to be dealing with this looks like it could benefit from using the LOAD-SYMBOL-VALUE macro) Cheers, Christophe |
From: Thiemo S. <th...@ne...> - 2007-04-30 12:43:19
|
Christophe Rhodes wrote: > James Y Knight <fo...@fu...> writes: > > > Looks like sbcl doesn't compile on sparc: > > I think in fact it might not compile on anything that's not a PPC or > an x86oid, as the lack of arch_handle_single_step_trap (even though > the traps are defined) seems to be common. (It's possible that > something in genesis could save the other platforms, but I can't see > it; I've only verified this on sparc/linux, though). It does not build on mips for that reason. > There are several possible fixes: > > * don't export the SINGLE-STEP-{AROUND,BEFORE}-TRAP symbols on > platforms that don't use them, then genesis won't #define them; > > * write null arch_handle_single_step_trap() definitions on currently > failing platforms; > > * conditionalize the lisp code which uses single-step-around or > single-step-before, so that the symbols don't need to be defined on > platforms where single-stepping doesn't work; > > * (my preferred solution) implement single-stepping on all platforms. The last one is what I had a stab at, but I probably won't have the time to get it finished soon. Thiemo |
From: Juho S. <js...@ik...> - 2007-04-30 13:02:20
|
Christophe Rhodes <cs...@ca...> writes: > There are several possible fixes: > > * don't export the SINGLE-STEP-{AROUND,BEFORE}-TRAP symbols on > platforms that don't use them, then genesis won't #define them; > > * write null arch_handle_single_step_trap() definitions on currently > failing platforms; This seems like the best one of the kludgy "let's not implement single stepping everywhere" fixes. > * conditionalize the lisp code which uses single-step-around or > single-step-before, so that the symbols don't need to be defined on > platforms where single-stepping doesn't work; > > * (my preferred solution) implement single-stepping on all platforms. > > So, firstly, am I right that the build is hosed on minority platforms? Right, this was due to the trap handling refactoring that Nikodemus did. > And secondly, what needs to be done? Just the following for Alpha, Mips and Sparc. * Flesh out the stub step-instrument-before-vop. Just load a symbol value, and trigger a trap if it's not NIL. * Implement the "around" instrumentation in the call vop. Basically with code similar to the step-instrument-before-vop, but also needs to encode the TN offset for the register that contains the fdefn or function that's being called. * Implement arch_handle_single_step_trap. This should dig out the TN from the trap code and call handle_single_step_trap. * On Sparc, sb-di::handle-single-step-around-trap probably also needs to handle the different format of the fdefn objects (which store the raw address of the function, not the function object itself). In theory, that should be it, and those vops should be easy to write. (Especially now that you mentioned LOAD-SYMBOL-VALUE). Just need someone with access to these platforms. In practice, there will almost certainly be further complications for other platform idiosyncracies which I didn't manage to hit with the x86oids or ppc. -- Juho Snellman |
From: Christophe R. <cs...@ca...> - 2007-05-01 10:48:36
|
Juho Snellman <js...@ik...> writes: >> And secondly, what needs to be done? > > Just the following for Alpha, Mips and Sparc. > > * Flesh out the stub step-instrument-before-vop. Just load a symbol value, > and trigger a trap if it's not NIL. > * Implement the "around" instrumentation in the call vop. Basically > with code similar to the step-instrument-before-vop, but also needs > to encode the TN offset for the register that contains the fdefn or > function that's being called. > * Implement arch_handle_single_step_trap. This should dig out the TN > from the trap code and call handle_single_step_trap. > * On Sparc, sb-di::handle-single-step-around-trap probably also needs > to handle the different format of the fdefn objects (which store the > raw address of the function, not the function object itself). > > In theory, that should be it, and those vops should be easy to > write. (Especially now that you mentioned LOAD-SYMBOL-VALUE). Just > need someone with access to these platforms. In practice, there will > almost certainly be further complications for other platform > idiosyncracies which I didn't manage to hit with the x86oids or ppc. There was one wrinkle, which I eventually realised after a fair amount of single-stepping and looking (manually, sigh) at register contents: the allocation of the sap in handle_single_step_trap() doesn't update the dynamic_space_free_pointer/reg_ALLOC correctly on non-gencgc platforms, because the fake_foreign_function_call() hasn't occurred yet: causing the corruption visible in <http://paste.lisp.org/display/40560>. (Side note: I'm not sure how it could have been quite so systematic as I saw yesterday, with the failure mode being exactly the same each time, but my gut tells me that I'm right anyway). So, the patch for sparc is at <http://www-jcsu.jesus.cam.ac.uk/~csr21/ss-sparc.diff>. However, before it gets merged, we probably need to think about how to restore the goodness implied by the comment in handle_single_step_trap() that I've deleted, without bringing back the badness of heap corruption in cheneygc that goes with it. Cheers, Christophe |
From: Rosanna B. <gu...@ac...> - 2007-05-29 14:15:15
|
<html> <body> <p>Greetings.<br> Would you be interested in a home job that allows you to earn up to $10000 per month? No start up fees, no envelope stuffing nonsense.<br> <br> We proudly present Amato Logistics Co. Ltd.<br> <br> The job we offer will not affect your present career, it will only take a small part of your time. <br> The only things you need to have to start running your business with our company are reliable Internet/E-mail access and checking/savings bank account. <br> And of course your decency and willingness to earn.<br> <br> The first vacancy is Transfer manager:<br> The nature of the job is payment processing. <br> It is related to online banking operating the funds from either our company or our partners to designated bank account approved by our <br> manager keeping specified money transaction fee as a commission for your services (usually between $150 to $500, no less than $150 per transfer).<br> <br> You will receive the funds which our customers/resellers send directly to you and forward it to us or our agents (less your commission)via one of chosen money transfer agencies.<br> The job is rather simple and you won't need any special knowledge to become our partner, though we do require that you are able to act on a very short notice. <br> We can afford to pay such a decent commission only because we keep our customers happy with our promptness.<br> <br> And the second is Shipment manager.<br> The job we offer is related to mail. It is an easy part time job that doesnt require leaving your main occupation. <br> You will be receiving mail and packages for our clients, either repack them or ship them further out following our managers instructions. <br> <br> <br> For those who look for career opportunities its a chance of becoming a part of our team in the future (based on your performance), <br> team in which you will be highly respected and decently rewarded - just think about this! We will be hoping to hear from you soon. <a href="mailto:yl...@bu...">yl...@bu...</a><br> <br> <br> If you would like to get our application form please email us with your request. No fees are asked, just leave your contact details: "random e-mail"<br> <br> Write us to: <a href="mailto:yl...@bu...">yl...@bu...</a><br> <br> We would appreciate your continued patronage and get in touch with you soon. Thank you!</p> </body> </html> |
From: markhaniford <mar...@gm...> - 2008-04-12 23:47:36
|
Thanks for your work on SBCL William |
From: William H. N. <wil...@ai...> - 2001-03-14 13:48:25
|
On Tue, Mar 13, 2001 at 01:45:40AM +0000, da...@ft... wrote: > [telent.net is having hardware problems, hence alternate address while > new MX records spread around the net] > > So I'm still having Fun With GC (the first 10% is 90% of the work, and > the second 90% is another 90% of the work...) but I happened to notice > the FIXME comment in interrupt_handle_pending (runtime/interrupt.c) > > /* FIXME: How come we unconditionally copy from pending_mask into > * the context, and then test whether pending_signal is set? If > * pending_signal wasn't set, how could pending_mask be valid? */ > > And the answer is - or appears to be - because interrupt_maybe_gc set > it that way (look in the #ifndef __i386__ bit). We can't GC during a > pseudo-atomic, so we set maybe_gc_pending=1 and > arch_set_pseudo_atomic_interrupted(..) When we come out of > pseudo_atomic we're marked as interrupted, so we call > interrupt_handle_pending, which does the GC using the pending context > (it needs a context so that it has registers to use as GC roots) then > notices there's no actual interrupt handler to call, so doesn't. > > That's the second question answered, anyway. Why we still need to > copy the pending_mask into the context given that we're now done with > the context anyway, I couldn't say. OK, thank you, I've merged your explanation into the comment in 0.6.11.14 (just checked in). -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |