[M3devel] m3gdb broken

[Rodney M. Bates]

On 04/01/2011 10:24 PM, Jay K wrote:
> The question is, can they be well represented within gcc's usual trees/types/debug-info
> for good experience in stock gdb.
> Enums for example -- yes, I had them working.
>
> Subranges -- what should the experience be?
> For example, when I use debuggers, I use expression evaluation involving assignment
> to set values. Should the debugger catch attempts to assign out of range values?
> Or are subranges just integers with a certain number of bits and that is it and that suffices?
> I understand the runtime does more precise checks than just bit-width.
>
> sets -- I can see this being....are they just an integer or an array of integers?
> Or higher level? I can see this being poor...unless unless.. gcc maybe already
> had good support for Pascal? Maybe Ada has a similar feature?
> Ada does actually look like Modula-3 to a large extent!
>
> Consider also that on Darwin, none of this stuff works at all.
> So even sets as integers or arrays of integers would be much better than current.
>
> One has to read some of the gcc documentation, browse tree.h, tree.def, etc.,
> learn what is well representable.
>
> One shouldn't just completely ignore the significant infrastructure and just
> tunnel all the information through in a custom way that stock gdb is completely ignorant of.
>

There is no way stock gdb can possibly provide anything remotely similar to the
support it gives other languages, just by providing it with better debug info.
Every one of the languages already supported by stock gdb (C, C++, Objective C,
Pascal, Ada, Java, Fortran, and Scheme come to mind) have significant amounts
of language-specific code, comparable to what m3gdb adds for Modula-3 support.

Some categories of language-specific code include: name demanglers, expression
parsers, expression evaluators, identifier lookups, characteristics of builtin
types, and value printers.  You can find anecdotal cases of types, operators,
and their syntax that are equivalent to another language, but this is highly
incomplete.  Value notations also differ.  Semantics of same-looking operators
can be significantly different.  The dot is a good example.  Not even Pascal
nor Ada are the same as Modula-3.

Interpretation of memory is also highly language dependent.  There are significant
differences in runtime representation of seemingly equivalent types and other
stuff.  Modula-3's TEXT, for example, is represented unlike any of the other
languages.  Heap objects have distinct ways of showing allocation status, GC
info, open array sizes for differing dimensionalities, and just the plain
allocated object type.  The method dispatching mechanism is distinct.

Actually, this stuff is really compiler-dependent, not just language-dependent.
There are significant differences between pm3/friends and cm3, and occasional
smaller differences between versions thereof.  m3gdb recognizes many of these
and adapts.  Ditto for some of the differences in thread and GC implementations.

Some procedures have hidden parameters that show up in the type info, but do
not appear in source code calls.  The rules for these are fairly conditional,
on both the procedure signature and on the target OS.  It is difficult for a
debugger user to even know when, where, and of what type these need to be to
supply them explicitly to make such a call, and as I recall, in some cases
impossible to supply some of the needed values, even with full knowledge.
In contrast, m3gdb allows typing procedure and method calls as they would
appear in source code, and supplies the hidden parameters as needed.

Assigning procedures to variables and parameters and calling through them
also have unique runtime representations.   As of the gdb the current m3gdb
is based on, no stock gdb language handles up-level addressing.

Much of this is working in the current m3gdb, or was until recently.  Most
of what isn't is documented as work to do.

>
> - Jay
>
>  > To: jay.krell at cornell.edu
>  > CC: m3devel at elegosoft.com
>  > Subject: Re: [M3devel] m3gdb broken
>  > Date: Fri, 1 Apr 2011 19:42:33 -0700
>  > From: mika at async.caltech.edu
>  >
>  > Jay K writes:
>  > ...
>  > >But that "custom information" is largely just basic type information=2C tha=
>  > >t any decent
>  > >C compiler/debug-info/debugger can handle.
>  > >Someone should investigate if we really pass stuff through that can't be we=
>  > >ll represented
>  > >in gcc's type information.
>  > >For example: sub ranges? sets? enums? packed?
>  >
>  > Subranges, sets, and enums certainly used to be shown in a "friendly" way
>  > by m3gdb.
>  >
>  > Mika