On 10 April 2012 02:24, Peter Keller <psilord@...> wrote:
(Adding sbcl-devel to the mix, because there are a couple of people
who may have smart things to say who don't necessarily follow -help.)
> What are some tricks I can do to get gdb and SBCL to play together nicely?
> I often get the "continuing with fingers crossed" and whatnot even before
> I get up to a prompt in SBCL.
One core trick is building SBCL --with-ud2-breakpoints (check the
exact feature name, that's from memory): otherwise SBCL uses SIGTRAP
(int3) for things like type-errors, which is liable to confused gdb as
it uses SIGTRAP for its own breakpoints. This changes SBCL to use
SIGILL instead.
> What signals should I ignore, is there a nice way to get a backtrace through
> the lisp function calls as I unwind through them when starting from a C
> stack frame, etc, etc, etc.
SIGSEGV, SIGILL/SIGTRAP (see above), are the bare minimum.
For threads you want to give SBCL SIGPIPE as well, and if timers or
profiling is going on, SIGALRM and SIGPROF.
The the C function lisp_backtrace spits a lisp backtrace to stdout,
but it is probably far from ideal for yor purposes out of the box.
> An example of something like this when debugging with C#'s runtime and
> gdb is (in .gdbinit):
>
> ########################################
> handle SIGXCPU SIG33 SIG35 SIGPWR nostop noprint
>
> define mono_bt
> select-frame 0
> set $i = 0
> while ($i < $arg0)
> set $foo = (char*) mono_pmip ($pc)
> if ($foo)
> printf "#%d %p in %s\n", $i, $pc, $foo
> else
> frame
> end
> up-silently
> set $i = $i + 1
> end
> end
> ########################################
>
> Is there a similar thing for sbcl to poke around a map of text segment
> addresses to internal SBCL calls?
Cheers,
-- Nikodemus
|