That vision thing ...

That vision thing ...

[Andrew Cagney]

(If you know something about Australian politics ``The Vision Thing'' is
a backhanded slap at someone that that has no sense of vision :-)

Hello,

For the curious :-) Where next.

Firstly, there is always the ongoing and important need to improve
things like language support (namely C++), symbol-table performance,
native threads, code cleanups, bug fixes and the like.  I believe that
that there is now plenty active and ongoing development in these area. 
Me giving opinions on it would just be distracting.

I also think that these ongoing developments are going to be the
principal factors that determine the time frame for each succeeding GDB
release.  They are also the things that attract the most attention and
also get the most praise :-)

Longer term I can see two significant developments:

	o	libgdb

		The basic motivation is the desire
		to make it easier (and more robust) to
		integrate GDB into a GUI.

		Here the first step is MI (along with
		ui-out/ui-file).

	o	multi-arch et al.

		Here the objective is to remove
		the assumption that GDB has, at any
		time, just one thread/language/isa
		/abi/vm/target/....  The motivation
		being to make it possible for GDB to
		handle complex targets that contain
		multiple architectures and the like.

		Here that first step is multi-arch.

So?

I'd just like to encourage people to pursue what they are currently
working on.  Just keep in mind that there is likely to be more
significant change (especially through multi-arch) lurking in the
background.  For my part I hope to be concentrating on mult-arch et al,
however, I will most likely occasionally prod libgdb.

As with any bit of open source, there is of course, no timeframe ...

Comments, fits of laughter, ...

	Andrew

Re: That vision thing ...

[Quality Quorum]

On Mon, 12 Jun 2000, Andrew Cagney wrote:

> (If you know something about Australian politics ``The Vision Thing'' is
> a backhanded slap at someone that that has no sense of vision :-)
> 
> Hello,
> 
> For the curious :-) Where next.
> 
> Firstly, there is always the ongoing and important need to improve
> things like language support (namely C++), symbol-table performance,
> native threads, code cleanups, bug fixes and the like.  I believe that
> that there is now plenty active and ongoing development in these area. 
> Me giving opinions on it would just be distracting.
> 
> I also think that these ongoing developments are going to be the
> principal factors that determine the time frame for each succeeding GDB
> release.  They are also the things that attract the most attention and
> also get the most praise :-)
> 
> Longer term I can see two significant developments:
> 
> 	o	libgdb
> 
> 		The basic motivation is the desire
> 		to make it easier (and more robust) to
> 		integrate GDB into a GUI.
> 
> 		Here the first step is MI (along with
> 		ui-out/ui-file).
> 
> 	o	multi-arch et al.
> 
> 		Here the objective is to remove
> 		the assumption that GDB has, at any
> 		time, just one thread/language/isa
> 		/abi/vm/target/....  The motivation
> 		being to make it possible for GDB to
> 		handle complex targets that contain
> 		multiple architectures and the like.
> 
> 		Here that first step is multi-arch.
> 
> So?
> 
> I'd just like to encourage people to pursue what they are currently
> working on.  Just keep in mind that there is likely to be more
> significant change (especially through multi-arch) lurking in the
> background.  For my part I hope to be concentrating on mult-arch et al,
> however, I will most likely occasionally prod libgdb.
> 
> As with any bit of open source, there is of course, no timeframe ...
> 
> Comments, fits of laughter, ...

Can we split target depended pieces into subdirs under gdb ?

> 
> 	Andrew
> 

Thanks,

Aleksey

Re: That vision thing ...

[Fernando Nasser]

Quality Quorum wrote:
> 
> Can we split target depended pieces into subdirs under gdb ?
> 

Aleksey,

For the majority of the targets we have only a single target dependent file.
So most of these subdirectories will have a single file in it.  The exceptions
would be few.

But a nice variant from your idea it would be a "targetdep" subdirectory for all
these files.  This would reduce the large number of files under src/gdb and
group together all that is related to different targets.  It still looks nice
even with multi-arch I think.

We can continue on that line and group all those remote-* files as well...

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299

Re: That vision thing ...

[Quality Quorum]

On Mon, 12 Jun 2000, Fernando Nasser wrote:

