[M3devel] Compiler upgrade broken in Hudson CI

[Rodney M. Bates]

On 02/07/2013 01:36 AM, Jay K wrote:
> m3gdb:
>   is GPL
>   is a fork, that will never be merged
>   that isn't being updated
>   is big
>   that doesn't support some platforms e.g. Darwin, HP-UX

Yes.  But what it does, works, now.  Nothing else exists now
that comes close.

Actually, it has been merged into at least 5 versions of
gdb, counting the original modification.  I have done three,
and in each, I have moved towards reducing the entanglement
with existing gdb code, so merging gets easier, though still no picnic.

It's been updated many times, though not recently.  Most of
the pure updates have been enhancements.  Most of the regressions
have been caused by back end changes, not problems inside
m3gdb.  That said, as often as possible, I have worked around
these inside m3gdb, by adding yet another back end version to
the set it can dynamically adapt to, rather than fixing
the back end.  Kludgier, yes.  But it's more robust, and compatible.
It already copes with quite a range of back ends.

>
> cm3cg has some but not all of those characteristics
>

Ditto.

>
> Meanwhile, debugging on NT and Darwin is limited to line numbers
> and integers and floats. No useful view of structs or globals
> is available.

Perhaps.  But what it does, works on LINUXLIBC6 and AMD64_LINUX, now.
Have you tried m3gdb on NT and Darwin using the working (debug-info-wise)
gcc backend (4.5, as I recall), or only the one wherein you disabled the
Modula-3 debug output (4.6, as I recall)?  In the latter case, it, of course,
doesn't work anywhere.

I think you will find stuff like calls, procedure variables, etc., that
involve the calling convention, will need target-dependent work in
m3gdb.  That's the way it went when adding AMD64_LINUX.  But I would
expect more than you describe to work on a new target, without
modifications.

> And as I understand..can anyone agree/disagree?.. gets its
> data from the backend via a total backdoor hack, that is very difficult
> to duplicate.

Yes, it's a backdoor hack.  But it works, now.

  E.g. including with llvm,

In the long run, llvm plus dwarf (which llvm appears to already have good
support for) is the clear way to get something non-hackish.  But that will
require major debugger work to support, in addition, of course, to an
llvm-derived back end itself.  I am sure this approach would be much
easier than getting dwarf info out of either cm3cg, or gcc compiling
C source.

including if we generated
> typeful gcc trees like any normal backend would do.
> I speculate, maybe it will be possible to output some assembly
> files on the side with just the stabs directives.
>

This could probably work, but it's just a superficially different
information path for an equivalent backdoor hack.  Right now, cm3cg
pretty much just serves as a conduit for stabs info that is generated
by the code parse.c.  From there, it ends up, with little or no change,
interspersed in the rest of the cm3cg-generated assembly code.

But I expect this would be the only reasonable way to get any
Modula-3-literate debug info past C source code.

>
>
> I'm hoping that:
>   gdb on Darwin will improve drastically via the C backend; it hasn't yet
>   windbg and Visual Studio ditto
>
> gdb on platforms that support m3gdb will come close to m3gdb,
> but parity might not be achievable.

You will not achieve anything close to parity without a debugger
that has a lot of Modula-3-specific code inside.  Have you read
cm3/doc/help/m3gdb/m3gdb-onepage.html?  Consider it the definition
of parity.

>
>
> Our target support continues to lag.
>   DragonflyBSD?
>   OpenBSD w/o maintaining patches (mainline gcc doesn't support OpenBSD, but I386_ELF is all fairly much the same, so the patches are small)
>   ARM_NT?
>   {PPC,MIPS,ARM,SH,I386}_CE?
>   ARM_DARWIN? Was mostly there already.
>   PPC32_XBOX?
>   AMD64_NT? This should come along fairly soon now via the C backend.
>
>
> Let's see how good we can get stock debuggers working with our C. Ok?
>

Do whatever you can and want to.  But don't torpedo what is now working,
until you can replace it with something that achieves parity.  Until
then, don't break, disable, or remove it from CVS head.  Keep it an
easy-to-choose and findably-documented option.  If you make changes
that could possibly undermine it, make a branch, until they are well-tested.

>
>   - Jay
>
>
>  > From: rcolebur at SCIRES.COM
>  > To: m3devel at elegosoft.com
>  > Date: Wed, 6 Feb 2013 23:13:37 +0000
>  > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI
>  >
>  > I concur with Rodney, we must preserve the m3gdb capability and the backends that support it!
>  > --Randy Coleburn
>  >
>  > -----Original Message-----
>  > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop]
>  > Sent: Wednesday, February 06, 2013 12:25 PM
>  > To: m3devel at elegosoft.com
>  > Subject: EXT:Re: [M3devel] Compiler upgrade broken in Hudson CI
>  >
>  >
>  >
>  > On 02/05/2013 02:28 AM, Jay K wrote:
>  > > I will fix it, but I do desire to drop the old backend entirely.
>  > > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded.
>  > > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms.
>  > >
>  >
>  >
>  > I am not sure what is happening here, but it is making me very nervous with talk of removing backends.
>  >
>  > I have put in a *huge* amount of work on m3gdb. While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence. Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic debugger.
>  >
>  > Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc. etc.
>  >
>  > A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information. Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its
>  > Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more. As I recall it, only the release branch supports a working m3gdb right now.
>  >
>  > And I use m3gdb all the time in my own work.
>  >
>  > Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*. Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until something newer supports at least all the same debug functions.
>  >
>  >
>  > >
>  > > - Jay
>  > >