Re: Live range splitting in new allocator

[dewar at gnat dot com]

<<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).

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 really think it would be better for you to put in the effort of
making gdb Mercury aware, it is well set up for this kind of adaptation.

<<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.