Updated MAINTAINERS file - work in progress

[Andrew Cagney <ac131313@cygnus.com>]

Hello,

Attached is a revised copy of the gdb/MAINTAINERS file.  In drafting
this revision, I've endeavored to:

	o	re-structure it slightly so that it is easier
		to figure out the exact problem domain of
		a given maintainer.

	o	prepare the file in readiness for when
		all maintainers have write privs.

	o	not change the maintenance assignments
		I've been handed several proposals already
		but would like to keep that separate.

For this discussion thread could I suggest (plead ;-) restricting the
discussion to style rather than substance.

Assuming no one objects, I'll commit this file 24 hours after this
posting.

	Andrew

			Blanket Write Privs

Andrew Cagney			ac131313@cygnus.com?
Stan Shebs			shebs@cygnus.com?


			Various Maintainers

Note individuals who maintain parts of the debugger need approval to
check in changes outside of the immediate domain that they maintain.

If there is no maintainer for a given domain then the problem falls to
the head maintainer.


Target/Architecture: Generic ISA - Instruction Set Architecture -
issues. API variants, CPU variants.  *-tdep.c.

d10v target		Andrew Cagney		cagney@cygnus.com
d30v target		Andrew Cagney		cagney@cygnus.com
mips target		Andrew Cagney		cagney@cygnus.com
mn10300 target		Andrew Cagney		cagney@cygnus.com
powerpc target		Elena Zannoni		ezannoni@cygnus.com
arm target		Jim Ingham		jingham@cygnus.com
m32r target		Michael Snyder		msnyder@cygnus.com


Host/Native: Target specific native support - typically shared
libraries and quirks to procfs/ptrace/...  A native maintainer works
with the arch and core maintainer when resolving more generic
problems.

hp testsuite (gdb.hp)	Jimmy Guo	 adl-debugger-wdb-merge-guru@cup.hp.com
djgpp native		DJ Delorie		dj@cygnus.com
win32 host & native	Chris Faylor		cgf@cygnus.com
x86 linux native	Jim Blandy		jimb@cygnus.com
hurd native		Mark Kettenis		kettenis@wins.va.nl
macos host & native	Stan Shebs		shebs@apple.com
hpux, hp pa native	Jeff Law		law@cygnus.com


Core: Generic components used by all of GDB

generic arch support	Andrew Cagney		cagney@cygnus.com
target vector		Andrew Cagney		cagney@cygnus.com
main (main.c, top.c)	Elena Zannoni		ezannoni@cygnus.com
readline		Elena Zannoni		ezannoni@cygnus.com
generic symtabs		Jim Blandy		jimb@cygnus.com
dwarf readers		Jim Blandy		jimb@cygnus.com
elf reader		Jim Blandy		jimb@cygnus.com
stabs reader		Jim Blandy		jimb@cygnus.com
tracing			Michael Snyder		msnyder@cygnus.com
threads			Michael Snyder		msnyder@cygnus.com
breakpoint.c		Michael Snyder		msnyder@cygnus.com
language support	David Taylor		taylor@cygnus.com
expression eval		David Taylor		taylor@cygnus.com
defs.h			David Taylor		taylor@cygnus.com
utils.c			David Taylor		taylor@cygnus.com
Scheme support		Jim Blandy		jimb@cygnus.com
svr4 shlibs (solib.c)	Jim Blandy		jimb@cygnus.com
coff reader		Philippe De Muyter	phdm@macqel.be
remote.c		Andrew Cagney		cagney@cygnus.com
sds protocol		Stan Shebs		shebs@apple.com
rdi/adp protocol	Stan Shebs		shebs@apple.com
gdbserver		Stan Shebs		shebs@apple.com
documentation	 	Stan Shebs		shebs@apple.com
testsuite	 	Stan Shebs		shebs@apple.com


UI: External (user) interfaces.

command interpreter	Fernando Nasser		fnasser@cygnus.com
gdbtk (c & tcl)		Jim Ingham		jingham@cygnus.com
libgui (w/foundry, sn)	Jim Ingham		jingham@cygnus.com



		Write After Approval

* Indicates folks we need to get Kerberos/ssh accounts ready so they
can write in the source tree
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: UI_OUT component of libGDB available
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <3898FD3C.9888BF77@cygnus.com>
X-SW-Source: 2000-q1/msg00099.html
Content-length: 1226

Hello,

I'm pleased to announce that Red Hat have integrated the UI_OUT
component (result builder object) which is part of the on going libGDB
project into the GDB sources. It will appear in the main CVS repository
shortly (1).  The basic details of the UI_OUT component were discussed
in various postings on the gdb@sourceware list last year.

