[M3devel] merging gdb from 6.4 to 7.1?

[Rodney M. Bates]

This sounds fine with me, as long as there is one branch for the entire
merge process, which will be broken for a while.

Jay K wrote:
> Thanks. To be clear then, my initial merge will likely lose some changes,
> it sounds like you are ok with that, and they can be redone soon 
> thereafter by someone else (e.g. you).
> I'll be sure it builds and do a minimum of debugging with it.
>   I'll expect it to understand some Modula-3 syntax and esp. decode types.
>    When I use gdb everything is void* so there should be obvious improvement
>    with m3gdb.
> I'm not sure what the best way to "help" is. I'm not super keen on 
> "sharing diffs" or using branches. Therefore, come up with something 
> reasonable maybe slightly flawed, commit it, someone else can improve it 
> afterward, as long as the initial one isn't too flawed? ok?
>  
>  
> ok?
>  
>  
> There is some use of $revision$ and $id$ in there and it makes things 
> slightly messy.
> There are files we didn't change, but which show as changed because of them.
> Mostly deleted stuff like hpread.c and the rdi-shared directory.
> Or we added comments in dwarfread.c which was deleted.
>  
>  
> I agree -gstabs might not be best.
>   It isn't supported on e.g. HP64_HPUX.
> But often whenever I try other options like -g or -gcoff or -ggdb or 
> -gdwarf,
> I get crashes in the backend so I leave the config files with -gstabs+. :(
>  
>  
> I don't think it matters too much what I merge up to, as long as it is >6.4.
> 7.1 is out. I didn't see 7.2.
>  
>  
> Thanks,
>  - Jay
>  
>  
>  > Date: Tue, 20 Jul 2010 10:20:38 -0500
>  > From: rodney_bates at lcwb.coop
>  > To: m3devel at elegosoft.com
>  > Subject: Re: [M3devel] merging gdb from 6.4 to 7.1?
>  >
>  > 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
>  > >
>  > >
>  > >
>  > >
>  > >