Re: debugging translated code, was Is Assembler

> How do you insert debug metadata on the HLL level into your binary in such
> setup ? It seems to me your debuginfo will contain C linenumbers, typedata
> etc. IOW, how do you debug in your HLL this way?


The first question is do you want to be debugging with a C debugger?
If you just want to support breakpoints in the code and inspecting of
low-level values, a C debugger may be good enough and #line directives
are all you will need.


However, unless you language is close to C, the chances are that the
expression evaluation facilities of a C debugger will be inadequate.
You are better off building an interpreter for that. With careful
design and a little luck, the IL you designed to represent your
language within the compiler can be used as the basis for the
interpreter. An interpreter often makes a fine debugger.


Still, even with a good interpreter, it is not always one's best
debugging tool, despite it's popularity as such. Your better (imo)
debugging tools are ones that take you to a higher level, such as
assertions or type checkers that find inconsistencies in your code,
and simliar items. Those tools may add code (e.g. assertions,
profilers, trace generatore) into your HLL or its translation. Or,
they may work on the HLL source itself such as type checkers,
equivalence checkers, etc.


By the way, the trace (or log) generator is a very useful tool. It
basically instruments your code with tracing or logging statements
that capture where the program was and what it was doing to a file (or
other kind of store). The trace or log is then often replayed by a
separate tool--this can even look like a traditional debugger.
However, it might use a display more suited to your application area.
For example, in circuit design, the waveform viewer is a popular
presentation for values changing over time. A good debugger interface
for a circuit designer thus is a waveform viewer, which can then map
transitions in the waves back to the parts of the circuit that the
waves are associated with.


Similarly, if I were working on sorting algorithms, I might like my
viewer to be an animation of the sorting progress that you see on some
web sites. I might like a similar kind of animation if I were doing a
process like Gaussian elimination.


What you need to build to do that kind of visualization can at some
level be integrated with a standard C-level debugger, but the C level
debugger is not likely the key driver.


So, what kind of debugger did we build for our Verilog compiler that
emitted C? Well, we built an interpreter. We built a waveform viewer
that could work off of dump files (called VCD files in the Verilog
community) and which could also be used in the interpreter. We built
a way for the interpreter to integrate and run C compiled versions of
the application and extract the relevant values in the C model--that
turned our interpreter into a normal "debugger". We built a GUI
interface that made certain things pretty and/or simiplifed the
outputs to get rid of clutter. We added support for some checking
facilities that were associated but not in the core language (OVL
assertions for instance). We also added some "lint" type support to
the compiler, to find common misuses that weren't strict errors, but
did indicate flaws in the users' code. We even found a way to
integrate the code with running in the underlying debuggers
(codeview/gdb) for times we thought the generated code was the
problem.


Evenutally, we built a run-time differencer, where you could take two
versions of the program and say which values should be the same in
both copies and run them with logs and breakpoints on the
discrepancies. That turned out to be a particularly good tool, since
much of hardware design is done with "golden" or reference models and
alternate implementations that try to achieve the same results but use
different methods (or at a different level of abstraction).


How much time did we spend worrying about the interface to the low
level deubggers? Probably some, but not very much--it was only for
the compiler developers use and we could deal with small errors or
inconsistencies in what it did. Again, we spent the time on things
that would make the end users life better, higher level tools. The
low-level debugger was not part of that suite. If the users needed
that, it was a mark of failure on our part.


Note, that nowhere in this post did I recommend trying to shoehorn
your HLL metadata into a form suitable for the C-level debugger.
There are tims when that is appropriate, but it isn't on the initial
list. It comes later, if it comes at all.


If you think at the C level, your eventual tool will tend to be at
that level. If you want to work on an HLL, focus on the HLL.


More opinions,
-Chris


******************************************************************************
Chris Clark Internet: christopher.f.clark@compiler-resources.com
Compiler Resources, Inc. or: compres@world.std.com
23 Bailey Rd Web Site: http://world.std.com/~compres
Berlin, MA 01503 voice: (508) 435-5016
USA fax: (978) 838-0263 (24 hours)
------------------------------------------------------------------------------

Return to the comp.compilers page.
Search the comp.compilers archives again.