racket runtime system debug build

[tori]

Hi,

I'm planning on studying the racket runtime (JIT, memory management) code. I'll be reading the  source code, in addition to which I wanted to build a racket system with debugs enabled, so that I can used "lldb" to track the execution as it happens.

I've used the following config to build the system. Can someone please let me know the right options or if I missed something? 

../configure CFLAGS=-g --prefix=SOME_DIR_ABS_PATH --enable-macprefix --enable-noopt

after installing, I see the following.

$ lldb bin/racket



(lldb) break set -n main

Breakpoint 1: no locations (pending).

WARNING:  Unable to resolve breakpoint to any actual locations.

(lldb) r

Process 24130 launched: '../refcode/racket/racket/src/build/bin/racket' (x86_64)

 

Welcome to Racket v6.2.900.10.
>

Thanks.

[tori]

I see that we have  --enable-backtrace option available. 

there are 2 binaries created in  $BUILD/racket/

1. racket3m 

2. racketcgc

are these standalone binaries for the racket interpreter using different GCs? I'm able to set breakpoints using these, but this is NOT interpreting any of the rkt source files. would appreciate if someone can point me to any docs, that help me the directory structure and design docs for the racket runtime and how to debug/understand the runtime.

Thanks.

[Matthew Flatt]

At Mon, 17 Aug 2015 06:54:12 -0700 (PDT), tori wrote:
> $ lldb bin/racket
> (lldb) break set -n main
> Breakpoint 1: no locations (pending).

Debugging will work better if you use "src/build/racket/racket3m",
instead of "racket/bin/racket". The version in the "build" directory
still has debugging information that has been stripped from the one
installed in "bin".

[Matthew Flatt]

At Mon, 17 Aug 2015 09:14:57 -0700 (PDT), tori wrote:
> I see that we have --enable-backtrace option available.

That's for enabling garbage-collector reference traces to help explain
why objects are retained by the GC. It's not about stack backtraces, so
it's probably not what you want.

> there are 2 binaries created in $BUILD/racket/
>
> 1. racket3m
> 2. racketcgc
>
> are these standalone binaries for the racket interpreter using different
> GCs?

Yes. Debugging with `racketcgc` is sometimes easier than with
`racket3m`, because C sources are converted (using `racketcgc`) to
create `racket3m`, and source-location tracking through that conversion
is approximate.

> I'm able to set breakpoints using these, but this is NOT interpreting
> any of the rkt source files. would appreciate if someone can point me to
> any docs, that help me the directory structure and design docs for the
> racket runtime and how to debug/understand the runtime.

A debugger like `lldb` or `gdb` cannot step through code from ".rkt".
At best, by disabling the JIT, you can step through the C code that
implements an interpreter of ".rkt" code --- but it's not so easy to
extract the current ".rkt" source location in that context.

When the JIT is enabled, you can step through machine code that
corresponds to ".rkt" code, but there's still no source correlation
within `lldb` or `gdb` (although there's a little bit of source
connection so that Racket can show its own backtraces for runtime
errors).