* Re: Configure libiberty after newlib
[not found] ` <or4s7x571j.fsf@saci.lsd.ic.unicamp.br>
@ 2000-05-17 16:28 ` Andrew Cagney
2000-05-18 0:36 ` Eli Zaretskii
1 sibling, 0 replies; 2+ messages in thread
From: Andrew Cagney @ 2000-05-17 16:28 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: binutils, gdb-patches, newlib
Alexandre Oliva wrote:
>
> 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?
Neither the binutils nor GDB release branches have newlib on them.
Andrew
From msnyder@cygnus.com Wed May 17 17:13:00 2000
From: msnyder@cygnus.com
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH}: Turn on Multi-Arch for Sparc Solaris.
Date: Wed, 17 May 2000 17:13:00 -0000
Message-id: <200005180012.RAA03575@seadog.cygnus.com>
X-SW-Source: 2000-05/msg00281.html
Content-length: 947
Thru an oversight, I forgot to actually turn this on when I
checked in my earlier patch! Hope it gets some genuine field
testing now...
2000-05-17 Michael Snyder <msnyder@seadog.cygnus.com>
* config/sparc/tm-sun4sol2.h: Turn on multi-arch.
Index: config/sparc/tm-sun4sol2.h
===================================================================
RCS file: /cvs/src/src/gdb/config/sparc/tm-sun4sol2.h,v
retrieving revision 1.3
diff -p -r1.3 tm-sun4sol2.h
*** tm-sun4sol2.h 2000/05/10 20:07:25 1.3
--- tm-sun4sol2.h 2000/05/18 00:11:26
***************
*** 19,25 ****
Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA. */
! /*#define GDB_MULTI_ARCH 2*/
#include "sparc/tm-sparc.h"
#include "tm-sysv4.h"
--- 19,25 ----
Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA. */
! #define GDB_MULTI_ARCH 2
#include "sparc/tm-sparc.h"
#include "tm-sysv4.h"
From law@cygnus.com Wed May 17 17:14:00 2000
From: Jeffrey A Law <law@cygnus.com>
To: Alexandre Oliva <aoliva@cygnus.com>
Cc: gcc-patches@gcc.gnu.org, binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com, newlib@sourceware.cygnus.com
Subject: Re: Configure libiberty after newlib
Date: Wed, 17 May 2000 17:14:00 -0000
Message-id: <6087.958608311@upchuck>
References: <orr9b39eeo.fsf@zecarneiro.lsd.ic.unicamp.br>
X-SW-Source: 2000-05/msg00282.html
Content-length: 371
In message < orr9b39eeo.fsf@zecarneiro.lsd.ic.unicamp.br >you write:
> --=-=-=
>
> libiberty's configure looks for header files, and they can only be
> found after newlib has been configured. Ok to install?
Can you install this into the gcc sources too? No sense in diverging
the toplevel Makefile.in any more than is absolutely necessary :-)
Thanks,
jeff
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: Configure libiberty after newlib
[not found] ` <or4s7x571j.fsf@saci.lsd.ic.unicamp.br>
2000-05-17 16:28 ` Configure libiberty after newlib Andrew Cagney
@ 2000-05-18 0:36 ` Eli Zaretskii
1 sibling, 0 replies; 2+ messages in thread
From: Eli Zaretskii @ 2000-05-18 0:36 UTC (permalink / raw)
To: aoliva; +Cc: binutils, gdb-patches, newlib
> 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?
^ permalink raw reply [flat|nested] 2+ messages in thread