[M3devel] merging gdb from 6.4 to 7.1?

[Rodney M. Bates]

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
> 
> 
> 
> 
>