[M3devel] additional CVS repositories for additional gcc forks?

[Jay K]

> What I've learned from this discussion is that we should definitely try
> to support dwarf debugging format for the gcc backend. I'll add that
> as a task for the 5.9 release.


I am not certain this makes any sense at all.
I'm not sure.


I don't think it is the job of a gcc front end (as Modula-3 is structured)
to do anything for debugging, to know about debug formats,
*except* to provide type-ful trees to the backend, which they should
do anyway, except which Modula-3 historically doesn't do much.


It is the job of the gcc backend -- below parse.c -- to generate debugging information.


I think what Modula-3 currently does is "tunnel" a bunch of private data through to m3gdb.
I think "stabs" might help associate the data with the code. Again, I don't know.


And I think the trees are slightly well formed such that gcc can generate line numbers
and knows a little bit about locals -- it shows pretty much everything as  void*.


This is getting better lately though.
I'm not doing anything specific to debugging or stabs or dwarf or something.
I'm just filling in the types in the trees.


There was already some code. I couldn't have figured this out so fast otherwise.
We were already building struct types. But we weren't associating them with locals/parameters.


What got me started down this area is actually that gcc cannot generate SPARC64_SOLARIS
code that passes records by value without type information for the records.


As well, if you only provide information to the caller or callee but not both, then AMD64_DARWIN
and possibly others generate incorrect code.


Then I realized what I had actually discovered is how to get stock gdb to work significantly better.
What the code should have been doing all along.


I suppose we could tunnel the private data through dwarf, but I don't think it would provide much gain.
Mainly that HP-UX might stand a chance of working with a debugger. Might.


Given the "data intensity" of the many debugging tasks, sprinking in RTIO calls is actually often
much more effective than any debugger could be. You know, the code I want to debug
gets hit many many times and I don't want to debug it until a certain late point. Getting
there in a debugger is too difficult. Though easier if there is a way to get the debugger
to stop, like by putting int 3 in x86 code. Win32 has the portable (to Win32 architectures) DebugBreak() call.
Macintosh has similar. Too bad I haven't seen anything like this in Posix. Posix is generally very small and limiting..


 - Jay

----------------------------------------
> Date: Sun, 29 Aug 2010 12:45:13 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] additional CVS repositories for additional gcc forks?
>
> Quoting Jay K :
>
> > 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.
> >
> > 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.
> >
> > In both cases as I understand, an effective hack to tunnel
> > information through systems not quite designed/extended to suit.
> >
> > What we have is flawed. What I favor is flawed. But differently.
>
> We don't need to give up what we have in order to try something else
> additionally, do we?
>
> I think m3gdb works quite well on some platforms these days. Unfortunately,
> it doesn't build on others.
>
> On Windows we'll need something for the native debuggers anyway.
>
> Improving the use of other C debuggers will be good, too, for platforms
> we haven't got anything else.
>
> What I've learned from this discussion is that we should definitely try
> to support dwarf debugging format for the gcc backend. I'll add that
> as a task for the 5.9 release.
>
> And Jay has already announced that he will be working on a C backend.
> That should open up other possibilities.
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>