I want to know if there are any tools/tool-kits which aid in building source level debuggers for domain specific languages ? (I work on a proprietary DSL, which doesn't have any tools and sometimes debugging will become difficult, so, if in case there are any such tool-kits, wanted to try)

  • 2
    If your DSL compiler is targeting JVM or .NET, it is fairly easy to emit debug information alongside with bytecode (line numbers, variable names, etc.).
    – SK-logic
    Nov 11, 2012 at 23:39

2 Answers 2


This is an indirect answer to your question. In 1982 I wrote the first commercial C source-level debugger, CDB (also possibly the first remote debugger, kernel debugger, and multi-process/multi-thread debugger). I initially wrote it because I needed it (the only other option was sdb on a VAX, except I didn't have a VAX, and sdb sucked planetoids). This situation was in perfect harmony with The Cathedral and the Bazaar's first rule: Every good work of software starts by scratching a developer's personal itch.

Since you are the person with the itch, you are also quite possibly the best person to embark on this journey.

The following things are needed to create a source-level debugger:

  1. A way of starting & stopping execution without killing the target process. Given your environment this may be trivial or it might be a deal killer. ptrace(2) was the key in UN*X-land.
  2. A way of querying the current execution state of the target process. e.g Program Counter (PC) (or equivalent), Stack Pointer (SP), registers, and data/instruction memory. Like #1, trivial or deal killer.
  3. A way of mapping the PC => file:line and vice versa—file:line => PC. This is critical because it's what differentiates a source-level debugger from an assembly-level debugger (or whatever the equivalent would be in your world). Compiled languages often generate additional symbols in the .o file that makes this mapping possible (although not always in a straightforward way).
  4. A way of inserting and removing a breakpoint. How this is accomplished can vary wildly across environments. It needs to be done in such a way as to be as non-disruptive of the execution state as possible so that you can avoid the debugger equivalent of the Heisenberg uncertainty principle—i.e. the bug reacts differently depending on where you set the break. Note: You can't avoid this with timing-related bugs.

Once you have these things nailed down, your actual command processing should be pretty straightforward. For example, when you hit a breakpoint, you read the PC, map it to file:line and display that line (normally with +/-5 lines of context). For a stack trace, you get the SP and print each frame using the additional symbol info that gives local variable offset from the SP, etc., etc.

What commands make sense will be driven by how you (and your future users) think when using the language. Things that make sense for one language are nonsense when applied to another. For example, given the C declaration struct FOO *pfoo;, it's nice if typing *pfoo at the command prompt gives you a formatted dump of the structure pointed to. This might not make sense when debugging something like SQL, but there are often analogues.

The Devil is in the Details on these 4 items, so let me know if you would like any more help offline. My email is in my profile.


It's not 100% what you're looking for, but you can have a look at Xtext and this thread. But obviously that might not help you if your in-house DSL isn't Xtext-based...

  • my DSL is not Xtext based, its old legacy C code with hand rolled lexer, parser.
    – Ani
    Nov 12, 2012 at 9:44
  • @vyom, are you generating C code in your compiler? Then you can use #line directive. If debugging is really important, it should be relatively easy to switch from C code generation to LLVM code generation, and then you can stuff all the debugging metadata in IR.
    – SK-logic
    Nov 12, 2012 at 10:18
  • @SK-logic I don't recall #line from my C days, but there was a __LINE__ directive. However, this was GCC-specific.
    – haylem
    Nov 12, 2012 at 17:21
  • @SK-logic No, its not generating c code, its generating some interim data structures which are used later (all the code is in C, is what I meant)
    – Ani
    Nov 13, 2012 at 3:30
  • @vyom, do you mean it is an interpreter? If so, debugging is trivial since all the evaluation is under your control anyway.
    – SK-logic
    Nov 13, 2012 at 7:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.