Re: Configure libiberty after newlib

[Eli Zaretskii <eliz@delorie.com>]

> From: Alexandre Oliva <aoliva@cygnus.com>
> Date: 17 May 2000 16:08:08 -0300
> 
> On May 16, 2000, Alexandre Oliva <aoliva@cygnus.com> wrote:
> 
> > 	* Makefile.in (configure-target-libiberty): Depend on
> > 	configure-target-newlib.
> 
> Having got approval from binutils and gdb maintainers (the latter in
> private), I'm checking this in.  How about release branches?

I'd rather we do not change the release branch at this late stage.  As
far as I understand, GDB 5.0 is very close to a release, and we had
better not rocked the boat too much with configury changes at this
time.
From ac131313@cygnus.com Thu May 18 01:01:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: gdb-4.95.2.tar.bz2 available
Date: Thu, 18 May 2000 01:01:00 -0000
Message-id: <3923A2F2.302AEF0A@cygnus.com>
X-SW-Source: 2000-05/msg00288.html
Content-length: 333

FYI

I have zero items in my 5.0 e-mail tray.

Before unpacking this tar-ball, I would suggest renaming it to something
obvious ;-)  Assuming that no one screams, I have it renamed/moved to
ftp.gnu.org/gnu/gdb some time after 2000-05-19.06:00 gmt

	Andrew

PS: I need to figure out how to rename the gdb_4_95_2-*-release CVS tag
:-)
From ac131313@cygnus.com Thu May 18 02:03:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: -W* rules for engagement?
Date: Thu, 18 May 2000 02:03:00 -0000
Message-id: <3923B19F.29591370@cygnus.com>
X-SW-Source: 2000-05/msg00289.html
Content-length: 2479

(The obvious follow on from PARAMS :-)

How do people think we should attack this?  I'm talking both from a
logistic point of view of how should it be done and a philosophical view
of position (w.r.t. warnings) should be taken.

I can think of two extreme viewpoints:

	o	fixing warnings is a waste of time.
		we've better things to do and besides
		we don't make mistakes.  Go away.

	o	GDB shall compile with
		  -Wall -Wa-few-extras -Werror
		and emit no warnings.  Drop
		everything and fix all warnings
		now.  Add something to CVS so that
		it doesn't accept code containing
		warnings.

The obvious flaw with the first (and yet highly convincing argument) is
that people do make mistakes.  A second and more significant problem is
that code that contains ``warnings'' is, to a new developer, in an
unknown state - was that if assignment ``if (x = y)'' intentional?. 
While not much of an problem in a small project with a single developer,
it is a very big issue with a large long lived project with many
developers (such as GDB).  Being able to make a change to a file knowing
that before/after it should contain no warnings is a real confidence
booster to a developer.  The reason I spent a significant amount of time
last year expunging key warnings was so that I could, with a certain
degree of confidence, make sweeping (but mechanical) changes across many
files.

The second proposal just needs a reality check.  While some warning
checks (e.g. -Wformat) have a relatively small over head and a very
significant return others such as -Wunused-parameters (yes, GCC 3.0 does
accept it!), I would argue, are of marginal benefit.  In selecting
warnings I think we need to be careful to choose those that avoid lots
of false negatives.  Further, given the vaguarities of operating systems
it is also often the case that zero warnings are physically impossible.


So what then?  I'd like to suggest we pad out the current list of
warnings:

  -Wimplicit -Wreturn-type -Wcomment -Wformat -Wparentheses
-Wpointer-arith

with a few additional key warnings such as -Wuninitialized
-Wmissing-prototypes (any others?) and then try to get these down to
zero so that -Werror can be used on this contracted list.  Beyond that,
people, can pursue things at their leisure.

How to approach this? I'm easy.  I am wary of fix warning a-thons and
the like.  Often fixing a warning involves a careful re-examination of
the code.  If someone wants to take it on, I'm again easy.

	Andrew
From kettenis@wins.uva.nl Thu May 18 03:27:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: ac131313@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: -W* rules for engagement?
Date: Thu, 18 May 2000 03:27:00 -0000
Message-id: <200005181027.MAA15469@landau.wins.uva.nl>
References: <3923B19F.29591370@cygnus.com>
X-SW-Source: 2000-05/msg00290.html
Content-length: 1523

