This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: That vision thing ...

Daniel Berlin wrote:
> >
> > I agree that these are the two biggies.  We could call the second
> > "multi-everything" :-)
> >
> > > As with any bit of open source, there is of course, no timeframe ...
> >
> > Somewhere around I still have the late-1994/early-1995 document
> > proposing that GDB ought to support multiple architectures at
> > runtime.  For a long time I was doubtful that it would ever
> > happen, but lo and behold, you made it real!  So yes, the big
> > changes can come about if we set them as our goals.
> >
> > Stan
> >
> I consider the type changes i'm making rather big as well.
> Also, on my list, as part of the type changes, is making the vtable using
> code, and overload resolution, generic.
> After that, redoing the symbol table structure.
> And for an encore, i'll rewrite gdb in C++.
> Estimated Time To Completion: 2 days, give or take 2 hours.
> :)

Remember, we're only allowed to rewrite GDB in scheme (N.B. is the GDB
collary to Godwin's law :-).

With regard to the the type changes I hear are being proposed, yes they
are very significant.  The key difference is in the logistics in
completing the work.  Changing types and language structures is largely
platform independant Once you've built/tested it on cygwin it will most
likely work for all platforms.  

bulk-arch (since we can't call it multi- :-) either involves modifying
every single host/target or at least figuring out a way to do things so
that nothing is broken.  It is a much slower more tedious operation.

Like I said, changes like yours are the ones that will be noticed and
receive the praise :-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]