To allow for both some settling in and some room for debate (2), there
is going to be a period during which the new UI_OUT code co-exists with
the old printf style output.  During this period, GDB can be built to
use the new UI_OUT code by configuring with (this will also be fixed):

	./configure --enable-build-warnings=-DUI_OUT=1

With the UI_OUT code enabled, the only visible change is that GDB's
start up message includes:

	GNU gdb 4.18.1 (UI_OUT)
	[...]
	(gdb) 

as the first ui-out implementation is, funny enough, the existing text
interface.

This work was authored (in reverse alphabetic order) by Elena Zannoni,
Fernando Nasser and me (Andrew Cagney).

	Andrew

(1) Don't forget that gdb/binutils are about to have their repositories
merged.  If you download this week, you'll just need to re-download next
week.

(2) I'm sure that there is plenty of room for debate.
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: 5.0 known issues 2000-02-09
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000208092840.C15046@lucon.org>
References: <38A04DBB.F32C217F@cygnus.com>
X-SW-Source: 2000-q1/msg00171.html
Content-length: 799

On Wed, Feb 09, 2000 at 04:09:15AM +1100, Andrew Cagney wrote:
> 
> 
> GNU/Linux/PPC: It's status is unclear (and is being debated as I write
> this).  I have a sinking feeling that it won't be ready until the 5.1
> time frame.  Sigh.
> 

Last time when I had access to Linux/PPC, my gdb was working ok on
Linux/PPC. Unfortunately, I no longer have any easy access to
Linux/PPC. There is very little I can do here. Going through my
change log, I see the following:

Wed Oct 27 13:34:15 1999  H.J. Lu  <hjl@gnu.org>

        * config/powerpc/linux.mh (NATDEPFILES): Add linux-thread.o and
        lin-thread.o.

Tue Sep 14 09:32:51 1999  H.J. Lu  <hjl@gnu.org>

	* config/powerpc/nm-linux.h: New.

Since I cannot verify if they really fix the problem, I am very
reluctant to submit the patch.


H.J.
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: msnyder@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: lin-thread cannot handle thread exit
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003081942.e28JgFa00230@delius.kettenis.local>
References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com>
X-SW-Source: 2000-q1/msg00613.html
Content-length: 1144

   Date: Tue, 07 Mar 2000 15:27:48 -0800
   From: Michael Snyder <msnyder@cygnus.com>

   Hi Mark, 

   I appreciate your helping to find problems with it, and
   I'd like to  know what else in the code you regard as a
   "loose end".  One of my problems is that I'm not really
   an experienced writer of multi-threaded apps -- I'm just
   the person on the GDB team with the most experience with
   GDB multi-thread debugging.

Well, the main "loose end" is that there seems to be some code to
take advantage of the event reporing facilities in libthread_db, but
GDB doesn't really use it right now.

Another thing is that the comment at the start of the file seems to
suggest that some code is shared with Solaris, but right now this
isn't the case.

Anyway, I'm not really experienced in writing multi-threaded apps
either.  I've some experience in multi-threaded debugging on the Hurd
(where basically every program is multi-threaded), but the Hurd uses a
much saner approach than Linux.  I'll do my best to help, but I
probably won't be able to take a serious look at GDB's way of handling
multithreaded apps in the next few weeks.

Mark
From rearnsha@arm.com Sat Apr 01 00:00:00 2000
From: Richard Earnshaw <rearnsha@arm.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: rearnsha@arm.com
Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003211408.OAA03415@cam-mail2.cambridge.arm.com>
References: <38D75890.C5CC8261@cygnus.com>
X-SW-Source: 2000-q1/msg00755.html
Content-length: 1032

> "J.T. Conklin" wrote:
> 
> > Todd> So I would have to argue that the singlestep logic must either
> > Todd> happen at a really low level (this guarantees it will patch last
> > Todd> and un-patch first) or must go through the real breakpoint logic
> > Todd> which can do duplicate detection.
> > 
> > The SOFTWARE_SINGLE_STEP() macro is called at a low enough level that
> > it inserts and remove trap instructions without effecting GDB's high-
> > level breakpoints.  So I think we're OK.  As a result, I wouldn't be
> > suprised if steping into a breakpoint didn't behave the same as on a
> > machine with hardware single-step.
> 
> Its got long-term problems.
> 
> The code assumes that it is going to retain control, blocked on the
> target, while the actual step is performed.
> This doesn't work well within a pure event model where control is ment
> to return to the event-loop when ever the target is resumed.

It doesn't work properly with INSTRUCTION_NULLIFIED either -- at least it 
didn't last time I tried it...

R.