Re: unused parameter warnings

Re: unused parameter warnings

[Jim Blandy]

> > Having the top level Makefile.in ``impose'' a specific -W policy is
> > something to discuss with the other projects.
> 
> I'd suggest configuring with
> 
> 	CFLAGS=-g ..../configure

Okay, that makes sense.  Thanks.
From blizzard@mozilla.org Wed Mar 29 19:56:00 2000
From: Christopher Blizzard <blizzard@mozilla.org>
To: gdb@sourceware.cygnus.com
Cc: jimb@redhat.com
Subject: Re: problems loading shared libraries - with attached test case
Date: Wed, 29 Mar 2000 19:56:00 -0000
Message-id: <38E2D221.ADC270BF@mozilla.org>
References: <38DFD84E.9F330EC1@mozilla.org>
X-SW-Source: 2000-03/msg00374.html
Content-length: 2542

Christopher Blizzard wrote:
> 
> I'm using "set auto-solib-add 0" after main has been called.  If I use
> "shar" to load a shared library manually once I can't use it again to
> load another shared library later.  Please see the attached log for an
> example of how to reproduce the problem.
> 

I've got a patch for this problem ( attached. )  The problem is in
solib_add().

--Chris

-- 
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
Chiseling through a wall of stone isn't my idea of fun.  But chiseling
through a wall of cheese -- now *there's* a party.
------------
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.207
diff -u -r1.207 ChangeLog
--- ChangeLog	2000/03/30 03:03:23	1.207
+++ ChangeLog	2000/03/30 03:53:33
@@ -1,3 +1,12 @@
+2000-03-29  Christopher Blizzard  <blizzard@redhat.com>
+
+	* solib.c (solib_add): If a library is in gdb's shared object map
+	and its symbols aren't loaded and the pattern of shared objects to
+	load matches the path name of the shared object in question, load
+	the symbols in the shared object.  This fixes the problem when
+	shared libraries are being loaded only on demand that the
+	"sharedlibrary" command can only be run once.
+
 2000-03-29  Daniel Berlin  <dan@cgsoftware.com>
 
 	* minsyms.c (add_minsym_to_demangled_hash_table): New function.
Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.7
diff -u -r1.7 solib.c
--- solib.c	2000/03/24 23:49:10	1.7
+++ solib.c	2000/03/30 03:53:39
@@ -1298,6 +1298,26 @@
 	  i = *i_link;
 	}
 
+      /* Check to see whether or not this shared object was added to
+         gdb's shared object list without the symbols being loaded.
+         If it was and it matches the pattern for the shared object
+         that needs to be loaded, load it. */
+      if (!gdb->symbols_loaded)
+	{
+	  if (!pattern || re_exec(gdb->so_name))
+	    {
+	      if (catch_errors(symbol_add_stub, gdb,
+			       "Error while reading shared library symbols:\n",
+			       RETURN_MASK_ALL))
+		{
+		  if (from_tty)
+		    printf_unfiltered ("Loaded symbols for %s\n",
+				       gdb->so_name);
+		  gdb->symbols_loaded = 1;
+		}
+	    }
+	}
+
       /* If the shared object appears on the inferior's list too, then
          it's still loaded, so we don't need to do anything.  Delete
          it from the inferior's list, and leave it on GDB's list.  */
