[M3devel] m3gdb broken

Rodney M. Bates rodney_bates at lcwb.coop
Fri Apr 1 19:43:25 CEST 2011

I have looked at this a bit.  I do not get this symptom on LINUXLIBC6,
using the Cartesian product of release/head for m3gdb and the compiler.

However, I see a lot of broken stuff that used to work.  In all the cases
I have seen, it correlates to debugging code compiled by the head compiler,
while the release and head versions of m3gdb make no difference to the
symptoms in anything I have tried.

I believe Jay had started updating the m3gdb in head to use a newer gdb.
I am not sure how far that got.  Its source code is vastly different, and
most of the other language support in gdb has been ripped out.

There is quite a lot of change in the stabs info generated by the two
compiler versions.  The existing way for a long time has been that this
is constructed during the first pass over the input to cm3cg, before
anything other than initial tree building is done.  This is a very
limited strategy, because cm3cg can change things later, and this will
not be reflected in the stabs info.

Debugging anything involving static links has been broken for a long time,
because tree-nested.c in cm3cg does some very convoluted stuff with the
way static ancestor activation records are accessed, and I have not been
able to see an easy way to get stabs info to reflect it.

I have thought for a long time that we really need to go to a version
of dwarf for debug info.  stabs is very limited, and there is a lot of
info in the stabs output that is not really stabs, it's just kludgily
coded values crammed inside various fields of stabs that the compiler
and m3gdb both agree on (well, they used to.)

Maybe the current head cm3cg can be fixed, but I know Jay has made big
changes in where type information is actually developed, so it may not
be worth it.  After all the work I have done on this to get m3gdb to where
it was, I am unenthusiastic about a bunch more work just to get back to
where we were.  I have long lists of improvements to make to m3gdb, and
it's hard to go back that way.  And, It's all in C :-(.

If I put much effort into fixing m3gdb and its support in cm3cg at this
point, it will probably be a rework to use dwarf.  That is likely a big
job too, but at least more rewarding and likely to lead to better m3gdb
function in the end.

For now, it you want a working m3gdb, you really have to use the release

On 03/05/2011 12:05 PM, Mika Nystrom wrote:
> Hi m3devel,
> I don't know what's happened here.  m3gdb used to work, and work fairly
> well (never perfectly, but...).  Now I'm trying to debug a program and
> I get the following:
> (m3gdb) break Main.m3:65
> Debug info for file "Main.mc" not in stabs format
> (m3gdb)
> The system/architecture is AMD64_FREEBSD but I've seen this problem on other
> systems too.
> Everything is from the CVS head.
> Main was compiled as follows, says cm3 -commands:
> gcc -gstabs+ -m64 -fPIC -z origin -Wl,--warn-common -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib  -Wl,--fatal-warnings -z now -Bsymbolic -L/usr/local/lib -o sstubgen  _m3main.o Main.mo /home/mika/t/mscheme/sstubgen/AMD64_FREEBSD/libsstubgen.a /home/mika/t/mscheme/schemereadline/AMD64_FREEBSD/libschemereadline.a /home/mika/t/mscheme/schemesig/AMD64_FREEBSD/libschemesig.a /home/mika/t/calarm/m3readline/AMD64_FREEBSD/libm3readline.a /home/mika/t/calarm/sx/AMD64_FREEBSD/libsx.a /home/mika/t/mscheme/modula3scheme/AMD64_FREEBSD/libmodula3scheme.a /home/mika/t/rdwr/AMD64_FREEBSD/librdwr.a /home/mika/t/mscheme/AMD64_FREEBSD/libmscheme.a /home/mika/t/cit_util/AMD64_FREEBSD/libcit_util.a /usr/local/cm3/pkg/netobj/AMD64_FREEBSD/libm3netobj.a /usr/local/cm3/pkg/tcp/AMD64_FREEBSD/libm3tcp.a /usr/local/cm3/pkg/patternmatching/AMD64_FREEBSD/libpatternmatching.a /home/mika/t/mscheme/scheme-lib/AMD64_FREEBSD/libscheme-lib.a /usr/local/cm3/pkg/libbuf/AMD64_FREEBSD/liblibbuf.a /home/mika/t/
>   t_common/AMD64_FREEBSD/libcit_common.a /usr/local/cm3/pkg/set/AMD64_FREEBSD/libset.a /home/mika/t/rdwrreset/AMD64_FREEBSD/librdwrreset.a /usr/local/cm3/pkg/m3tk/AMD64_FREEBSD/libm3tk.a /usr/local/cm3/pkg/m3tk-misc/AMD64_FREEBSD/libm3tk-misc.a /usr/local/cm3/pkg/libm3/AMD64_FREEBSD/libm3.a /usr/local/cm3/pkg/m3core/AMD64_FREEBSD/libm3core.a -lm -lcrypt -lssl -L/usr/local/lib -lintl -lreadline
> I'm not even sure where to begin looking.  Is it a configuration issue,
> something broken in the compiler, or what?
> I fear m3gdb is essentially useless at the moment.
>       Mika

More information about the M3devel mailing list