Re: Hopefully my last request for 5.0 incorporation

Re: Hopefully my last request for 5.0 incorporation

[Fernando Nasser]

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 jingham@cygnus.com Fri Apr 14 08:53:00 2000
From: James Ingham <jingham@cygnus.com>
To: Jonathan Larmour <jlarmour@redhat.co.uk>
Cc: James Ingham <jingham@cygnus.com>, Andrew Cagney <ac131313@cygnus.com>, insight@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Insight remote output doesn't output to console window immediately
Date: Fri, 14 Apr 2000 08:53:00 -0000
Message-id: <14583.16305.343648.795283@leda.cygnus.com>
References: <38F6404E.5959A4E0@redhat.co.uk> <38F65D4D.8B390EFA@cygnus.com> <38F67617.D1A2A6B3@redhat.co.uk> <14582.31502.754152.913822@leda.cygnus.com> <38F6873A.8284A61B@redhat.co.uk>
X-SW-Source: 2000-04/msg00288.html
Content-length: 765

Jonathan,

 > James Ingham wrote:
 > > 
 > > Okay, check this in.
 > 
 > Trunk, branch or both?

Both.  Maybe add a FIXME to the comment, since I often grep for FIXME
when I am trying to figure out what I should do next (though as I
said, this one is already on the short list.)

 >  
 > > As for the Changelog-gdbtk's.  They should be changed to just
 > > ChangeLog - the gdbtk is historic; the C-code files used to live at
 > > the top level, but since Insight couldn't be included in the FSF gdb
 > > releases, we had to have separate ChangeLogs...
 > 
 > Would you like me to rename those two then? Obviously not forgetting to
 > remove all the change-log-default-name emacs variables. That would be trunk
 > only of course.

That would be lovely, thanks.

Jim
From ezannoni@cygnus.com Fri Apr 14 09:17:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: jimb@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: [WITHDRAW PATCH] cleanup section_addr_info struct
Date: Fri, 14 Apr 2000 09:17:00 -0000
Message-id: <14583.17571.879578.797464@kwikemart.cygnus.com>
X-SW-Source: 2000-04/msg00289.html
Content-length: 133

Disregard the following patch:
http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00280.html

I'll submit a new one ASAP.

Elena
From taylor@cygnus.com Fri Apr 14 09:34:00 2000
From: David Taylor <taylor@cygnus.com>
To: Jim Blandy <jimb@zwingli.cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com, Jeff Law <law@cygnus.com>
Subject: Re: RFA: distinguish between pointers and addresses
Date: Fri, 14 Apr 2000 09:34:00 -0000
Message-id: <200004141633.MAA15832@texas.cygnus.com>
X-SW-Source: 2000-04/msg00290.html
Content-length: 875

    From: Jim Blandy <jimb@zwingli.cygnus.com>
    Date: Mon, 10 Apr 2000 15:22:35 -0500 (EST)

    The following patch needs approval from:
    - David Taylor       (the bulk of it)

Approved.

    - Andrew Cagney      (new gdbarch entries)
    - Michael Snyder     (tracepoint.c changes)
    - Jeff Law           (hppa-tdep.c changes)
    - Eli Zaretskii      (doc changes)
[...]
    This patch allows GDB to cope with machines where pointers are not
    simply byte addresses.  For example, some machines with small word
    sizes use word addresses for code pointers, to steal a few more
    address bits.  The D10V is such a processor; I think this patch makes
    it possible to replace all those ugly GDB_TARGET_IS_D10V conditionals
    in GDB's architecture-independent code with functions nicely isolated
    in d10v-tdep.c.

Such a clean up would be a good thing.

Re: Hopefully my last request for 5.0 incorporation

[Andrew Cagney]

[-- 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