Re: unused parameter warnings

[Andrew Cagney <ac131313@cygnus.com>]

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