We should definitely try to eleminate all warnings from GDB.  And
indeed picking the right set of warning flags is important.  Having a
lot of spurious warnings makes it harder to spot the important ones
(or even to spot errors, having Emacs walk through all the warnings
before hitting the first real error can be quite annoying).

   So what then?  I'd like to suggest we pad out the current list of
   warnings:

     -Wimplicit -Wreturn-type -Wcomment -Wformat -Wparentheses
   -Wpointer-arith

Hmm, how important is -Wpointer-arith?  It generates a lot of warnings
from code in <string.h> on Linux and the Hurd, due to a bug in gcc
2.95.  For now I've just disabled it in my local CVS tree.

   with a few additional key warnings such as -Wuninitialized
   -Wmissing-prototypes (any others?) and then try to get these down to
   zero so that -Werror can be used on this contracted list.  Beyond that,
   people, can pursue things at their leisure.

   How to approach this? I'm easy.  I am wary of fix warning a-thons and
   the like.  Often fixing a warning involves a careful re-examination of
   the code.  If someone wants to take it on, I'm again easy.

Enabling additional warnings one by one, giving people a few weeks to
recover and fix things, is probably the best idea.  The majority of
those won't really involve a lot of re-examination of code.  And the
cases where it does, that code will probably benefit from a
re-examination, at least if people will review, update and add
comments to that code.

Mark
From donnte@microsoft.com Thu May 18 09:42:00 2000
From: Donn Terry <donnte@microsoft.com>
To: 'Andrew Cagney' <ac131313@cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: RE: -W* rules for engagement?
Date: Thu, 18 May 2000 09:42:00 -0000
Message-id: <309F4FC4705DC844987051A517E9E39B16EEE4@red-pt-02.redmond.corp.microsoft.com>
X-SW-Source: 2000-05/msg00291.html
Content-length: 4275

Let me add a little on the side of fixing all warnings (over time):
On a new port (or with a new compiler, or....) there is no way to
know whether any given warning is benign or not.  (Particularly
since there is no canonical list of "expected" warnings.)  To
do a port right, each and every warning should be inspected to assure
that it isn't significant on that particular port.  That's
an expensive proposition if there are any number of "too much trouble
to fix" warnings.

Also, if there are more than an easily memorized handful, the appearance
of a new warning (which has a very good chance of being significant)
due to a code change is much easier to miss.

If it were my world :-) ... warnings would be acceptable, but each warning
would require that in the source code there is a one page or longer
(minimum acceptable size) explanation of why the warning is present,
why it cannot be fixed, who made that decision, and a study of possible
alternatives and why they were discarded.  For the 1 warning in 100
that is easier to fix that way than to make a code change, it's probably
justified to spend that effort.  The rest would be fixed by code change
real quickly :-) .

To be more realistic: how about a goal that 5.1 has a minimum number
of warnings, and provide a periodic scorecard on how it's going.
(And maybe 1-line comments for the ones that are painful to fix any
other way, so at least folks reviewing warnings know what to expect.)

Donn

