gdb & Mercury (was: live range splitting)

[Fergus Henderson <fjh at cs dot mu dot oz dot au>]

This originated on the gcc list.  I'm cross-posting to the gdb
and mercury-developers lists.

On 29-Jan-2001, dewar@gnat.com <dewar@gnat.com> wrote:
> <<For the Mercury front-end, inhibiting optimizations because they might
> break gdb seems like a very bad idea, since gdb is in most cases
> pretty useless for ordinary Mercury developers.  The main problem is
> that gdb doesn't know how to print out Mercury data structures.
> >>
> 
> Two comments.
> 
> 1. You could certainly make GDB Mecury data structure aware, as we have
> for GNAT. (we are working hard on getting these patches checked into the
> main gdb tree ASAP).

It would certainly be *possible*.  The question is whether the large
amount of effort required to do so would be worth it.  Since gdb
doesn't understand Mercury's nondet procedures, merely fixing it to
understand Mercury data structures still wouldn't be satisfactory.

I suspect that getting gdb to handle Mercury data structures will be
quite difficult, because of two aspects of Mercury which AFAIK are not
present in any of the languages that gdb currently supports:

	1. Tagged pointers.

		The Mercury compiler represents discriminated unions
		using the low bits of word-aligned pointers as tag
		bits.

	2. Parametric polymorphism.

		Mercury supports parametric polymorphism with shared
		code (unlike e.g. C++ templates).

		In the code that we generate, the *type* of one
		parameter can depend on the *value* of another
		parameter.

Furthermore, mdb supports a `retry' command, which allows you to
restart a function call after it just has returned.
This feature is so useful that it is considered almost essential.
gdb doesn't support this, and adding it would be a non-trivial task.

Finally, the Mercury compiler has a number of different back-ends.
The GCC back-end is just one of those.  It makes more sense for us to
work on a debugger that will support all our different back-ends, or
at least as many as possible, rather than working on which will only
support the GCC back-end.  The advantage of using gdb is that work
done on it is amortized over different languages, but for us it may
make better sense to amortize over different back-ends.

> 2. Even if that is not done, it is quite wrong to think that gdb is
> not usable. A very common debugging technique is to write debug
> callable routines that write out results at an appropriate level
> of abstraction (e.g. when debugging the gcc backend, you do not
> dump raw tree structures, you use the appropriate debug routines).

I have used that technique when debugging the Mercury compiler.
Indeed the Mercury standard library provides a routine that will
print out any value, given the value and the appropriate type descriptor.
However, figuring out the type descriptors by hand is very hard,
even for me, and if you get it wrong the result is a seg fault,
which generally means you have to restart debugging from the start
of the program.  I would not want to recommend this technique to
ordinary Mercury programmers.  `mdb' is much much easier to use.

> <<was.  Instead, we have our own debugger `mdb', which uses our own
> format of debug information that we put in the executable as ordinary
> read-only static constants (i.e. .rodata).  We plan to adapt mdb to
> work with the GCC back-end version of the Mercury compiler.
> >>
> 
> Surely it would be much better to use an appropriate Dwarf-2 section.
> You don't want to unconditionally load debug data.

That would only be portable to systems that use Dwarf-2.  Putting the
debug info in ordinary read-only static constants is more portable.

With demand loading, the cost of this is not so bad.  And you only pay
it when you compile with debugging enabled.  Actually our debugging
scheme has some other costs which are worse.  But note that for
debugging you want to inhibit tail recursion and sibling call
optimization, so performance of Mercury programs compiled with
debugging enabled is never going to be great anyway.

P.S. If you want to know more about the Mercury debugger, there's a paper
"The implementation technology of the Mercury debugger" on our web site
at <http://www.cs.mu.oz.au/mercury/information/papers.html>.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.