[M3devel] recent m3gdb does not want to compile

[Jay]

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?

 

 

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
 
> From: jay.krell at cornell.edu
> To: rodney.m.bates at cox.net
> Date: Wed, 10 Jun 2009 20:13:55 -0700
> CC: m3devel at elegosoft.com; estellnb at yahoo.de
> Subject: Re: [M3devel] recent m3gdb does not want to compile
> 
> Do they have any field names at all? Can m3gdb see them? I suspect no 
> to both. The struct is not TOO odd.
> 
> - Jay (phone)
> 
> On Jun 10, 2009, at 7:20 PM, "Rodney M. Bates" 
> <rodney.m.bates at cox.net> wrote:
> 
> > Peter Eiserloh has recently gotten it to build on AMD64_LINUX,
> > using the do-cm3-m3gdb.sh script. You should try that method.
> >
> > Unfortunately, it is not recognizing executables and dynamic
> > libraries. I have looked at this a bit, and the problem looks to
> > be in the bfd library, which is stock from gdb. m3gdb is derived
> > from gdb 6.4, which is by now quite old. gdb maintainers are about
> > to make a new release, I think 6.9. I am in the throes of moving
> > house now, but am getting odd bits of time to look at this.
> > I have been thinking for some time that it is about time to update
> > m3gdb to a later gdb. For one thing, gdb now has some reverse
> > debugging support, which would be very nice for Modula-3 too.
> > I have done it two or three times, and I believe Tony has done it
> > at least once. It takes a fair amount of work. But it should be
> > possible to get the current m3gdb working on AMD64 without going
> > to that much trouble. Maybe just some updated source files from
> > bfd will do the trick.
> > Jay is right about global variables. You will have a very hard time
> > finding them using stock gdb. They are located in a record with a
> > funny compiler-generated name and have funny compiler-mangled
> > field names. I'm not sure you can get them even if you know these.
> >
> >
> >
> >
> > Elmar Stellnberger wrote:
> >> For any kind of reason recent m3gdbs refuse to compile at me:
> >>
> >> ../gdb/configure
> >> ...
> >> checking for x86_64-unknown-linux-gnu-ar... no
> >> checking for ar... ar
> >> ...
> >>
> >>
> >>> which ar
> >>>
> >> /usr/bin/ar
> >>
> >> setting --bindir to /usr/bin or /usr does not help.
> >> full error log: see attachement
> >>
> >> Should I compile m3gdb towards 32bit on an x86_64 platform if the
> >> m3build I am using is 32bit?
> >>
> >> Besides this I am in wonder why a plain gdb can not access global
> >> Modula-3 variables using PM3/EZM3 although I have specified -gstabs 
> >> in
> >> m3config/src/COMMON:
> >> ASM = ["as","--32","-gstabs","-o"] % Assembler
> >> DEBUG_FLAG = "-gstabs" % debugging info
> >> BDEBUG_FLAG = "-gstabs" % debugging info
> >> LDEBUG_FLAG = "-gstabs"
> >>
> >> i.e.
> >>
> >>> gdb -batch --directory=
> >>>
> >> --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info
> >> variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls
> >>
> >>
> >>> grep myglobal smbls -> nothing found
> >>>
> >>
> >>
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090611/658540b5/attachment-0002.html>