> -----Original Message-----
> From: Andrew Cagney [ mailto:ac131313@cygnus.com ]
> Sent: Thursday, May 18, 2000 2:02 AM
> To: GDB Patches
> Subject: -W* rules for engagement?
> 
> 
> (The obvious follow on from PARAMS :-)
> 
> How do people think we should attack this?  I'm talking both from a
> logistic point of view of how should it be done and a 
> philosophical view
> of position (w.r.t. warnings) should be taken.
> 
> I can think of two extreme viewpoints:
> 
> 	o	fixing warnings is a waste of time.
> 		we've better things to do and besides
> 		we don't make mistakes.  Go away.
> 
> 	o	GDB shall compile with
> 		  -Wall -Wa-few-extras -Werror
> 		and emit no warnings.  Drop
> 		everything and fix all warnings
> 		now.  Add something to CVS so that
> 		it doesn't accept code containing
> 		warnings.
> 
> The obvious flaw with the first (and yet highly convincing 
> argument) is
> that people do make mistakes.  A second and more significant 
> problem is
> that code that contains ``warnings'' is, to a new developer, in an
> unknown state - was that if assignment ``if (x = y)'' intentional?. 
> While not much of an problem in a small project with a single 
> developer,
> it is a very big issue with a large long lived project with many
> developers (such as GDB).  Being able to make a change to a 
> file knowing
> that before/after it should contain no warnings is a real confidence
> booster to a developer.  The reason I spent a significant 
> amount of time
> last year expunging key warnings was so that I could, with a certain
> degree of confidence, make sweeping (but mechanical) changes 
> across many
> files.
> 
> The second proposal just needs a reality check.  While some warning
> checks (e.g. -Wformat) have a relatively small over head and a very
> significant return others such as -Wunused-parameters (yes, 
> GCC 3.0 does
> accept it!), I would argue, are of marginal benefit.  In selecting
> warnings I think we need to be careful to choose those that avoid lots
> of false negatives.  Further, given the vaguarities of 
> operating systems
> it is also often the case that zero warnings are physically 
> impossible.
> 
> 
> So what then?  I'd like to suggest we pad out the current list of
> warnings:
> 
>   -Wimplicit -Wreturn-type -Wcomment -Wformat -Wparentheses
> -Wpointer-arith
> 
> with a few additional key warnings such as -Wuninitialized
> -Wmissing-prototypes (any others?) and then try to get these down to
> zero so that -Werror can be used on this contracted list.  
> Beyond that,
> people, can pursue things at their leisure.
> 
> How to approach this? I'm easy.  I am wary of fix warning a-thons and
> the like.  Often fixing a warning involves a careful re-examination of
> the code.  If someone wants to take it on, I'm again easy.
> 
> 	Andrew
> 
From assign@gnu.org Thu May 18 10:31:00 2000
From: assignments <assign@gnu.org>
To: gdb-patches@sourceware.cygnus.com
Subject: GDB assigns/disclaims
Date: Thu, 18 May 2000 10:31:00 -0000
Message-id: <200005181731.NAA31164@delysid.gnu.org>
X-SW-Source: 2000-05/msg00292.html
Content-length: 1162

The following disclaimers and/or assignments concerning GDB
have recently been added to the file copyright.list here at the 
Free Software Foundation.  If you have any questions or corrections,
please send them to my general work address, 3diff@gnu.org.
                                     Thanks!
                                     Brian Youmans
                                     Assignments Clerk

GDB     Christopher G. Demetriou        US 1972 2000-04-26
Assigns past and future changes.
cgd@sibyte.com

GDB     Ed Satterthwaite        US 1943 2000-04-27
Assigns past and future changes.
ehs@sibyte.com

GDB     Ralf Baechle    Germany 1970    2000-04-22
Assigns past and future changes.
ralf@gnu.org

BINUTILS GDB GLIBC GCC  SGI     2000-04-18
Disclaims changes by Ralf Ba:chle in the past and for the next 5 years.
(Nancy Bigham)

ANY BINUTILS GCC GDB    Sibyte, Inc.    2000-04-26
Disclaims changes to free software by Ed Satterthwaite, in the past and
for the next 2 years.
(Leo Joseph)

ANY BINUTILS GCC GDB    Sibyte, Inc.    2000-04-26
Disclaims changes to free software by Chris G. Demetriou, in the past
and for the next 2 years.
(Leo Joseph)
From brolley@redhat.com Thu May 18 12:08:00 2000
From: Dave Brolley <brolley@redhat.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] Pass Machine to Assembler During Simulator Tests
Date: Thu, 18 May 2000 12:08:00 -0000
Message-id: <39243FC9.6FA03C19@redhat.com>
X-SW-Source: 2000-05/msg00293.html
Content-length: 631

Hi,

The test harness for the sim/testsuite/sim/<target> testsuite was
correctly iterating through all of the requested machines, but was not
passing this information to the assembler. As a result, the tests were
really just running repeatedly for the default machine.

This patch passes the machine information to the assembler using the
-mcpu option. This information is then passed on to the linker and
simulator via the obect file. I know that all assemblers do not have
the -mcpu option, but the two targets using this framework (FR30 and
m32r) both support it.

Anyone have a better idea? If not, is this ok to commit?

Dave
From aoliva@cygnus.com Thu May 18 13:21:00 2000
From: Alexandre Oliva <aoliva@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: mn10300 sim 64-bit clean-up
Date: Thu, 18 May 2000 13:21:00 -0000
Message-id: <orvh0bliff.fsf@saci.lsd.ic.unicamp.br>
X-SW-Source: 2000-05/msg00294.html
Content-length: 127

This didn't kill as many testsuite failures on alpha-x-mn10300 as I
had hoped it would, but it did kill some.  Ok to install?