From guo@cup.hp.com Thu Mar 30 00:12:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: gdb@sourceware.cygnus.com
Subject: rsync failure (rsync --archive --delete --checksum --compress --statsrsync://sourceware.cygnus.com/src-cvs .) (fwd)
Date: Thu, 30 Mar 2000 00:12:00 -0000
Message-id: <Pine.LNX.4.10.10003300109010.10974-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-03/msg00375.html
Content-length: 4936

Why these rsync error messages?  What do they mean?

- Jimmy Guo, guo@cup.hp.com

---------- Forwarded message ----------
Date: Thu, 30 Mar 2000 00:01:23 -0800

src/gdb/osf-share/HP800/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/gdb/osf-share/RIOS/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/gdb/testsuite/config/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/gdb/testsuite/gdb.chill/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/gdb/testsuite/gdb.disasm/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/gdb/testsuite/gdb.fortran/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/gdb/testsuite/gdb.hp/gdb.defects/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/gdb/testsuite/gdb.hp/gdb.objdbg/objdbg01/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/gdb/testsuite/gdb.hp/gdb.objdbg/objdbg03/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/gdb/testsuite/gdb.hp/gdb.objdbg/objdbg04/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/gdb/testsuite/gdb.hp/gdb.objdbg/tools/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/gdb/testsuite/gdb.hp/gdb.objdbg/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/gdb/testsuite/gdb.hp/tools/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/tix/generic/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/tix/library/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/tk/generic/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/tk/library/demos/images/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/tk/library/images/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/tk/library/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/tk/mac/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/tk/testsuite/config/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/tk/testsuite/tk.tests/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/tk/win/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/cygwin/regexp/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/cygwin/testsuite/config/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/cygwin/testsuite/winsup.api/samples/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/cygwin/testsuite/winsup.api/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/cygwin/testsuite/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/doc/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/mingw/include/sys/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/mingw/include/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/mingw/profile/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/mingw/samples/dlltest/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/mingw/samples/filehand/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/mingw/samples/fixargv/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/mingw/samples/fmode/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/mingw/samples/globbing/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/mingw/samples/simpledll/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/mingw/samples/test/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/mingw/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/w32api/include/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
src/winsup/w32api/lib/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
IO error encountered - skipping file deletion
send_files failed to open src/bfd/hosts/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
send_files failed to open src/gdb/testsuite/gdb.base/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
send_files failed to open src/tix/library/bitmaps/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
send_files failed to open src/tix/man/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory
send_files failed to open src/tk/doc/#cvs.rfl.sourceware.cygnus.com.2545: No such file or directory

Number of files: 12823
Number of files transferred: 49
Total file size: 152516389 bytes
Total transferred file size: 7892394 bytes
Literal data: 275622 bytes
Matched data: 7616772 bytes
File list size: 433947
Total bytes written: 68061
Total bytes read: 508910

wrote 68061 bytes  read 508910 bytes  1306.84 bytes/sec
total size is 152516389  speedup is 264.34

Re: unused parameter warnings

[Jim Blandy]

> > Having the top level Makefile.in ``impose'' a specific -W policy is
> > something to discuss with the other projects.
> 
> I'd suggest configuring with
> 
> 	CFLAGS=-g ..../configure

Okay, that makes sense.  Thanks.
From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: "H . J . Lu" <hjl@lucon.org>
Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A revised patch for dlclose
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <npu2iicdra.fsf@zwingli.cygnus.com>
References: <20000307120800.A27315@valinux.com> <200003080058.e280wga00453@delius.kettenis.local> <20000307170321.A884@lucon.org> <200003080119.e281Jul00524@delius.kettenis.local> <20000307173547.A1068@lucon.org>
X-SW-Source: 2000-q1/msg00583.html
Content-length: 579

> That is fine with me as long as it is fixed in 5.0. There is no excuse
> not to get gdb to work with dlclose. "I don't like the way it fixes the
> bug" doesn't count unless you can provide a different approach. I
> think it is unreasonable to have a perfect fix for every bug. We can
> work a better one after 5.0 if we don't have the time now.

I believe there is such a thing as a correct fix.  And I don't think
they so hard to find that one must always shamble towards correctness.
I think it's fine to reject a patch that one knows has bugs as serious
as the extant code.
From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
Cc: gdb@sourceware.cygnus.com
Subject: Re: unloading shared objects
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <np7lf6bwp4.fsf@zwingli.cygnus.com>
References: <200003102253.XAA04805@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-q1/msg00687.html
Content-length: 1796

> > Anyway, I'll finish these when I get back, if nobody else does.  I'd
> > love comments on the changes.
> 
> Looks like the way to go. If at all possible, could you adapt my proposed
> changes to avoid casts to/from CORE_ADDR to your patches ?

Sure thing.

> There are at least two more subcases for this case (which should perhaps
> be mentioned in a FIXME), where _something_ needs to happen:
> 
>       - The DSO might have changed in the meantime, in which case we will
> 	have to reread it. Comparing timestamps between GDB's view
> 	of the DSO and the current DSO will detect this case.
>       - The shared object is now loaded to another address, requiring
> 	relocation of the DSO in GDB's symbol tables etc.
> 	This might happen if another DSO increased in size since the
> 	last run, causing a relocation for the current DSO.
> 	Handling this requires comparison between the current objfile
> 	offsets and the computed offsets for the DSO in the inferior.

The shared object list should be emptied each time the inferior is
started, exactly because the address at which a given shared object is
loaded may vary from run to run.  Within a particular process, shared
objects never change address.  We re-read each shared object's symbols
every time it is loaded.  So I think these are handled trivially.


> And for the next round of changes (GDB-17.0 ?):
> 
> Create a layer between GDB's view of DSOs and the target DSOs.
> This would get rid of duplicated solib.c code in osfsolib.c, irix5-nat.c
> and perhaps the awkward DSO handling in rs6000-nat.c. It might also
> allow us to split solib.c properly into SVR4 and non-SVR4 (SunOS 4.x/BSD)
> components.

Absolutely!  Solaris already has an interface for this, modeled after
the thread_db library, which we may want to emulate.
From jimb@cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@cygnus.com>
To: Vandervennet Yves <yves.vandervennet@philips.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Some Questions about GDB
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <np66vfr25f.fsf@zwingli.cygnus.com>
References: <200002232139.QAA08859@delysid.gnu.org>
X-SW-Source: 2000-q1/msg00389.html
Content-length: 1295

> Hi there,

Hi!  The best place for questions like this is
gdb@sourceware.cygnus.com.


>     I am trying to find out if it is possible to debug an embedded
> program with gdb running on a workstation.

It certainly is.  Most of the contracts Cygnus took were to support
embedded systems of some sort or another.  (We expect things to remain
the same under the Red Hat name.)

>    * which distribution of gdb is needed ?

Any distribution of GDB should work.  Certainly the ones available
from the FSF or from sourceware.cygnus.com do.

>    * what is the protocol used ? Serial line ? TCP/IP ?

There are many protocols supported.  GDB can talk over a serial line
or to an arbitrary host and TCP port.  GDB has its own remote
protocol, which works fine, which is fully documented in the GDB
manual.  Also, GDB knows how to talk to many different kinds of ROM
monitors --- as far as the monitor is concerned, GDB is just a very
fast typist.

>    * what is the program (or piece of code) that has to run on the
>      target machine ?

You'll either need a ROM monitor GDB knows how to talk to, or you can
write a simple stub.  The GDB distribution includes several sample
stubs you can modify to suit your needs.  All this is described in the
GDB manual.

(Gosh, I love questions like that.)
From davidwilliams@ozemail.com.au Sat Apr 01 00:00:00 2000
From: David Williams <davidwilliams@ozemail.com.au>
To: Serge Nikulin <nikulin@actsw.amat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: How to set RS232 speed in gdb in WinNT?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E538DF.ED6289D6@ozemail.com.au>
References: <003e01bf9b69$afc0c220$35758798@mis.amat.com>
X-SW-Source: 2000-q1/msg00853.html
Content-length: 1045

Use -b command line option to change baud rate

eg.     gdb -b 115200
to set baud rate 115200 baud.
Dave.

Serge Nikulin wrote:

> Hi,
>
> I use gdb for remote debugging of m68k target, compiled with MRI
> <--host=i686-pc-cygwin32 --target=m68k-motorola-ieee>
> Native MRI' X-Ray debugger does not support our home-made RTOS.
> GDB works but I have few questions.
>
> 1) Currently ieee-695 bfd section is not connected to gdb, so I work without
> src.
>     I've checked examples of coff and aout conections and it does not look
> as a 1-day job for me
>     (including the fact that ieee-695 support in bfd is incomplete).
>     Does anyone have ieee + gdb experience?
>
> 2) In my gdb session under WinNT I use command "target remote com1"
> In this case gdb connects to COM1 at 9600 baud. I'd like to change this
> speed (say, to 38400) but I can't. I've changed default speed for COM1 in
> WinNT's control panel but it did not help. It looks like I have to pass that
> speed to cygwin.dll somehow. How can I do that?
>
> Thanks!
>
> Serge.

