From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: GDB Discussion Subject: Updated MAINTAINERS file - work in progress Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A37686.BC866EB5@cygnus.com> X-SW-Source: 2000-q1/msg00208.html 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 To: GDB Discussion , GDB Patches 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" To: Andrew Cagney Cc: GDB Discussion 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 * config/powerpc/linux.mh (NATDEPFILES): Add linux-thread.o and lin-thread.o. Tue Sep 14 09:32:51 1999 H.J. Lu * 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 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 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 To: Andrew Cagney 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.