Re: [Sbcl-devel] [Sbcl-commits] master: Skip building standalone ldb for sb-safepoint

[Stas Boukarev]

Is a standalone ldb a good idea? Wouldn't it be better to have an entry point to ldb from sbcl.exe? Especially considering core/runtime mismatch you might not have the right ldb when you need it most.

On Thu, Oct 19, 2023 at 5:15 PM snuglas via Sbcl-commits <sbcl-c...@lists.sourceforge.net> wrote:

The branch "master" has been updated in SBCL:
       via  777d37a3fb7571162ea8628087bdafa4d0408a08 (commit)
      from  85d542f10abf860fe5881c678a0ed808db147cda (commit)

- Log -----------------------------------------------------------------
commit 777d37a3fb7571162ea8628087bdafa4d0408a08
Author: Douglas Katzman <do...@google.com>
Date:   Thu Oct 19 10:14:07 2023 -0400

    Skip building standalone ldb for sb-safepoint
---
 src/runtime/GNUmakefile | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/runtime/GNUmakefile b/src/runtime/GNUmakefile
index 7cfb0945e..d53448d37 100644
--- a/src/runtime/GNUmakefile
+++ b/src/runtime/GNUmakefile
@@ -90,7 +90,13 @@ OBJS = $(C_SRC:.c=.o) $(ASSEM_SRC:.S=.o) ../../tlsf-bsd/tlsf/tlsf.o

 LIBS = ${OS_LIBS} $(LDLIBS) -lm

-targets: $(TARGET) $(OBJTARGET) ldb sbcl.mk
+ifdef LISP_FEATURE_SB_SAFEPOINT
+LDB_TARGET =
+else
+LDB_TARGET = ldb
+endif
+
+targets: $(TARGET) $(OBJTARGET) $(LDB_TARGET) sbcl.mk

 LDB_OBJS = $(filter-out main.o runtime.o monitor.o save.o thread.o safepoint.o,$(OBJS))
 ldb: $(LIBSBCL)

-----------------------------------------------------------------------


hooks/post-receive
--
SBCL


_______________________________________________
Sbcl-commits mailing list
Sbcl-c...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-commits

[Douglas Katzman via Sbcl-devel]

On Thu, Oct 19, 2023 at 2:02 PM Stas Boukarev <stas...@gmail.com> wrote:

Is a standalone ldb a good idea?

Standalone ldb is able to inspect a crashed lisp produced by save_gc_crashdump from the ordinary ldb which can capture the dynamic space exactly as it exists at that instant, including page tables, mark bits, and thread stacks.  This allows changing some code in gencgc and rebuilding the C runtime, starting ldb in standalone mode, running a GC looking for invariant failures; and iterating on those steps until you can fix your problem. 

Wouldn't it be better to have an entry point to ldb from sbcl.exe?

That's just (sb-vm:ldb-monitor) isn't it?

 

[Stas Boukarev]

Not from lisp, but from C directly. Something like --ldb