<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>Ps we don't even have m3gdb for all systems e.g. Darwin, and the Windows debuggers are much better than anything I've seen on Unix. On these systems intermediate C would improve debugging much. Though Darwin gdb I've also been improving.<br><br>Also you seem to confuse C name mangling with what Modula-3 does. They are quite different. C only mangles things with linkage, for linking reasons, not for debugging information. Locals, parameters, record fields: no mangling. C code analogous to what Modula-3 allows would survive with everything being extern C, no name mangling.<br><br>In both cases as I understand, an effective hack to tunnel information through systems not quite designed/extended to suit.<br><br>What we have is flawed. What I favor is flawed. But differently.<br><br> - Jay/phone<br><br>> Date: Sat, 28 Aug 2010 14:15:02 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] additional CVS repositories for additional gcc forks?<br>> <br>> <br>> <br>> Jay K wrote:<br>> > <br>> >> There is no way a debugger that has no Modula-3 awareness is going to provide<br>> >> a Modula-3-like view. The operators will have C spellings and C semantics,<br>> > <br>> > <br>> > How many operators do people use in a debugger?<br>> > <br>> > I use very few. Partly because for a long time I used a debugger<br>> > with a great gui and an awful expression evaluator.<br>> > <br>> > <br>> > Still, I use basically only "+" "->" "*" (dereference) and "=" for assignment.<br>> > Sometimes multiplication and subtraction.<br>> > I agree it would be nice if all the C debuggers would be lenient about "->" vs. ".".<br>> > That would unify Modula-3, Java, C#, C, C++.<br>> > Except where C++ has an operator-> overload. But operator overload<br>> > is an area where.. tangent... C++ is a great language..my compiler implements<br>> > it well..but my debugger, my editor, plain text search.. can't cope with it.<br>> > Modula-3, C#, Java run afoul of plain text search too -- anything with prevalent "scoped names".<br>> > In C you get Window_Init, File_Open, etc. never just Init or Open.<br>> > How do you search for calls to operator+ in C++? For a certain type?<br>> > In C, except for the builtin types, they'd be unique function names.<br>> > Anyway, tangent over.<br>> > <br>> > <br>> > + is the same in the various languages.<br>> > <br>> > I think "=", ":=", "==" are the main problem.<br>> > You might try a compare and accidentally to an assignment.<br>> > <br>> > <br>> >> The syntax will be strictly C.<br>> > <br>> > Almost the same.<br>> > <br>> > <br>> > > The display of values will be C.<br>> > <br>> > Almost the same.<br>> <br>> On the strength of your comments, I rest my case.<br>> <br>> > <br>> > Also if you have a particularly good C compiler/debugger, we could do<br>> > #define AND && <br>> > #define OR || <br>> > <br>> > <br>> > getting you back those two operators, which I rarely use in a debugger.<br>> > <br>> > <br>> > > TEXT won't work in any reasonable way at all.<br>> > <br>> > Sure it might.<br>> > In Visual Studio you can write little addins to help the debugger display stuff.<br>> > I believe there is a small builtin "language" or I believe you can write actual code.<br>> > In Windbg you can write little plugins. You could provide like !m3.text.<br>> > I don't know if you can tell the debugger ahead of time how to custom display types.<br>> > I don't know if gdb has a story here.<br>> > Still, one might imagine a *small* patch to gdb.<br>> <br>> All of which is just different ways of providing a debugger with proper Modula-3 support.<br>> <br>> > <br>> > <br>> > > Demangling names in the compiler's debug output would make them look nice, but then the Modula-3<br>> > > type info would be lost, and output formats would lose.<br>> > <br>> > <br>> > Um, you think maybe this stuff was done the wrong way in the first place?<br>> > That the names shouldn't be mangled in the first place?<br>> > I strongly suspect so. Other systems don't depend on this.<br>> > (Yes, I know about C++ name mangling, and even though it does something similar,<br>> > that's a trick for the linker and now how debug information works. It for<br>> > in the absence of debug information, among other reasons.)<br>> > <br>> <br>> I think it could be done a lot better if switching to a better debug info format.<br>> stabs may have been the best option around at the time it was done. And I don't<br>> know if Modula-3's structural type equivalence rules could be supported any better<br>> without the uid's.<br>> <br>> But there will still have to be name mangling to get a standard linker to work,<br>> with just about any language. Stock gdb does what it does in part because it<br>> has builtin demanglers for the various languages it supports. It chooses the<br>> appropriate demangler dynamically. It would be a pretty ugly user interface if<br>> it didn't.<br>> <br>> > There is "naturally" type information you get just by building up decent gcc trees.<br>> > Ditto for intermediate C code.<br>> > For a while you know, every record is a void* or just has a size, and all the type information<br>> > is buried in the names. This is questionable. I'm sure it has some advantages.<br>> > You can describe things maybe not easily described in C.<br>> > e.g. Subranges?<br>> > And then our code in m3gdb is probably very portable, in that, I think, we just ferry along<br>> > some strings, from our code to our code, and we can decipher them the same in all systems.<br>> > I think, I'm not sure, there is like no dependence on the vagaries of coff, dwarf, etc., and<br>> > what they can or cannot represent. However there is a dependency on stabs being available.<br>> > It is not for example available on HP-UX.<br>> > <br>> > <br>> > Furthermore the lack of correct type information, apart from stabs, causes problems.<br>> > For some targets the backend wants accurate type information to pass records by value.<br>> > I again/still think we should probably not rely on the backend for this anyway.<br>> > We should probably make a copy and pass a pointer to it, kind of like m3x86 does.<br>> > <br>> <br>> Certainly, a back end needs type information for code generation. That won't do much to<br>> help a debugger that is oblivious to the source language.<br>> <br>> > <br>> > > Things that use pointers at the machine level can never know whether the pointers<br>> > > point to a single value or an array, and if the latter, with what bounds.<br>> > <br>> > <br>> > C programmers can cope with that. Can't we?<br>> <br>> Look at the security advisories. Buffer overflow, buffer overrun, buffer overflow, ...<br>> over and over. Almost all of them are buffer overruns. But that's a tangent too.<br>> <br>> > And..I admit.. I don't know what our machine level mapping looks like.<br>> > Do we pass a pointer and a size as two parameters? Or a small record with pointer/size by value?<br>> > <br>> <br>> If it's a fixed array, its all in the static type, which the stabs (as extended for Modula-3)<br>> info conveys. If it's an open array, there is runtime dope: a pointer to the zero-th array<br>> element, followed by a shape, which is just a list of words giving the NUMBER of each dimension.<br>> The dimension count is statically known. generally passed by reference, although it is never<br>> altered. For heap-allocated arrays, it's located right in the heap object, at the beginning,<br>> making the pointer redundant. For Formal parameters, if the actual doesn't already have the<br>> needed dope, it is constructed at runtime by code at the call site. This works for, e.g.,<br>> passing a fixed array or a SUBARRAY to a formal that is open.<br>> <br>> BTW, this is another thing a debugger has to know about to either pass, display, or alter<br>> open array values. Perhaps Dwarf is sophisticated enough that it could just be encoded in<br>> Dwarf, but certainly not in stabs. (Well, we could probably cobble up yet another stabs<br>> extension, but that would still require specialized debugger support.)<br>> <br>> > <br>> > The debugger need not be a full blown Modula-3 interpreter.<br>> > <br>> > <br>> >> Probably the worst thing will be calls. They just don't work without the debugger<br>> >> having knowledge of a lot of stuff. There are extra hidden parameters, method<br>> >> calls, passing procedure-typed parameters with environments, calling the same,<br>> >> the three modes of Modula-3, etc. I consider calls in debugger commands very<br>> >> valuable.<br>> > <br>> > <br>> > I use calls very rarely.<br>> > I'm not super keen on running some of my code when otherwise my code is all frozen<br>> > and some of it is misbehaving. I know this is partly me.<br>> > <br>> > <br>> > Even so, generally you only call certain functions that put there for use from a debugger, right?<br>> > Like gcc's debug_node or such?<br>> > And they tend to not be fancy?<br>> <br>> I regularly type a debugger call to rexecute something that I just stepped over, not knowing whether<br>> the problem I am looking for would occur inside the procedure or not. Reverse debugging in the newest<br>> gdb could provide an alternative, but I am hearing that the necessary recording costs ~ n*10 slowdown.<br>> <br>> I also do it as an easy way to test some parameter combination. Kind of like having an interpreter for<br>> the language. And I do it with fancy procedures that format some elaborate data structure in a readable,<br>> high-level way, which is, I think, what you meant. Sometimes a *lot* of effort.<br>> <br>> <br>> > <br>> > And the extra parameters..debugger would complain about missing them, programmer would figure it out?<br>> <br>> Before I got call support working, I found there were many calls I could not make work at all. Either<br>> I couldn't figure out what was needed (This amounts, in part, to manually reading stabs), or there<br>> was no way to supply what was needed in a debugger command. Also, on method calls, there was no way<br>> to figure out where it would dispatch to, even when you could locate all the possible overrides in all<br>> the subtypes, in all the source files of the closure. Language-specific support can take care of this,<br>> when done completely. m3gdb is a long way from there now, but it helps a lot.<br>> <br>> > <br>> > <br>> > I'm not saying there aren't drawbacks here.<br>> > But there are also major advantages.<br>> > There are major costs and drawbacks to our current approach.<br>> > We have a ton of extra code.<br>> > Which I don't think we are well equipped for.<br>> > Maybe Tony is. Maybe someone else is. I'm not.<br>> > <br>> > <br>> > Partly, I'll admit, anything I write, I am much more able to maintain.<br>> > Or, another lazy angle, anything smaller is easier to maintain.<br>> > <br>> > <br>> > In gcc we have a large code base. It takes me a long time to get just slightly up to speed on it.<br>> > We have several nagging problems with it. Maybe I just need to look at the C front end more.<br>> > Or read tree.h. I don't know.<br>> > <br>> > <br>> > 4.5.1 doesn't work with SPARC32_SOLARIS/SOLgnu/SOLsun. <br>> > 4.3.5 maybe not either. <br>> > A few optimizations I have turned off for 4.5.1 because they cause problems. Including inlining. <br>> > Maybe I just need to debug more. <br>> > Apple and OpenBSD each maintain their own forks. So that, *sort of but not really*, triples things.<br>> > (now, they are all highly related, so it doesn't) So far we don't have the OpenBSD fork.<br>> > But for example 4.5.1 doesn't have the OpenBSD/powerpc stuff quite. And there is a small OpenBSD/mips64<br>> > problem I worked around. Minor, I guess. We could just drop these platforms, or OpenBSD entirely.<br>> > Not a huge deal. But it is yet more stuff that C as an intermediate platform solves.<br>> > Exception handling stinks on all platforms but SOLsun/SOLgnu.<br>> > The ALPHA_OSF code no longer works. I tried.<br>> > Generating C/C++ would significantly improve exception handling nearly across the board.<br>> > It is possible otherwise, but much more difficult.<br>> > <br>> > <br>> > So, again, C as intermediate code isn't perfect or without drawbacks, but it promises:<br>> > greatly increased portability <br>> > more efficient exception handling <br>> > better codegen by letting the optimizer be full on, even acrosss modules with some C compilers (gcc 4.5, Visual C++, at least) <br>> > better debugging with stock debuggers (including Visual C++, windbg) <br>> > a portable distribution format -- no more having to distribute binaries, though they still have advantages <br>> > easier to get into the various "ports" systems I think as a result <br>> > a much smaller system overall (no GPL, if it matters) <br>> > <br>> > <br>> > Again, there are drawbacks, but it just seems so very tempting.<br>> > <br>> > <br>> > I'm sure I'll plug away at m3cc a while longer, but I think more and more it is questionable.<br>> > <br>> > <br>> > I can try again to read the LLVM stuff.<br>> > <br>> > <br>> > A new backend I think is unavoidably a lot of work, be it C or LLVM.<br>> > That's my hangup on both of these. It requires knowing a lot about two big things -- M3CG and the underlying generator.<br>> > parse.c is "only" 6,000 lines but pretty dense in terms of information gone into it. Maybe I'm just feeling dumb.<br>> > <br>> > <br>> > The thing about C though, is it is a very well understood next layer down. Certainly compared to<br>> > the gcc trees or LLVM. I don't think it is just me, that I'm some C expert.<br>> > <br>> > <br>> > <br>> >> This could probably be improved a lot by switching to a better debug info format,<br>> >> probably the latest Dwarf variant. But that is a big job.<br>> > <br>> > <br>> > I don't believe we have to do *anything* sort of to switch debug formats.<br>> > We just have to provide gcc with decently formed typeful trees.<br>> > It should do the rest.<br>> > Currently I guess it is all custom.<br>> <br>> It doesn't provide nearly enough information in stock form. The "stabs" it now produces has a lot<br>> of Modula-3-specific stuff crammed inside the fields of stabs entries. This had be be added by the<br>> original implementors of the gcc backend. A different debug format will need changes to gcc to<br>> emit what is needed. However, it might well be entirely within the "llanguage" of, say Dwarf, which<br>> is very general. It certainly would be a lot cleaner, and it could easily be completed in places<br>> that are now hard. So there would still be a lot of work.<br>> <br>> I don't completely understand where the current back end emits all the stabs stuff, but I believe<br>> all or almost all of it comes through code in parse.c calling utility code (dbxout.c, e.g.), and<br>> is not much taken from the trees gcc uses. This is why I have yet to figure out how to write<br>> correct debug info describing the locations of static links, since gcc develops this information<br>> by transforming trees, after parse.c has done its thing.<br>> <br>> > <br>> > I tried -g again, thinking maybe things were better now. It still crashes.<br>> > It seems related to the fact that _m3_fault is in an unknown location.<br>> > But that seems actually deliberate and reasonable, and I tried fiddling with it anyway.<br>> > No luck yet.<br>> > <br>> > <br>> > This debug format problem is also solved by using C intermediate code.<br>> > You just use -g or -gdb or -Zi or whatever, whatever is normal for C, and it'd just work.<br>> > <br>> <br>> Lots of things, TEXT being probably the worst, won't display in a Modula-3 form this way.<br>> And things in expressions/statements won't work either. A debugger user will have to understand<br>> a lot of low-level stuff about how the C back end translates Modula-3 code to C, to use it at all,<br>> and it will still be far less convenient.<br>> <br>> > <br>> > Anyway..<br>> > - Jay<br>> > <br> </body>
</html>