> Quality Quorum wrote:
> > 
> > Can we split target depended pieces into subdirs under gdb ?
> > 
> 
> Aleksey,
> 
> For the majority of the targets we have only a single target dependent file.
> So most of these subdirectories will have a single file in it.  The exceptions
> would be few.
> 
> But a nice variant from your idea it would be a "targetdep" subdirectory for all
> these files.  This would reduce the large number of files under src/gdb and
> group together all that is related to different targets.  It still looks nice
> even with multi-arch I think.
> 
> We can continue on that line and group all those remote-* files as well...

It sounds nice.

> 
> -- 
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
> 2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
> Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
> 

Thanks,

Aleksey

Re: That vision thing ...

[Fernando Nasser]

Quality Quorum wrote:
> 
> On Mon, 12 Jun 2000, Fernando Nasser wrote:
> 
> > Quality Quorum wrote:
> > >
> > > Can we split target depended pieces into subdirs under gdb ?
> > >
> >
> > Aleksey,
> >
> > For the majority of the targets we have only a single target dependent file.
> > So most of these subdirectories will have a single file in it.  The exceptions
> > would be few.
> >
> > But a nice variant from your idea it would be a "targetdep" subdirectory for all
> > these files.  This would reduce the large number of files under src/gdb and
> > group together all that is related to different targets.  It still looks nice
> > even with multi-arch I think.
> >
> > We can continue on that line and group all those remote-* files as well...
> 
> It sounds nice.
> 
> Thanks,
> 
> Aleksey

Lets see what Andrew thinks of this.  Someone would also have to take the time
to create the new directory(ies).


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299

Re: That vision thing ...

[Andrew Cagney]

Quality Quorum wrote:
> 
> On Mon, 12 Jun 2000, Andrew Cagney wrote:

> Can we split target depended pieces into subdirs under gdb ?

From the TODO file:

  --

  Restructure gdb directory tree so that it avoids any 8.3 and 14
  filename problems.

  --

  Can the xdep files be replaced by autoconf?

  --

  Convert GDB build process to AUTOMAKE.

  See also sub-directory configure below.

  The current convention is (kind of) to use $(<header>_h) in all
  dependency lists.  It isn't done in a consistent way.

  --

  Cleanup configury support for optional sub-directories.

  Check how GCC handles multiple front ends for an example of how things
  could work.  A tentative first step is to rationalize things so that
  all sub directories are handled in a fashion similar to gdb/mi.

  See also automake above.

  --

(I've included the others as they are about eliminating xdep* and fixing
the build process).

So yes.

Exactly how to do this is another problem entirely.  Do we just
re-arange the deck chairs or look more deeply.

	Andrew

Re: That vision thing ...

[Stan Shebs]

Andrew Cagney wrote:
> 
> Longer term I can see two significant developments:
> 
>         o       libgdb

>         o       multi-arch et al.
> 

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

Re: That vision thing ...

[Daniel Berlin]

> 
> 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.
:)
--Dan

Re: That vision thing ...

[Todd Whitesel]

> I agree that these are the two biggies.  We could call the second
> "multi-everything" :-)

Careful, Green Hills has a trademark on "MULTI" -- 1 guess why...

-- 
Todd Whitesel
toddpw @ windriver.com

Re: That vision thing ...

[Chris Faylor]

On Mon, Jun 12, 2000 at 06:31:57PM -0700, Daniel Berlin wrote:
>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.
>:)

I think I have to revise my usual method of doubling and increasing by
then next time unit when I see (or propose) an engineering time estimate.

That would mean that you'd have this done in four months give or take
four days.

Surely, this would take at least five months.

cgf

Re: That vision thing ...

[Andrew Cagney]

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

	enjoy,
		Andrew

Re: That vision thing ...

[Quality Quorum]

On Tue, 13 Jun 2000, Andrew Cagney wrote:

> So yes.
> 
> Exactly how to do this is another problem entirely.  Do we just
> re-arange the deck chairs or look more deeply.

I would say re-arranging of deck chairs will be a signficant help
in the looking, especially for the guys like me who mostly uses
gdb and seldom has to tweak pieces here and there.

> 
> 	Andrew
> 

Thanks,

Aleksey