[M3devel] merging gdb from 6.4 to 7.1?

[Jay K]

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
> > 
> > 
> > 
> > 
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100721/e2daf338/attachment-0002.html>