<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
I really tried not to break anything in the wierdo stubs/m3gdb stuff.<br><br><br>The work I have been doing to properly declare types is I believe disabled currently.<br><br><br>As types become more correct, things start breaking.<br>Either because the optimizer is more aggressive, or because more sanity checks<br>can be done by the compiler, and we don't give it particularly good trees.<br><br><br>In most things I've looked it, it's really not any mystery what is wrong with our trees btw.<br>It's not really generally the fault of gcc being obscure or changing.<br> Though perhaps to some extent that is true.<br> Or, there is the rare case, like where Modula-3 uses div/mod primitives that are not<br> accessible from C source, and therefore bugs in them go undetected.<br>It's more generally clearly not great stuff in cm3cg.<br>The main bad thing is that field access is done by just adding to base pointers and casting away.<br><br><br>Note that stabs is not supported on Darwin.<br>Nor as I recall HP-UX/HPPA64.<br>All the more reason to no do things this way.<br><br><br>Note furthermore that discussion here is often confused.<br>Really no particular debug-info generation code should be cm3cg.<br> In our part -- m3cg/parse.c<br>Neither stabs nor dwarf nor coff nor anything else.<br><br><br>The right approach is to build an intermediate form with reasonably good types.<br>The backend handles it from there, whatever debug-info format is requested on the command line.<br><br><br>This also enables using stock/current gdb, instead of hacked up/old gdb.<br><br><br>I made no visible progress upgrading our fork of gdb.<br>I'd rather just have it go away.<br><br><br>I understand, that custom information is being tunneled through to m3gdb.<br>But that "custom information" is largely just basic type information, that any decent<br>C compiler/debug-info/debugger can handle.<br>Someone should investigate if we really pass stuff through that can't be well represented<br>in gcc's type information.<br>For example: sub ranges? sets? enums? packed?<br>Some higher level description of "methods" (really -- whatever C++ does should suffice;<br>if it exposes a vtable pointer in the debugger, so be it; if it doesn't, that's perhaps nice too.)<br><br><br>At some point the new type information was really breaking stuff so I think I disabled it.<br>The system is kind of incomplete and fragile and the way forward is not always easy<br>or possible in small steps. :(<br><br><br> - Jay<br><br><br>> Date: Fri, 1 Apr 2011 12:43:25 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] m3gdb broken<br>> <br>> I have looked at this a bit. I do not get this symptom on LINUXLIBC6,<br>> using the Cartesian product of release/head for m3gdb and the compiler.<br>> <br>> However, I see a lot of broken stuff that used to work. In all the cases<br>> I have seen, it correlates to debugging code compiled by the head compiler,<br>> while the release and head versions of m3gdb make no difference to the<br>> symptoms in anything I have tried.<br>> <br>> I believe Jay had started updating the m3gdb in head to use a newer gdb.<br>> I am not sure how far that got. Its source code is vastly different, and<br>> most of the other language support in gdb has been ripped out.<br>> <br>> There is quite a lot of change in the stabs info generated by the two<br>> compiler versions. The existing way for a long time has been that this<br>> is constructed during the first pass over the input to cm3cg, before<br>> anything other than initial tree building is done. This is a very<br>> limited strategy, because cm3cg can change things later, and this will<br>> not be reflected in the stabs info.<br>> <br>> Debugging anything involving static links has been broken for a long time,<br>> because tree-nested.c in cm3cg does some very convoluted stuff with the<br>> way static ancestor activation records are accessed, and I have not been<br>> able to see an easy way to get stabs info to reflect it.<br>> <br>> I have thought for a long time that we really need to go to a version<br>> of dwarf for debug info. stabs is very limited, and there is a lot of<br>> info in the stabs output that is not really stabs, it's just kludgily<br>> coded values crammed inside various fields of stabs that the compiler<br>> and m3gdb both agree on (well, they used to.)<br>> <br>> Maybe the current head cm3cg can be fixed, but I know Jay has made big<br>> changes in where type information is actually developed, so it may not<br>> be worth it. After all the work I have done on this to get m3gdb to where<br>> it was, I am unenthusiastic about a bunch more work just to get back to<br>> where we were. I have long lists of improvements to make to m3gdb, and<br>> it's hard to go back that way. And, It's all in C :-(.<br>> <br>> If I put much effort into fixing m3gdb and its support in cm3cg at this<br>> point, it will probably be a rework to use dwarf. That is likely a big<br>> job too, but at least more rewarding and likely to lead to better m3gdb<br>> function in the end.<br>> <br>> For now, it you want a working m3gdb, you really have to use the release<br>> compiler.<br>> <br>> On 03/05/2011 12:05 PM, Mika Nystrom wrote:<br>> > Hi m3devel,<br>> ><br>> > I don't know what's happened here. m3gdb used to work, and work fairly<br>> > well (never perfectly, but...). Now I'm trying to debug a program and<br>> > I get the following:<br>> ><br>> > (m3gdb) break Main.m3:65<br>> > Debug info for file "Main.mc" not in stabs format<br>> > (m3gdb)<br>> ><br>> > The system/architecture is AMD64_FREEBSD but I've seen this problem on other<br>> > systems too.<br>> ><br>> > Everything is from the CVS head.<br>> ><br>> > Main was compiled as follows, says cm3 -commands:<br>> ><br>> > 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/<br>> ci<br>> > 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<br>> ><br>> > I'm not even sure where to begin looking. Is it a configuration issue,<br>> > something broken in the compiler, or what?<br>> ><br>> > I fear m3gdb is essentially useless at the moment.<br>> ><br>> > Mika<br>> ><br> </body>
</html>