Where to put gdb/gdbserver-shared code?

Where to put gdb/gdbserver-shared code?

[Daniel Jacobowitz]

There was some discussion a month or so about sharing signals.c between gdb
and gdbserver.

This comes up fairly often; we never quite decided how to treat it.  Kevin
seemed to be of the school that says there should be no code sharing, and
Andrew leant the other way (as I remember - apologies for
misrepresentation!).  I dislike it in general, and having just eliminated
every last bit of it I'm reluctant to introduce more, but signals.c is a
good candidate if ever there was one.

Ignoring that for the moment though, if we are going to share it, where
should we keep it?  We could keep it in a directory clearly describing its
role ("native" or "utils") or clearly describing its status as shared ("common"). 
I don't want to leave it where it is if it's going to be shared.

Since I don't see the transition to lots and lots of common, shareable code
with well-defined boundaries in our near future, I lean towards "common". 
Longer term, I'd prefer something like "native/utils/" and a well-described
allowable interface for code in that directory; I don't know how practical
that is yet.

Thoughts?  Preferences?

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

Re: Where to put gdb/gdbserver-shared code?

[Andrew Cagney]

> There was some discussion a month or so about sharing signals.c between gdb
> and gdbserver.

Month or so [ago]?

http://sources.redhat.com/ml/gdb/2002-03/msg00058.html

> This comes up fairly often; we never quite decided how to treat it.  Kevin
> seemed to be of the school that says there should be no code sharing, and
> Andrew leant the other way (as I remember - apologies for
> misrepresentation!).  I dislike it in general, and having just eliminated
> every last bit of it I'm reluctant to introduce more, but signals.c is a
> good candidate if ever there was one.
> 
> Ignoring that for the moment though, if we are going to share it, where
> should we keep it?  We could keep it in a directory clearly describing its
> role ("native" or "utils") or clearly describing its status as shared ("common"). 
> I don't want to leave it where it is if it's going to be shared.
> 
> Since I don't see the transition to lots and lots of common, shareable code
> with well-defined boundaries in our near future, I lean towards "common". 
> Longer term, I'd prefer something like "native/utils/" and a well-described
> allowable interface for code in that directory; I don't know how practical
> that is yet.
> 
> Thoughts?  Preferences?

If it is only going to contains the signals stuff, gdb/signals/?

As I mentioned before, I'm left wondering what "common" is in common 
with :-)  GDB?  sim? ...

Andrew

Re: Where to put gdb/gdbserver-shared code?

[Daniel Jacobowitz]

On Sun, Mar 24, 2002 at 05:54:46PM -0500, Andrew Cagney wrote:
> >There was some discussion a month or so about sharing signals.c between gdb
> >and gdbserver.
> 
> Month or so [ago]?
> 
> http://sources.redhat.com/ml/gdb/2002-03/msg00058.html

Two and a half weeks is sorta like a month! :)

> >This comes up fairly often; we never quite decided how to treat it.  Kevin
> >seemed to be of the school that says there should be no code sharing, and
> >Andrew leant the other way (as I remember - apologies for
> >misrepresentation!).  I dislike it in general, and having just eliminated
> >every last bit of it I'm reluctant to introduce more, but signals.c is a
> >good candidate if ever there was one.
> >
> >Ignoring that for the moment though, if we are going to share it, where
> >should we keep it?  We could keep it in a directory clearly describing its
> >role ("native" or "utils") or clearly describing its status as shared 
> >("common"). I don't want to leave it where it is if it's going to be 
> >shared.
> >
> >Since I don't see the transition to lots and lots of common, shareable code
> >with well-defined boundaries in our near future, I lean towards "common". 
> >Longer term, I'd prefer something like "native/utils/" and a well-described
> >allowable interface for code in that directory; I don't know how practical
> >that is yet.
> >
> >Thoughts?  Preferences?
> 
> If it is only going to contains the signals stuff, gdb/signals/?
> 
> As I mentioned before, I'm left wondering what "common" is in common 
> with :-)  GDB?  sim? ...

Very true.  gdb/signals/ seems like overkill, because I can't think of
anything else to go there - well, maybe I can, actually - but at least
it's exact.  Let's see how this looks.

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