Re: unused parameter warnings

[Andrew Cagney]

Jim Blandy wrote:
> 

Jim,  just FYI,

GDB currently set -Wunused for the reason you've explained (it is also
why I've been picking at a -Wno-unused-param flag).  gdb/configure.in
doesn't enable it.  The reason you're seeing those warnings is because
the top level src/Makefile.in sets:
	CFLAGS="-g -Wall -O2"
overriding any local default.

Having the top level Makefile.in ``impose'' a specific -W policy is
something to discuss with the other projects.

	enjoy
		Andrew
From insulaner_andi@yahoo.com Sat Apr 01 00:00:00 2000
From: Andreas Kuepper <insulaner_andi@yahoo.com>
To: gdb@sourceware.cygnus.com
Subject: running GDB on Cygwin
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000303101528.22003.qmail@web3402.mail.yahoo.com>
X-SW-Source: 2000-q1/msg00518.html
Content-length: 364

Is there anybody who ever tried to run GDB on Cygwin?

I want to do remote debugging and when I run
"configure" it fails with the message :

configure: error: could not find term library

Thanks for your help!

Andreas Kuepper
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Jim Blandy <jimb@cygnus.com>, hjl@lucon.org, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D92F29.A3D@cygnus.com>
References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org> <200003091210.HAA19857@indy.delorie.com> <npya7c6zn7.fsf@zwingli.cygnus.com> <200003221806.NAA14225@indy.delorie.com>
X-SW-Source: 2000-q1/msg00774.html
Content-length: 759

