[M3devel] recent m3gdb does not want to compile

[Elmar Stellnberger]

  As I still have the old PM3/EZM3 in use I do welcome the continuing
support for that kind of old compiler tech. Besides all these advanced
issues I still simply wonder on how to compile a current m3gdb. As
described earlier ./configure does not even find the standard utilities
like ar, as, etc. although they are on path:

../gdb/configure --target i686-pc-linux-gnu
checking for i686-pc-linux-gnu-ar... no
checking for i686-pc-linux-gnu-as... no

  I will be happy as soon as I can print global integer variables. I can
convert Text-vars to char* although that will cause little extra output.
The thing is that even some elder m3gdb that I still have a compilate of
can not print global vars for any kind of reason (perhaps it would be
necessary to update the codegen).

Rodney M. Bates schrieb:
> 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
>>  
>>
> 
>