[M3devel] m3gdb broken

[Rodney M. Bates]

On 04/01/2011 08:26 PM, Jay K wrote:
> I really tried not to break anything in the wierdo stubs/m3gdb stuff.
>
>
> The work I have been doing to properly declare types is I believe disabled currently.
>
>

Hmm, I looked at a sample of stabs output for the same program, produced by the
release and head compilers.  In the head, all of the stabs type information is
missing, including the type definitions and the references to them.  This may
be enough to explain all the breakage in m3gdb I have seen.

I see another small change, but it is something that, I think, m3gdb already
adapts to, and, as in the release version, was weird anyway.

> As types become more correct, things start breaking.
> Either because the optimizer is more aggressive, or because more sanity checks
> can be done by the compiler, and we don't give it particularly good trees.
>
>
> In most things I've looked it, it's really not any mystery what is wrong with our trees btw.
> It's not really generally the fault of gcc being obscure or changing.
> Though perhaps to some extent that is true.
> Or, there is the rare case, like where Modula-3 uses div/mod primitives that are not
> accessible from C source, and therefore bugs in them go undetected.
> It's more generally clearly not great stuff in cm3cg.
> The main bad thing is that field access is done by just adding to base pointers and casting away.
>
>
> Note that stabs is not supported on Darwin.
> Nor as I recall HP-UX/HPPA64.
> All the more reason to no do things this way.
>
>
> Note furthermore that discussion here is often confused.
> Really no particular debug-info generation code should be cm3cg.
> In our part -- m3cg/parse.c
> Neither stabs nor dwarf nor coff nor anything else.
>
>
> The right approach is to build an intermediate form with reasonably good types.
> The backend handles it from there, whatever debug-info format is requested on the command line.
>
>
> This also enables using stock/current gdb, instead of hacked up/old gdb.
>
>
> I made no visible progress upgrading our fork of gdb.
> I'd rather just have it go away.
>
>
> I understand, that custom information is being tunneled through to m3gdb.
> But that "custom information" is largely just basic type information, that any decent
> C compiler/debug-info/debugger can handle.
> Someone should investigate if we really pass stuff through that can't be well represented
> in gcc's type information.
> For example: sub ranges? sets? enums? packed?
> Some higher level description of "methods" (really -- whatever C++ does should suffice;
> if it exposes a vtable pointer in the debugger, so be it; if it doesn't, that's perhaps nice too.)
>
>
> At some point the new type information was really breaking stuff so I think I disabled it.
> The system is kind of incomplete and fragile and the way forward is not always easy
> or possible in small steps. :(
>
>
> - Jay
>
>
>  > Date: Fri, 1 Apr 2011 12:43:25 -0500
>  > From: rodney_bates at lcwb.coop
>  > To: m3devel at elegosoft.com
>  > Subject: Re: [M3devel] m3gdb broken
>  >
>  > 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
>  > compiler.
>  >
>  > 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/
>  > ci
>  > > 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
>  > >