[M3devel] recent m3gdb does not want to compile

[jay.krell at cornell.edu]

Those are not necessarily errors. It looks for platform-ar and then  
ar. Plain ar is fine for native builds. You probably should build  
outside the source tree. It is strongly recommended at least for gcc.

  - Jay (phone)

On Jun 11, 2009, at 12:29 PM, Elmar Stellnberger <estellnb at yahoo.de>  
wrote:

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