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). -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/20150817162416.B016D6501CC%40mail-svr1.cs.utah.edu. For more options, visit https://groups.google.com/d/optout.
