X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=base-target-features.lisp-expr;h=7bd7caff6a787a24a4164978c96b3c5a4d71d4e9;hb=2ac72bb9dee580d01a1cb55fc72a5535ba6b9bd8;hp=50b732ebd47abacce9b535583d0776613f90e113;hpb=2230ea0c1765a95fd2aa0a8996b3555b93ba3745;p=sbcl.git

diff --git a/base-target-features.lisp-expr b/base-target-features.lisp-expr
index 50b732e..7bd7caf 100644
--- a/base-target-features.lisp-expr
+++ b/base-target-features.lisp-expr
@@ -216,12 +216,9 @@
 
  ;; low-level thread primitives support
  ;;
- ;; As of SBCL 0.8, this is only supposed to work in x86 Linux with
- ;; NPTL support (usually kernel 2.6, though sme Red Hat distributions
- ;; with older kernels also have it) and is implemented using clone(2)
- ;; and the %fs segment register.  Note that no consistent effort to
- ;; audit the SBCL library code for thread safety has been performed,
- ;; so caveat executor.
+ ;; As of SBCL 1.0.33.26, threads are part of the default build on
+ ;; x86oid Linux. Other platforms that support them include
+ ;; x86oid Darwin, FreeBSD, and Solaris.
  ; :sb-thread
 
  ;; lutex support
@@ -240,6 +237,11 @@
  ;; local storage.
  ; :restore-tls-segment-register-from-tls
 
+ ;; On some x86oid operating systems (darwin) SIGTRAP is not reliably
+ ;; delivered for the INT3 instruction, so we use the UD2 instruction
+ ;; which generates SIGILL instead.
+ ; :ud2-breakpoints
+
  ;; Support for detection of unportable code (when applied to the
  ;; COMMON-LISP package, or SBCL-internal pacakges) or bad-neighbourly
  ;; code (when applied to user-level packages), relating to material
@@ -261,6 +263,12 @@
  ;; increases core size by about 100kB.
  :sb-source-locations
 
+ ;; Record xref data for SBCL internals. This can be rather useful for
+ ;; people who want to develop on SBCL itself because it'll make M-?
+ ;; (slime-edit-uses) work which lists call/expansion/etc. sites.
+ ;; It'll increase the core size by major 5-6mB, though.
+ ; :sb-xref-for-internals
+
  ;; This affects the definition of a lot of things in bignum.lisp. It
  ;; doesn't seem to be documented anywhere what systems it might apply
  ;; to. It doesn't seem to be needed for X86 systems anyway.