Re: Technical criteria for retaining symbol readers

Re: Technical criteria for retaining symbol readers

[Michael Elizabeth Chastain]

jimb> I'd also like to have some kind of requirement for testability.

I would, too.  My preference would be that we look at gdb-testers@
and if there are no test results for feature X for the past N years,
that counts against keeping feature X.  gcc uses that as one factor
in deciding whether to obsolete stuff.

As far as Andrew's original proposal goes, it's okay with me to
set up some criteria for dropping formats.

Michael C

Re: Technical criteria for retaining symbol readers

[Andrew Cagney]

> jimb> I'd also like to have some kind of requirement for testability.
> 
> I would, too.  My preference would be that we look at gdb-testers@
> and if there are no test results for feature X for the past N years,
> that counts against keeping feature X.  gcc uses that as one factor
> in deciding whether to obsolete stuff.

That's been suggested in the past.  It was pointed out that some systems 
can't run the testsuite (DJGPP) so on its own it wasn't reasonable 
(neither is assuming that the presence of test results stops an 
architecture being removed :-).

Andrew

Re: Technical criteria for retaining symbol readers

[Jim Blandy]

Andrew Cagney <cagney@gnu.org> writes:
> > jimb> I'd also like to have some kind of requirement for testability.
> > I would, too.  My preference would be that we look at gdb-testers@
> > and if there are no test results for feature X for the past N years,
> > that counts against keeping feature X.  gcc uses that as one factor
> > in deciding whether to obsolete stuff.
> 
> That's been suggested in the past.  It was pointed out that some
> systems can't run the testsuite (DJGPP) so on its own it wasn't
> reasonable (neither is assuming that the presence of test results
> stops an architecture being removed :-).

DJGPP (go32-nat.c) doesn't use deprecated interfaces, so it's not a
maintenance burden in core GDB work.  If a target or host has been
kept up to date as interfaces have been deprecated, I'm not sure we
should consider removing it --- obviously somebody cares about it, and
cares in the way that matters.  An absence of test results, plus the
use of deprecated interfaces that most other targets have moved
beyond, seems like sufficient reason to ditch something.

As far as the symtab stuff goes, we don't (yet) have deprecated
interfaces to the symtab core, so that criterion doesn't help us
there.  Looking through the interfaces actually in use and beginning a
deprecation process is called for there.

Technical criteria for retaining symbol readers

[Andrew Cagney]

Hello,

I'd like to see us establish clear technical criteria against which
symtab readers are measured.  Those that don't meet the criteria, either
being fixed or removed.

As an example, should it be a requirement that all symbol-readers use 
the build-symtab framework?

Andrew

Re: Technical criteria for retaining symbol readers

[Jim Blandy]

Andrew Cagney <cagney@gnu.org> writes:
> I'd like to see us establish clear technical criteria against which
> symtab readers are measured.  Those that don't meet the criteria, either
> being fixed or removed.
> 
> As an example, should it be a requirement that all symbol-readers use
> the build-symtab framework?

That would be good.

I'd also like to have some kind of requirement for testability.  For
example, I have no way (that I know of) to evaluate changes to
nlmread.c, but that shouldn't mean that I mustn't change anything it
depends on.  Perhaps we should require that, in order to be retained,
symbol readers have a contact person who can give GDB developers
access to a machine that actually uses that format.  (A complete sim
toolchain being available would be an easy way to satisfy this
requirement.)