Eli Zaretskii wrote:
> 
> > Eli's test of the value's type is incorrect if the watch expression
> > contains a structure comparison, like (foo == bar) || (something
> > else), where foo and bar are structures.  In that case, there will be
> > a value of type "struct", not at the end of the value list, but which
> > should be watched in its entirety.
> 
> Errr... do you have an actual example program where this happens?
> 
> I seem to be unable to reproduce the problem, at least in a C program:
> whenever I say "watch foo == bar" (where foo and bar are structs), GDB
> curses thusly:
> 
>         Structure has no component named operator==.

Argh... gdb does not seem to know that struct compare
is permitted.  I'll publish a patch.

				Michael Snyder
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kettenis@wins.uva.nl
Cc: gdb@sourceware.cygnus.com
Subject: Re: Restructuring i386_extract_return_value
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003101742.MAA22060@indy.delorie.com>
References: <200003092241.e29Mfow00303@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00671.html
Content-length: 908

> Comments are welcome!

The changes seem okay, but I have one consideration:

> 1. The majority of i386 targets in GCC return floating-point values by
>    default on the FPU stack.  In fact the only exception is NeXT.
>    There is a switch `-mno-fp-ret-in-387' to force GCC to return
>    floating-point values in the ordinary CPU registers.  I don't think
>    this can be determined from the debugging information.  Is it worth
>    adding a i386 target specific option to enable people to debug
>    this code?  Propably not.

Is this switch so painful to support that it is justified to disable
debugging such programs?

In my experience, about 5 minutes after you release a product based on
the assumption that this switch is not used enough to care about,
somebody posts a bug report for a program which does use that
switch...

So I think it might be a good idea to support it if that is feasible.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [GDB-MAINT] Nick Duffek is now the UnixWare threads maintainer
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A78889.1CFDD70@cygnus.com>
X-SW-Source: 2000-q1/msg00257.html
Content-length: 863

Hello,

Nick was the original author of the UnixWare threads support.  It's only
natural that he be allowed to continue maintaining it.

	Andrew
Mon Feb 14 15:39:01 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* MAINTAINERS: Make Nick Duffek the UnixWare threads maintainer.

Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.3
diff -p -r1.3 MAINTAINERS
*** MAINTAINERS	2000/02/12 23:55:14	1.3
--- MAINTAINERS	2000/02/14 04:40:59
*************** GNU/Linux PPC native	Kevin Buettner		kev
*** 41,46 ****
--- 41,47 ----
  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
+ UnixWare Threads	Nick Duffek		nsd@cygnus.com
  
  
  Core: Generic components used by all of GDB
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: hjl@valinux.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003081008.FAA16481@indy.delorie.com>
References: <20000307132401.A20282@valinux.com>
X-SW-Source: 2000-q1/msg00595.html
Content-length: 1624

> Starting program: /home/hjl/bugs/gdb/hw/y 
> warning: Could not insert hardware watchpoint 1.
> warning: Could not insert hardware watchpoint 3.
> ptrace: Unknown error 4294967295.
> Cannot insert breakpoints.
> The same program may be running in another process.
> (gdb)
> 
> ia32 only has 4 hardware debug registers. But gdb shouldn't crash.

I don't see any crashes in the above script.  GDB simply didn't start
the process.  It is arguable whether it should instead proceed after
inserting only those watchpoints it can, but I agree that it should at
least be a user option.

> Even worse, after deleted one hardware watchpoint, gdb still refused
> to work.

It works for me, but I have patches to do that, which I'm trying for 6
months to get accepted :-(.

Those patches also correct numerous other problems with watchpoints on
x86, which you didn't mention.  For example, try setting several
watchpoints (of different types) on the same variable, and see the
mess.  Another problem which I corrected is that you cannot watch
struct members, array elements, and bit fields with hardware-assisted
watchpoints.

> (gdb) watch a1
> Watchpoint 1: a1
> (gdb) watch a2
> Watchpoint 2: a2
> (gdb)
> 
> gdb won't set hardware watchpoints on long long nor double.

You could look at go32-nat.c, it supports watching any region up to 16
bytes large.  (I'm at a loss how come DJGPP needed to invent this: I'd
expect any x86 platform to have this already, since watchpoints are
such an indispensable tool in some circumstances.)

> I will send in a patch in another email.

Please see my response with objections to your patch.
From scottb@netwinder.org Sat Apr 01 00:00:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: GDB Mailing List <gdb@sourceware.cygnus.com>
Subject: Problems with LinuxThreads support in GDB...
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C92CBD.178D0A1E@netwinder.org>
X-SW-Source: 2000-q1/msg00670.html
Content-length: 1430

> Scott Bambrough wrote:
> >
> > I've been running tests on the ARM Linux target on a NetWinder regularly.  The
> > results of the testsuite follow.  Most of the problems are due to no
> > linuxthreads support and problems stepping in/out or backtracing in signal
> > handlers.  I'll work at implementing support for these over time.  I was hoping
> > to port the x86 work, but just haven't had the time.
> 
Michael Snyder wrote:
> 
> Hmm, the new thread_db module should be pretty
> target-independent (correct me if I'm wrong).

Ok.  I attempted to put the linuxthreads support in last night.  It was
relatively painless, but I have reached a stumbling block with glibc 2.1.2.  In
gdb_proc_service.h there are the following two definitions:

#ifndef HAVE_PRGREGSET_T
typedef gregset_t  prgregset_t;         /* BOGUS BOGUS BOGUS */
#endif

#ifndef HAVE_PRFPREGSET_T
typedef fpregset_t prfpregset_t;        /* BOGUS BOGUS BOGUS */
#endif

The BOGUS comments are accurate.  Neither gregset_t or fpregset_t are defined in
<sys/procfs.h>.  prgregset_t and prfpregset_t are also used in gdb_threads_db.h
as well without checking the defines from config.h.  I'm trying this on 2.1.3
ATM, but for the most part, the installed base of users is using 2.1.2 on ARM
Linux.  Any thoughts on how I could get around this?

Scott


-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From guo@cup.hp.com Sat Apr 01 00:00:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: gdb@sourceware.cygnus.com
Subject: hppa 10.20 test result comparison
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.LNX.4.10.10003231324500.9146-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-q1/msg00778.html
Content-length: 3207

This is a comparison of 2/4's gdb and 3/21's.  The sourceware version of
3/21 has disabled elf32-hppa support in bfd, so there's no hpux 11.00
comparison for the sourceware version.

Also, I've just diff'd the result for run PASS "1", which is HP WDB
project's internal pass for HP compiler support.  I don't have the
result for GNUPro gcc / g++ pass yet.  So far, the 3/21 version is
mostly stable, with some regressions when using HP compilers.

- Jimmy Guo, guo@cup.hp.com

 <0>: 2/4
    # of expected passes            4505
    # of unexpected failures        101
    # of unexpected successes       3
    # of expected failures          17
    # of unresolved testcases       2
    # of unsupported tests          15
 <1>: 3/21
    # of expected passes            4499
    # of unexpected failures        115
    # of unexpected successes       3
    # of expected failures          17
    # of unresolved testcases       2
    # of unsupported tests          16

------------------------------------------------------------------------
 Section - FAIL / XFAIL / XPASS / UNRESOLVED
      | 1 |: (P:PASS F:FAIL FTM:FAIL/timeout XFA:XFAIL
              XTM:XFAIL/timeout XPA:XPASS UNR:UNRESOLVED SKI:skipped
              '-':not run)
------------------------------------------------------------------------
gdb.base/selftest.exp
 <0>: | P |: step into xmalloc call
 <1>: | F |: step into xmalloc call

 <0>: | P |: xgdb is at prompt
 <1>: | F |: xgdb is at prompt

 <0>: | P |: send ^C to child process
 <1>: |FTM|: send ^C to child process

 <0>: | P |: send SIGINT signal to child process
 <1>: |FTM|: send SIGINT signal to child process

 <0>: |XFA|: backtrace through signal handler
 <1>: |XTM|: backtrace through signal handler

gdb.base/shlib-call.exp
 <0>: | P |: run until breakpoint set at a function
 <1>: | F |: run until breakpoint set at a function

gdb.base/so-impl-ld.exp
 <0>: | P |: step into solib call
 <1>: | F |: step into solib call

 <0>: | P |: step in solib call
 <1>: | F |: step in solib call

gdb.base/so-indr-cl.exp
 <0>: | P |: break on indirect solib call before running
 <1>: | F |: break on indirect solib call before running

gdb.base/solib.exp
 <0>: | P |: caught generic solib load
 <1>: | F |: caught generic solib load

 <0>: | P |: continue after generic catch load
 <1>: | F |: continue after generic catch load

 <0>: | P |: caught generic solib unload
 <1>: | F |: caught generic solib unload

 <0>: | P |: caught specific solib load
 <1>: | F |: caught specific solib load

 <0>: | P |: caught specific solib unload
 <1>: | F |: caught specific solib unload

 <0>: | P |: specific catch load doesn't trigger inappropriately
 <1>: | F |: specific catch load doesn't trigger inappropriately

 <0>: | P |: specific catch unload doesn't trigger inappropriately
 <1>: | F |: specific catch unload doesn't trigger inappropriately

 <0>: | F |: break on indirect call
 <1>: | P |: break on indirect call

 <0>: | F |: continue to break on indirect call: the program is no longer running
 <1>: | - |: continue to break on indirect call: the program is no longer running

 <0>: | - |: continue to break on indirect call
 <1>: | F |: continue to break on indirect call