[M3devel] m3gdb broken

[Daniel Alejandro Benavides D.]

Hi all:
well, all that said, is it possible, but how many checks would be needed to all those errors, I perhaps think the best tool at hand is but to run undependently of the platform ESC, at least to catch the most common RT errors for now, but gcc as a backend is enough optimizable and also enough conservative to catch at compile time warnings you see as possible M3CG errors, in Modula-3 safe code there are not explicity needed in ESC terms but in UNSAFE ones, so the most RTError you want to catch as m3gdb exceptions would be advisable in foreseeable future, perhaps making some of them implementable at ESC level, but to check for  those that are that in the RTCollector, RTException and the RTThread specially perhaps simpler ones in ESC terms but important, and in the M3CG memory handling, exception, and threads too, obviously in the RTType, even if those are not safely checked RTError should have some correspondent there and that is it must be caught in the
 M3CG before it can also generate bad codes, if so, also possible improved UNSAFE RTTypeSRC information to accomplish that perhaps a better but not limited to type checking and exceptions handled of both safe and UNSAFE code.
Thinking in what's on the market there are recent reports in Logic Analyzer of embedded software-hardware verification environments for circuit analysis, such kind of automation tests are deployable even at the try and so we may get that, although this Embedded software Arena, but even at that level, cost effective knowing of the logic synthesis theories errors they want to be rid of, that is, is more important to shape some circuit level checks before product is deployed since may things depended on that too.
We could seemingly adopt that strategic objective too, detect most of the common errors in those areas, also a nice RTTypeSRC interface for unsafe type code patterns.
Perhaps some of this work is already done implemented in Modula-3 VM backend Quest abstract machine, since  it has nice constructs and basically same stack architecture and machine but with additional ability to support for separating sound and unsound modules. 
I think in this way the margin of RT errors will be diminished by at least by some volume bounded by the amount of each type inference in the checker, specially some of the ones in RTTypeSRC information portion plus desired good to watch at least some code modularity level sound handled in such code, so some of them that must be catched and, something it isn't right now for M3CG will not, but just because of correspondent MODULEs so it can be translated sound and caught in better CG compiler time in other representation and then generate code to its RT binary structures perhaps some may want for that too. Also that could be generous in terms of debugging both Quest level and m3gdb source level.
Thanks in advance 


--- El vie, 1/4/11, Jay K <jay.krell at cornell.edu> escribió:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] m3gdb broken
Para: "Mika Nystrom" <mika at async.caltech.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 1 de abril, 2011 22:24




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.


 - 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
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110402/8fdf079c/attachment-0002.html>