[M3devel] merging gdb from 6.4 to 7.1?

[Daniel Alejandro Benavides D.]

Hi all:
Is it possible to include in the m3gdb support for remote debugging like the one introduced by the developers in SPIN (which was based on DEC Firefly teledebug protocol called TTD see doi:10.1145/68210.69219 see doi.org), it is a protocol to remotely debug a target program but in such a case you have the post-mortem abilities is that hard to ask for doing it remotely, though TDD it was implemented for debugging the operating system itself it could be if I'm not wrong easier to debug from a type terminal remotely than in the cellphone or tablet it self when such a target is available for any application. Postmortem would be even nicer since there is general support in high-end cellphones which seem to be a ever increasing range of platforms and operating system versions and vendors.
Other version of TTD protocol was used in the ldb debugger, this allowed even to disconnect and connect from cross-platform debugging to target and provide services for the stack walking between other issues its dependence in lcc's c compiler though will it be possible to replace it for an intermediate representation like the one of Modula-3 I just see possible for the m3tk toolkit to do it since support for it would be a nice feature for its debugging features  the porting of the M3CG assembly machine language for the lcc framework would be possible, there is support on it for targeting even the CLI .Net framework so it would be good to ask if it isn't too hard to do it for a good reason to do it to host M3CG.
Thanks in advance

 
--- El mar, 20/7/10, Rodney M. Bates <rodney_bates at lcwb.coop> escribió:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] merging gdb from 6.4 to 7.1?
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 20 de julio, 2010 10:20
> I have been thinking about doing this
> myself for some time, but up to
> now, have not had the time.  I can certainly help, if
> you want to do it,
> or maybe take it on myself.  I think I will be having
> more time soon.
> I have done it a couple of times before.  A few things
> can be hard to
> figure out, because they rework existing stuff in gdb and
> it's hard to
> dig out what the new equivalent of the old mechanism
> is.  A lot of the
> M3-specific code I either heavily modified or wrote.
> 
> Jay K wrote:
> > The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well
> enough.
> > 
> > I'll volunteer to merge m3gdb from 6.4 to 7.1.
> 
> BTW, there is now or will be very soom, a 7.2 gdb.
> Also, the latest gdb does reverse debugging, by recording
> snapshots during the forward run.  This would be a
> *very*
> nice feature to have for Modula-3.
> 
> 
> > 
> > Are people interested?
> > 
> > I saw some mention of 6.4.3 in our history.
> > But there's no release called that.
> > What is it?
> 
> I don't remember anything about this.
> 
> > 
> > Some of the conflicts are about  SYMBOL_TYP vs.
> LHS_SYMBOL_TYPE.
> > What that a deliberate important change on our port?
> 
> Yes, this is my change, very deliberate, and gets around a
> nasty
> group of dangling pointer bugs.  I would have to took
> at it again,
> but it used to cache a pointer to a gdb type struct, lazily
> looked-
> up the first time, right into an existing field of another
> gdb struct.
> When you rerun, gdb reloads the referent structs of such
> pointers,
> leaving them dangling.  Or maybe I am mixing up two
> different
> problems.  Anyway, the two macros are essential.
> 
> I have long thought it might be nice to design a better
> mechanism,
> but it's not simple.  I strongly recommend not messing
> with it during
> merging to a newer gdb.  Save that for a subsequent
> job with a separate
> CVS tag.  It's only a performance matter, and except
> for debugging work
> that proceeds without requiring user-types commands all the
> time, it
> scarcely matters.
> 
> Also, we would be a lot better off to dump stabs+ and use
> whatever
> latest version of dwarf that gdb already has support
> for.  But that
> is also a job that should be done separately, with its own
> tag, after
> a new merge is working with the existing mechanisms.
> 
> 
> > 
> > Thanks,
> >  - Jay
> > 
> > 
> > 
> > 
> >     
>         
>           
>