From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: "Peter.Schauer" <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE>,
gdb-patches@sourceware.cygnus.com
Subject: Re: Hopefully my last request for 5.0 incorporation
Date: Wed, 19 Apr 2000 01:02:00 -0000 [thread overview]
Message-ID: <38FD673F.C5FFFAE4@cygnus.com> (raw)
In-Reply-To: <38F721D0.4CFF03E8@redhat.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7466 bytes --]
FYI,
I've applied the relevant patches to both the trunk and the 5.0 branch.
Andrew
Fernando Nasser wrote:
>
> For sake of reference by the others I will repeat here what is being proposed.
>
> 1) Have "i r" stand for "info reg". This used to work before but the addition of a new (much less
> frequently used) info command that also starts with "r" ("info remote-process") made it ambiguous.
>
> "i r" is so much used that I am in favor of adding this one. As I heard nothing to the contrary I
> will add it to gdb5.
>
> 2) Have "maint i" stand for "maint info". This also worked before but the addition of "maint
> internal-error" it does not work anymore.
>
> I am quite concerned about adding alias that are so short. However, "i" is an alias for the "info"
> command, and this is a very strong argument in favor of making it an alias for "info" under
> "maintenance". After all "maintenance" is just a prefix that help us separate our "internal use
> only" (TM) commands from the normal user commands.
>
> So, in this one exceptional case, due to the long term acceptance of "i" as short for "info", I will
> incorporate it.
>
> But please folks, no more cryptic abrevs pls. ;-)
>
> --
> Fernando Nasser
> Red Hat, Inc. - Toronto E-Mail: fnasser@redhat.com
> 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
> Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From ac131313@cygnus.com Wed Apr 19 01:31:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sourceware.cygnus.com, Ian Lance Taylor <ian@zembu.com>
Subject: Re: Problems with snapshot 20000412
Date: Wed, 19 Apr 2000 01:31:00 -0000
Message-id: <38FD6E92.8B94D0A0@cygnus.com>
References: <200004160807.EAA10378@indy.delorie.com> <38FD3F8C.B30CA4BF@cygnus.com> <200004190745.DAA14311@indy.delorie.com>
X-SW-Source: 2000-04/msg00375.html
Content-length: 1020
Eli Zaretskii wrote:
>
> > It doesn't appear to affect the build
>
> Really? Did you try renaming your system-wide texinfo.tex (somewhere
> in the TeX installation tree)?
Hmm, ok, yes point taken :-)
> The special setting of TEXINPUTS before invoking TeX-related commands
> is there to make sure that the manual is produced using the specific
> version of texinfo.tex that was used by the maintainer(s), because
> another version of texinfo.tex might produce incorrect results or even
> fail. If you have the same or compatible version of texinfo.tex in
> another place where TeX can find it, you won't see the problems caused
> by TEXINPUTS being set incorrectly.
Its already been reported:
http://sourceware.cygnus.com/ml/bug-automake/1999/msg00007.html
and the follow up:
http://sourceware.cygnus.com/ml/bug-automake/1999/msg00019.html
claims:
> > TEXINPUTS should be a list of directories.
>
> Yup, this has been fixed in the CVS tree for quite some time.
I'll double check my automake tools.
Andrew
From ac131313@cygnus.com Wed Apr 19 02:07:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: David Whedon <davidw@gordian.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFC] Change configure.in so -W arnings match reality
Date: Wed, 19 Apr 2000 02:07:00 -0000
Message-id: <38FD76D9.A0975F97@cygnus.com>
References: <Pine.LNX.4.04.10004181444000.19907-100000@pcx08>
X-SW-Source: 2000-04/msg00376.html
Content-length: 2668
David Whedon wrote:
>
> I'm building the gdb 5.0 branch on our sgi and it has a problem with the
> warning flags.
>
> This error, I believe, is caused by this patch.
> ( http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00276.html )
> My problem would be fixed if -Wreturn-type is removed from gdb/configure.in
> (see the patch for more info)
>
> I think it is because I am using an old gcc (October '99)
That isn't old.
$ gcc --version
2.7.2.3
$ gcc -Wreturn-type hello.c
hello.c:2: warning: return-type defaults to `int'
is old :-) I'm actually slightly puzzled by this problem. The
-Wreturn-type option is very old.
Anyway, I've applied the attached to the branch. But _not_ the trunk.
Andrew
Wed Apr 19 18:05:24 2000 Andrew Cagney <cagney@b1.cygnus.com>
* configure.in (build_warnings): Default to warnings disabled.
* configure: Re-generate.
Index: configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.18.2.2
diff -p -r1.18.2.2 configure.in
*** configure.in 2000/04/14 10:40:00 1.18.2.2
--- configure.in 2000/04/19 08:59:55
*************** if test "${enable_netrom}" = "yes"; then
*** 482,489 ****
fi
! build_warnings="-Wimplicit -Wreturn-type -Wcomment -Wtrigraphs \
-Wformat -Wparentheses -Wpointer-arith"
# Not yet: -Wall -Wpointer-arith -Wstrict-prototypes
# -Wmissing-prototypes -Wmissing-declarations
AC_ARG_ENABLE(build-warnings,
--- 482,490 ----
fi
! default_build_warnings="-Wimplicit -Wreturn-type -Wcomment -Wtrigraphs \
-Wformat -Wparentheses -Wpointer-arith"
+ build_warnings=""
# Not yet: -Wall -Wpointer-arith -Wstrict-prototypes
# -Wmissing-prototypes -Wmissing-declarations
AC_ARG_ENABLE(build-warnings,
*************** AC_ARG_ENABLE(build-warnings,
*** 492,500 ****
yes) ;;
no) build_warnings="-w";;
,*) t=`echo "${enableval}" | sed -e "s/,/ /g"`
! build_warnings="${build_warnings} ${t}";;
*,) t=`echo "${enableval}" | sed -e "s/,/ /g"`
! build_warnings="${t} ${build_warnings}";;
*) build_warnings=`echo "${enableval}" | sed -e "s/,/ /g"`;;
esac
if test x"$silent" != x"yes" && test x"$build_warnings" != x""; then
--- 493,501 ----
yes) ;;
no) build_warnings="-w";;
,*) t=`echo "${enableval}" | sed -e "s/,/ /g"`
! build_warnings="${default_build_warnings} ${t}";;
*,) t=`echo "${enableval}" | sed -e "s/,/ /g"`
! build_warnings="${t} ${default_build_warnings}";;
*) build_warnings=`echo "${enableval}" | sed -e "s/,/ /g"`;;
esac
if test x"$silent" != x"yes" && test x"$build_warnings" != x""; then
From aoliva@cygnus.com Wed Apr 19 04:27:00 2000
From: Alexandre Oliva <aoliva@cygnus.com>
To: Jim Blandy <jimb@zwingli.cygnus.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: gdbarch IEEE_FLOAT
Date: Wed, 19 Apr 2000 04:27:00 -0000
Message-id: <orln2atjnx.fsf@zecarneiro.lsd.ic.unicamp.br>
References: <200004110302.WAA13962@zwingli.cygnus.com> <38F41405.8F24928@cygnus.com> <np7le0lcjb.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-04/msg00377.html
Content-length: 887
On Apr 14, 2000, Jim Blandy <jimb@zwingli.cygnus.com> wrote:
>> BTW, the need to add the below is going away soon. I've pending
>> multi-arch patches that will provide this as a non- multi-arch default.
>>
>> > + /* Provide a default value for IEEE_FLOAT. */
>> > + #ifndef IEEE_FLOAT
>> > + #define IEEE_FLOAT (0)
>> > + #endif
> Sounds great to me!
BTW, are you aware that gdbarch.c fails to compile on a single-arch
build whose target header file doesn't define IEEE_FLOAT? For
example, I've configured --target=mn10300-elf, and gdbarch.c won't
build because IEEE_FLOAT is not defined.
--
Alexandre Oliva Enjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
prev parent reply other threads:[~2000-04-19 1:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200004131903.VAA10696@reglos.regent.e-technik.tu-muenchen.de>
[not found] ` <38F66D15.A68BBB52@cygnus.com>
2000-04-14 6:54 ` Fernando Nasser
2000-04-19 1:02 ` Andrew Cagney [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=38FD673F.C5FFFAE4@cygnus.com \
--to=ac131313@cygnus.com \
--cc=Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE \
--cc=fnasser@redhat.com \
--cc=gdb-patches@sourceware.cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox