New directory src/gdb/misc?

New directory src/gdb/misc?

[Andrew Cagney]

Hello,

Some may have noticed DanielJ's and my discussion about better sharing 
of the signals.c code between GDB and GDBSERVER.

I'd previously posted a suggestion that gdb/utils.c be broken down into 
smaller parts and moved to a new directory gdb/utils/.  utils.c is 
running into system include header problems, that should be easier to 
handle if there are a number of smaller more independant files.

In addition to this GDBSERVER and GDB contain a number of common chunks 
of code related to signal handling and conversion.  The proposal is to 
break signals.c down into smaller files in the directory gdb/common/.

Having had a bit of time to think this over, I suspect a gdb/utils/ 
directory is wrongly named - utils makes me think of utility programs.

This leaves ``gdb/common'' and, (new suggestion) gdb/misc/ as possible 
directory names.

thoughts,
Andrew

Re: New directory src/gdb/misc?

[Daniel Jacobowitz]

On Wed, Mar 06, 2002 at 09:31:22PM -0500, Andrew Cagney wrote:
> Hello,
> 
> Some may have noticed DanielJ's and my discussion about better sharing 
> of the signals.c code between GDB and GDBSERVER.
> 
> I'd previously posted a suggestion that gdb/utils.c be broken down into 
> smaller parts and moved to a new directory gdb/utils/.  utils.c is 
> running into system include header problems, that should be easier to 
> handle if there are a number of smaller more independant files.
> 
> In addition to this GDBSERVER and GDB contain a number of common chunks 
> of code related to signal handling and conversion.  The proposal is to 
> break signals.c down into smaller files in the directory gdb/common/.
> 
> Having had a bit of time to think this over, I suspect a gdb/utils/ 
> directory is wrongly named - utils makes me think of utility programs.
> 
> This leaves ``gdb/common'' and, (new suggestion) gdb/misc/ as possible 
> directory names.

'misc' doesn't convey any information.  It's like calling something
'new' in its documentation - not useful for very long.  I'd vote for
common.

Ideally, there would be other files as GDB became gradually more
modular.  THat's something to talk about later though.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: New directory src/gdb/misc?

[Eli Zaretskii]

On Thu, 7 Mar 2002, Daniel Jacobowitz wrote:

> > This leaves ``gdb/common'' and, (new suggestion) gdb/misc/ as possible 
> > directory names.
> 
> 'misc' doesn't convey any information.  It's like calling something
> 'new' in its documentation - not useful for very long.  I'd vote for
> common.

Either `common' or maybe `lib' (or `gdblib').  I agree that `misc' is not 
such a good idea.

Re: New directory src/gdb/misc?

[Andrew Cagney]

> 
> 'misc' doesn't convey any information.  It's like calling something
> 'new' in its documentation - not useful for very long.  I'd vote for
> common.

No information was the idea :-)  Common with what?  Another name is 
``host'' this stuff is all host specific.

> Ideally, there would be other files as GDB became gradually more
> modular.  THat's something to talk about later though.

The one that comes to mind, is the code for mapping between an internal 
buffer and the host's ptrace().  I don't think that would live in common.

enjoy,
Andrew

Re: New directory src/gdb/misc?

[Andrew Cagney]

> On Thu, 7 Mar 2002, Daniel Jacobowitz wrote:
> 
> 
>> > This leaves ``gdb/common'' and, (new suggestion) gdb/misc/ as possible 
>> > directory names.
> 
>> 
>> 'misc' doesn't convey any information.  It's like calling something
>> 'new' in its documentation - not useful for very long.  I'd vote for
>> common.
> 
> 
> Either `common' or maybe `lib' (or `gdblib').  I agree that `misc' is not 
> such a good idea.

I suspect lib will end up being confused with gdblib/libgdb.  At present 
I can only see signals.c and a small part of utils.c ending up in their.

enjoy,
Andrew

Re: New directory src/gdb/misc?

[Elena Zannoni]

Eli Zaretskii writes:
 > 
 > On Thu, 7 Mar 2002, Daniel Jacobowitz wrote:
 > 
 > > > This leaves ``gdb/common'' and, (new suggestion) gdb/misc/ as possible 
 > > > directory names.
 > > 
 > > 'misc' doesn't convey any information.  It's like calling something
 > > 'new' in its documentation - not useful for very long.  I'd vote for
 > > common.
 > 
 > Either `common' or maybe `lib' (or `gdblib').  I agree that `misc' is not 
 > such a good idea.

how about 'generic' (stolen from gdbtk) or 'shared' or 'general' ?

Elena

Re: New directory src/gdb/misc?

[Andrew Cagney]

> Eli Zaretskii writes:
>  > > On Thu, 7 Mar 2002, Daniel Jacobowitz wrote:
>  > > > > This leaves ``gdb/common'' and, (new suggestion) gdb/misc/ as possible 
>  > > > directory names.
>  > > > > 'misc' doesn't convey any information.  It's like calling something
>  > > 'new' in its documentation - not useful for very long.  I'd vote for
>  > > common.
>  > > Either `common' or maybe `lib' (or `gdblib').  I agree that `misc' is not 
>  > such a good idea.
> 
> how about 'generic' (stolen from gdbtk) or 'shared' or 'general' ?
> 
> Elena

`Generic' could be interpreted to mean everything except the 
architecture stuff.

(I think I regret raising this one :-)

Starting again ...

Perhaphs I'm trying to simultaneously squeese a square and triangular 
peg through a round hole

- ``nat'' stuff related to host=target.  gdbserver and gdb have the 
potential to share this.  Signal mapping and ptrace() are probably the 
only things that live here.  Shared libraries, threads, core files, ... 
are all no longer ``native''.

- ``utils'' for just getting gdb to build.  safe_strerror(), xfree(), ...

This does open up the more general question of how to restructure GDB. 
Hopefully that discussion can be side stepped and just persue this to 
the point of being fairly sure we're not heading in a completly wrong 
direction.

Is the right direction to split things across ``functional'' (utils, 
nat, isa/abi, ..) lines rather than ``usage'' (common to gdb/gdbserver, 
commont to gdb/sim, ...) lines?  A functional split would result in 
gdbserver cherry picking from random directories the bits it wants from 
core gdb.

Andrew

Re: New directory src/gdb/misc?

[Daniel Jacobowitz]

On Thu, Mar 07, 2002 at 01:22:22AM -0500, Andrew Cagney wrote:
> >
> >'misc' doesn't convey any information.  It's like calling something
> >'new' in its documentation - not useful for very long.  I'd vote for
> >common.
> 
> No information was the idea :-)  Common with what?  Another name is 
> ``host'' this stuff is all host specific.
> 
> >Ideally, there would be other files as GDB became gradually more
> >modular.  THat's something to talk about later though.
> 
> The one that comes to mind, is the code for mapping between an internal 
> buffer and the host's ptrace().  I don't think that would live in common.

Perhaps someday we'll be able to share that.  It's a bit of a pipe
dream ATM, of course.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: New directory src/gdb/misc?

[Daniel Jacobowitz]

On Thu, Mar 07, 2002 at 10:59:39AM -0500, Andrew Cagney wrote:
> Is the right direction to split things across ``functional'' (utils, 
> nat, isa/abi, ..) lines rather than ``usage'' (common to gdb/gdbserver, 
> commont to gdb/sim, ...) lines?  A functional split would result in 
> gdbserver cherry picking from random directories the bits it wants from 
> core gdb.

One type of directory seem particularly useful:
 - directories in which each file serves the exact same purpose for a
different target.  However many of these we want, though the more
pieces it goes into the more complicated it'll be to figure out what
does what...

The other useful idea would be purely organizational (like breaking up
utils).

Both of these require creating subdirectories; I think both may be good
ideas.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer