GDB PR categories

GDB PR categories

[Andrew Cagney]

Following up from what Elena did.  What do people think of the following 
PR categories.

a29k
alpha
arc
arm
avr
cris
d10v
d30v
fr30
h8300
h8500
i386
i960
ia64
m32r
m68hc11
m68k
m88k
mcore
mn10200
mn10300
ns32k
pa
powerpc
s390
sh
sparc
tic80
v850
vax
w65
x86-64
xstormy16
z8k

aix
djgpp
GNU/Linux
FreeBSD
NetBSD
OpenBSD
hurd
solaris
other os

c++
java
pascal
scheme
ada
objc

threads
sharedlibs
remote
server
cli
mi
tui
symtab

It kind of reflects the maintainers file.  We can, like everything else, 
always do this incrementally :-)

Thoughts?
Andrew

Re: GDB PR categories

[David Carlton]

On Thu, 26 Sep 2002 14:16:49 -0400, Andrew Cagney <ac131313@redhat.com> said:

> Following up from what Elena did.  What do people think of the
> following PR categories.

[ one for each architecture, for each OS, for each programming
language, and for the following components of GDB: threads,
sharedlibs, remote, server, cli, mi, tui, symtab. ]

> It kind of reflects the maintainers file.  We can, like everything
> else, always do this incrementally :-)

A few random thoughts:

* If you're going to create so many categories, how about one for each
  debugging format as well?

* Another thing to consider kind of reflecting is the testsuite: so
  arch, asm, base, c++, (chill), disasm, fortran, gdb, hp, java, log,
  mi, stabs, sum, threads, trace.  Maybe that would be a good place to
  start from; and then, as we noticed that there were, say, a large
  number of bugs about a specific subcategory of one of those
  categories, we could fork off a separate PR/testsuite category for
  it?
  
  Though, now that I think about it, the two lists of categories
  shouldn't be identical: if a bug currently is present only on a
  particular platform but the command sequence to manifest that bug
  makes sense on any platform, then the testsuite case shouldn't be
  placed in a platform-specific location.

* I definitely think that doing this incrementally would be a good
  idea; you've proposed more than 50 categories, and there are only
  476 non-closed PR's, so probably some of the categories would be too
  sparse to bother with for now.  Maybe you could follow the 'os' lead
  and have 'other arch' and 'other language' categories (where, say,
  pascal/scheme/ada/objc could be in the latter but c++ and java get
  their own PR categories), forking off a new arch/language/os
  whenever the appropriate 'other' category gets too large to
  conveniently browse.

David Carlton
carlton@math.stanford.edu

Re: GDB PR categories

[Andrew Cagney]

> * If you're going to create so many categories, how about one for each
>   debugging format as well?

I think it might confuse things.  The only way the average user is going 
to spot a symtab bug is by GDB printing out:
	internal-error: symtab.c: .....
:-)

> * Another thing to consider kind of reflecting is the testsuite: so
>   arch, asm, base, c++, (chill), disasm, fortran, gdb, hp, java, log,
>   mi, stabs, sum, threads, trace.  Maybe that would be a good place to
>   start from; and then, as we noticed that there were, say, a large
>   number of bugs about a specific subcategory of one of those
>   categories, we could fork off a separate PR/testsuite category for
>   it?

GDB's testsuite directory is split more along functional lines.

>   Though, now that I think about it, the two lists of categories
>   shouldn't be identical: if a bug currently is present only on a
>   particular platform but the command sequence to manifest that bug
>   makes sense on any platform, then the testsuite case shouldn't be
>   placed in a platform-specific location.

Yes.  Most test cases are generic.  The only non-generic directory is 
gdb.arch where tests need to verify the exact value of registers.

Separatly I was wondering about a test-bug `class'.

> * I definitely think that doing this incrementally would be a good
>   idea; you've proposed more than 50 categories, and there are only

Dam!  You spotted my cunning plan.  I was going to spread the bugs so 
thinly that no one could find them and hence think GDB had no problems ;-)

>   476 non-closed PR's, so probably some of the categories would be too
>   sparse to bother with for now.  Maybe you could follow the 'os' lead
>   and have 'other arch' and 'other language' categories (where, say,
>   pascal/scheme/ada/objc could be in the latter but c++ and java get
>   their own PR categories), forking off a new arch/language/os
>   whenever the appropriate 'other' category gets too large to
>   conveniently browse.

Yes, that makes sense.  If there is an active maintainer create the 
category otherwize leave it for ``other'':

arch-i386
arch-mips

os-GNU/Linux
os-bsd

lang-c++

???-thread
???-macro

ui-misc
ui-mi
ui-tui

I just wonder if somone will get confused by having to choose between 
``other arch/lang/os/ui/...  I guess create xxx-other on demand as well.

(BTW, anyone know the story with ``-'' in categories.  I think fernando 
indicated that it wasn't valid but the online docs 
(http://www.gnu.org/software/gnats/ uses that in the examples.)

thanks,
Andrew

Re: GDB PR categories

[Daniel Jacobowitz]

On Thu, Sep 26, 2002 at 05:05:29PM -0400, Andrew Cagney wrote:
> (BTW, anyone know the story with ``-'' in categories.  I think fernando 
> indicated that it wasn't valid but the online docs 
> (http://www.gnu.org/software/gnats/ uses that in the examples.)

It's valid - but awkward for dejagnu/kfail.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB PR categories

[David Carlton]

On Thu, 26 Sep 2002 17:05:29 -0400, Andrew Cagney <ac131313@redhat.com> said:

>> If you're going to create so many categories, how about one for
>> each debugging format as well?

> I think it might confuse things.  The only way the average user is
> going to spot a symtab bug is by GDB printing out:

> 	internal-error: symtab.c: .....
> :-)

That's a good point, and one that I hadn't considered.  Having said
that, the categories are more for our benefit, not for users'
benefits, so as long as we don't mind moving PR's to an appropriate
category once they've been analyzed, then debugging format-specific
categories could be useful.

But probably in practice there would be few enough such bugs that
having a generic 'symtab' category is good enough.

> (BTW, anyone know the story with ``-'' in categories.  I think
> fernando indicated that it wasn't valid but the online docs
> (http://www.gnu.org/software/gnats/ uses that in the examples.)

Wasn't Fernando complaining about "-" in categories for the testsuite?
Something about argument passing and runtest?

Though now that I look at the actual thread, I'm confused.

David Carlton
carlton@math.stanford.edu

Re: GDB PR categories

[Jim Blandy]

Andrew Cagney <ac131313@redhat.com> writes:
> Following up from what Elena did.  What do people think of the
> following PR categories.

Looks like a great first shot to me.

Re: GDB PR categories

[Elena Zannoni]

Andrew Cagney writes:
 > Following up from what Elena did.  What do people think of the following 
 > PR categories.

Ok. seems reasonable. Even though there may be some overlap of
categories.  Watch out for characters like '-' '+' '/' in the
names. Maybe double check with Fernando.

Elena


 > 
 > a29k
 > alpha
 > arc
 > arm
 > avr
 > cris
 > d10v
 > d30v
 > fr30
 > h8300
 > h8500
 > i386
 > i960
 > ia64
 > m32r
 > m68hc11
 > m68k
 > m88k
 > mcore
 > mn10200
 > mn10300
 > ns32k
 > pa
 > powerpc
 > s390
 > sh
 > sparc
 > tic80
 > v850
 > vax
 > w65
 > x86-64
 > xstormy16
 > z8k
 > 
 > aix
 > djgpp
 > GNU/Linux
 > FreeBSD
 > NetBSD
 > OpenBSD
 > hurd
 > solaris
 > other os
 > 
 > c++
 > java
 > pascal
 > scheme
 > ada
 > objc
 > 
 > threads
 > sharedlibs
 > remote
 > server
 > cli
 > mi
 > tui
 > symtab
 > 
 > It kind of reflects the maintainers file.  We can, like everything else, 
 > always do this incrementally :-)
 > 
 > Thoughts?
 > Andrew
 > 
 > 

Re: GDB PR categories

[Andrew Cagney]

> Andrew Cagney writes:
>  > Following up from what Elena did.  What do people think of the following 
>  > PR categories.
> 
> Ok. seems reasonable. Even though there may be some overlap of
> categories.  Watch out for characters like '-' '+' '/' in the
> names. Maybe double check with Fernando.

Is this for things like setup_xfail vis: ``setup_xfail *-*-* gdb/123''?

I guess the question is, as with the above, does ``gdb'' refer to the 
bug database or the category within the database.  I think it should 
identify the bug database (so we can also refer to GCC's and other 
databases).  Otherwize, we'll create a situtation where, every time 
someone re-categories a bug report, they need to remember to also modify 
the test :-(

Andrew