[M3devel] recent m3gdb does not want to compile

[Rodney M. Bates]

Jay wrote:
> scripts/do-cm3-m3gdb.sh just cd's over to m3-sys/m3gdb and runs cm3.
>  
> m3gdb builds and seems to work fine for me.
>  
> Specifically, on AMD64_LINUX birch, I can both:
>  
> mkdir -p $HOME/obj/gdb
> cd $HOME/obj/gdb
> $HOME/dev2/cm3/m3-sys/m3gdb/gdb/configure && make
> gdb/gdb gdb/gdb
> break main
> r
>  
> and
>  
> cd $HOME/dev2/cm3/m3-sys/m3gdb
> rm -rf AMD64_LINUX
> cm3
>  
>  
> AMD64_LINUX/m3gdb AMD64_LINUX/m3gdb
> break main
> r
>  
>  
> I haven't tried with Modula-3 code and/or stabs.
>  
>  
> Updating from the 2005 6.4 release to a current 6.8 release is 
> probably advisable anyway.
>  
>  
> But again, um, er, could we maybe adapt the generated code so that 
> plain gdb is all anyone would need/want?
I don't think so.  There is ~ 20K lines of Modula-3-specific code in 
m3gdb, and I have tens of
pages of handwritten lists of more that ought to be done to make it a 
nice M3 debugger.
I think doing it all could easily double this.   The variable reference 
rules are different
from C/C++, for example, because of the link between a module and its 
exported
interface(s).

The global variable thing is just the tip of the iceberg.  For example, 
there is a whole lot
to making procedure calls and method calls work.  Ditto for nested 
procedures, which,
after several iterations, is broken again by the change to the newest 
gcc as the base for
the code generator, although it works somewhat.  Note that gdb provides 
no real
support for nested functions in C, even though gcc supports them as an 
extension to C.
Probably, they are little used in C.  I use them a lot in M3.

Then there are just all the language-specific formats for input and 
output values,
and expression syntax.  Plus, Modula-3, being a considerably 
higher-level language,
(at least optionally,) has a significant runtime system, and m3gdb needs 
to know \
quite a bit about that too.   Real arrays and open arrays also need 
support.  And
TEXT is a lot different.


There are also some significant differences between cm3 and the earlier 
compilers.
I have taken the position that support for the older ones should remain, 
along with
new stuff too.


What we should do, in addition to updating to newest gdb, is change from 
stabs to
dwarf2 debug info format, which is *much* richer in what it can 
express.  stabs was
something of a cobbled up mess to begin with, and the M3-specific 
extensions to it
only make it worse.  There's a lot of what has to be seen as very 
arbitrary stuff,
not really stabs,  wrapped inside of some of the character strings that 
stabs has. 
This change would require a significant amount of code in the compiler, 
as well
as in m3gdb.


Someday, it might also be nice to try to get the m3 changes rolled in to 
the stock
gdb.  This would require a serious commitment to maintain them there.  
Also, there
are some copyright assertions that DEC put in to some of the code that, 
I believe
were in violation of the GPL.   We would have to somehow get a 
determination that
the copyright ownership could be transferred to FSF, to their 
satisfaction.  All the
more difficult with DEC's identity having changed twice.  IANAL.
>  
>  
> Cygwin fork being so slow makes me want to optimize out such large 
> pieces as building gdb.
> Maybe I can figure out a way to speed up Cygwin fork some day...
>  
>  
>  - Jay
>  
>