Re: Include GDB/MI docs in GDB manual

Re: Include GDB/MI docs in GDB manual

[Dmitry Sivachenko]

Just one more thought:  we can make third book (GDB manual, GDB internals)
plus smth like 'GDB technicals' and include both annotate.texi and 
gdbmi.texi there.

Even if it will not be accepted,
I think it is bad idea to make a 'garbage heap' from the GDB manual,
mainly intended for regular GDB users, not 'GDB hackers'.
From shebs@apple.com Mon Apr 17 11:16:00 2000
From: Stan Shebs <shebs@apple.com>
To: Dmitry Sivachenko <dima@Chg.RU>
Cc: eliz@is.elta.co.il, gdb-patches@sourceware.cygnus.com
Subject: Re: Index in gdb.texinfo
Date: Mon, 17 Apr 2000 11:16:00 -0000
Message-id: <38FB54DC.9A7D3E8C@apple.com>
References: <200004162015.AAA39758@netserv1.chg.ru>
X-SW-Source: 2000-04/msg00332.html
Content-length: 819

Dmitry Sivachenko wrote:
> 
> > > -@kindex RET
> > > +@kindex @key{RET}
> >
> > I don't think it's a good idea to have @key in the index, it looks
> > awkward there.  Isn't @code{RET} good enough for the index?
> 
> We have 'complete (@key{TAB})' in Readline chapter.
> I thought we should markup RET in a similar manner.

Then how about including the command name, or a virtual command
name like "repeat (@key{RET})"?

> By the way, what people think about splitting Index into two parts:
> Concept index and Functions and Commands index (or smth similar)?

Hmmm.  The combined index isn't really that large, less than 10
pages, and it doesn't seem too hard to find the command names
in it.  I think we'd want to think about it at the 20-30 page
level, or if concept entries massively outnumber command entries.

Stan
From dima@Chg.RU Mon Apr 17 11:23:00 2000
From: Dmitry Sivachenko <dima@Chg.RU>
To: shebs@apple.com
Cc: eliz@is.elta.co.il, gdb-patches@sourceware.cygnus.com
Subject: Re: Index in gdb.texinfo
Date: Mon, 17 Apr 2000 11:23:00 -0000
Message-id: <200004171823.WAA66644@netserv1.chg.ru>
References: <200004162015.AAA39758@netserv1.chg.ru> <38FB54DC.9A7D3E8C@apple.com>
X-SW-Source: 2000-04/msg00333.html
Content-length: 797

   > We have 'complete (@key{TAB})' in Readline chapter.
   > I thought we should markup RET in a similar manner.

   Then how about including the command name, or a virtual command
   name like "repeat (@key{RET})"?

Sounds good for me.

   > By the way, what people think about splitting Index into two parts:
   > Concept index and Functions and Commands index (or smth similar)?

   Hmmm.  The combined index isn't really that large, less than 10
   pages, and it doesn't seem too hard to find the command names
   in it.  I think we'd want to think about it at the 20-30 page
   level, or if concept entries massively outnumber command entries.


In the translated version of manual it is better to have translated
part of Index separated from untranslated (command, functions, etc.)

--dima
From shebs@apple.com Mon Apr 17 11:31:00 2000
From: Stan Shebs <shebs@apple.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: [RFA] Include GDB/MI docs in GDB manual (was: Re: GDB 5 2000-03-29)
Date: Mon, 17 Apr 2000 11:31:00 -0000
Message-id: <38FB5864.1ADA6A08@apple.com>
References: <38E17D2C.F7EB65B9@cygnus.com> <200003312306.SAA07143@indy.delorie.com> <38E6945F.66938F0@cygnus.com> <200004160759.DAA10364@indy.delorie.com> <200004170823.EAA11690@indy.delorie.com>
X-SW-Source: 2000-04/msg00334.html
Content-length: 4978

Eli Zaretskii wrote:
> 
> What, no responses at all?  I'd expect a thousand flowers by now ;-)

OK...

  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
  (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
(*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*)
 |/  |/  |/  |/  |/  |/  |/  |/  |/  |/  |/  |/  |/  |/  |/  |/  |/  |/  |/  |/
\|  \|  \|  \|  \|  \|  \|  \|  \|  \|  \|  \|  \|  \|  \|  \|  \|  \|  \|  \|

> The message at the URL below includes the patches to make GDB/MI docs
> part of the GDB manual.  Please tell me if it's okay to commit.
> 
>  http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00309.html

Looks fine to me.  Since the MI is part of 5.0, we ought to have this
bit of the manual in it too, so people know about it.

Stan
From shebs@apple.com Mon Apr 17 11:50:00 2000
From: Stan Shebs <shebs@apple.com>
To: Dmitry Sivachenko <dima@Chg.RU>
Cc: eliz@delorie.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Include GDB/MI docs in GDB manual
Date: Mon, 17 Apr 2000 11:50:00 -0000
Message-id: <38FB5CE4.6B79E410@apple.com>
References: <200004170956.NAA55866@netserv1.chg.ru>
X-SW-Source: 2000-04/msg00335.html
Content-length: 1710

Dmitry Sivachenko wrote:
> 
> I think it is not good thing to include gdbmi.texinfo into
> GDB manual.  It contains very technical issues, which regular users
> would not be happy to see in the Manual.
> GDB manual should contain things which describe using of the debugger
> from the users's point of view.

You're right that the MI interface is not obviously part of the
regular manual.  But after thinking about it for awhile, considering
the alternatives, and looking at other manuals, it seemed that the
user manual was the best home.

The MI is one of the interfaces presented by GDB.  In that respect
it is similar to annotations, which we also added docs for recently,
and the remote protocol, which has been documented in the manual
for a long time - along with C programming hints for the stub.
The MI is at least as appropriate as these other examples.

The MI audience is narrow, namely people building GUIs that use GDB.
But we also document commands like "target dink32", for which I can
assure you the audience is even narrower!

Multiple manuals are more work to maintain, and historically they
seem to result in more style and sync problems.

The GCC manual actually includes full porting instructions, which
goes well outside being just a user's manual.  However, I've long
wondered if that actually encourages people to start on GCC ports;
certainly when I started working with GCC in 1989, having that
info in the main manual smoothed the way.  One of the underlying
goals for the GNU project is to encourage the creation of more
free software, and so it's a good idea to have programmer-oriented
manuals that encourage and inform programmers about all the avenues
for adding to GNU.

Stan
From jlarmour@redhat.co.uk Mon Apr 17 13:07:00 2000
From: Jonathan Larmour <jlarmour@redhat.co.uk>
To: James Ingham <jingham@cygnus.com>
Cc: insight@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Insight remote output doesn't output to console window immediately
Date: Mon, 17 Apr 2000 13:07:00 -0000
Message-id: <38FB6EEC.D2521EBC@redhat.co.uk>
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> <14583.16305.343648.795283@leda.cygnus.com>
X-SW-Source: 2000-04/msg00336.html
Content-length: 7576

James Ingham wrote:
> 
> 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.)

I've added a FIXME comment now.

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

I'll check in the attached patch to the trunk only once you say so. I added
ChangeLog entries:

2000-04-17  Jonathan Larmour  <jlarmour@redhat.co.uk>
 
        * ChangeLog-gdbtk: Renamed to ChangeLog
        * ChangeLog: New file
        * README.GDBTK: No need for changelog-default-name hint for Emacs
now

generic/ChangeLog
2000-04-17  Jonathan Larmour  <jlarmour@redhat.co.uk>
 
        * ChangeLog-gdbtk: Renamed to ChangeLog
        * ChangeLog: New file
        * gdbtk-cmds.c, gdbtk-hooks.c, gdbtk-variable.c, gdbtk-varobj.c,
        gdbtk-wrapper.h, gdbtk-wrapper.c, gdbtk.h, gdbtk.c: No need for
        changelog-default-name hint for Emacs now

I was tempted to just go ahead check this in, but I'm erring on the side of
caution.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault
cvs server: ChangeLog is a new entry, no comparison available
cvs server: ChangeLog-gdbtk was removed, no comparison available
Index: README.GDBTK
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/README.GDBTK,v
retrieving revision 1.1.1.1
diff -u -5 -p -r1.1.1.1 README.GDBTK
--- README.GDBTK	2000/02/07 00:19:42	1.1.1.1
+++ README.GDBTK	2000/04/17 20:05:43
@@ -396,8 +396,5 @@ m68k-hp-hpux9.00:
 		. 
 		. 
 		. 
 
 
-/* Local variables: */
-/* change-log-default-name: "ChangeLog-gdbtk" */
-/* End: */
cvs server: generic/ChangeLog is a new entry, no comparison available
cvs server: generic/ChangeLog-gdbtk was removed, no comparison available
Index: generic/gdbtk-cmds.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-cmds.c,v
retrieving revision 1.6
diff -u -5 -p -r1.6 gdbtk-cmds.c
--- generic/gdbtk-cmds.c	2000/04/03 21:29:00	1.6
+++ generic/gdbtk-cmds.c	2000/04/17 20:05:45
@@ -4698,10 +4698,6 @@ setup_architecture_data ()
 {
   /* don't trust REGISTER_BYTES to be zero. */
   old_regs = xmalloc (REGISTER_BYTES + 1);
   memset (old_regs, 0, REGISTER_BYTES + 1);
 }
-\f
 
-/* Local variables: */
-/* change-log-default-name: "ChangeLog-gdbtk" */
-/* End: */
Index: generic/gdbtk-hooks.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-hooks.c,v
retrieving revision 1.3
diff -u -5 -p -r1.3 gdbtk-hooks.c
--- generic/gdbtk-hooks.c	2000/04/03 21:29:00	1.3
+++ generic/gdbtk-hooks.c	2000/04/17 20:05:45
@@ -905,8 +905,6 @@ gdbtk_detach ()
   if (Tcl_Eval (gdbtk_interp, "gdbtk_detached") != TCL_OK)
     {
       report_error ();
     }
 }
-/* Local variables: */
-/* change-log-default-name: "ChangeLog-gdbtk" */
-/* End: */
+
Index: generic/gdbtk-variable.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-variable.c,v
retrieving revision 1.1.1.1
diff -u -5 -p -r1.1.1.1 gdbtk-variable.c
--- generic/gdbtk-variable.c	2000/02/07 00:19:42	1.1.1.1
+++ generic/gdbtk-variable.c	2000/04/17 20:05:46
@@ -2409,9 +2409,6 @@ java_value_of_variable (var, obj)
      gdb_variable *var;
      Tcl_Obj **obj;
 {
   return cplus_value_of_variable (var, obj);
 }
-\f
-/* Local variables: */
-/* change-log-default-name: "ChangeLog-gdbtk" */
-/* End: */
+
Index: generic/gdbtk-varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-varobj.c,v
retrieving revision 1.2
diff -u -5 -p -r1.2 gdbtk-varobj.c
--- generic/gdbtk-varobj.c	2000/03/13 21:51:45	1.2
+++ generic/gdbtk-varobj.c	2000/04/17 20:05:46
@@ -627,9 +627,6 @@ uninstall_variable (interp, varname)
      Tcl_Interp *interp;
      char *varname;
 {
   Tcl_DeleteCommand (interp, varname);
 }
-\f
-/* Local variables: */
-/* change-log-default-name: "ChangeLog-gdbtk" */
-/* End: */
+
Index: generic/gdbtk-wrapper.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-wrapper.c,v
retrieving revision 1.2
diff -u -5 -p -r1.2 gdbtk-wrapper.c
--- generic/gdbtk-wrapper.c	2000/02/24 03:11:47	1.2
+++ generic/gdbtk-wrapper.c	2000/04/17 20:05:46
@@ -826,11 +826,6 @@ wrap_get_current_frame (char *opaque_arg
   struct gdb_wrapper_arguments **args = (struct gdb_wrapper_arguments **) opaque_arg;
 
   (*args)->result = (char *) get_current_frame ();
   return 1;
 }
-\f
 
-
-/* Local variables: */
-/* change-log-default-name: "ChangeLog-gdbtk" */
-/* End: */
Index: generic/gdbtk-wrapper.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-wrapper.h,v
retrieving revision 1.2
diff -u -5 -p -r1.2 gdbtk-wrapper.h
--- generic/gdbtk-wrapper.h	2000/02/24 03:11:47	1.2
+++ generic/gdbtk-wrapper.h	2000/04/17 20:05:46
@@ -73,9 +73,6 @@ extern gdb_result GDB_get_next_frame PAR
 extern gdb_result GDB_find_relative_frame PARAMS ((struct frame_info *fi,
 						   int *start,
 						   struct frame_info **result));
 extern gdb_result GDB_get_current_frame PARAMS ((struct frame_info **result));
 #endif /* GDBTK_WRAPPER_H */
-\f
-/* Local variables: */
-/* change-log-default-name: "ChangeLog-gdbtk" */
-/* End: */
+
Index: generic/gdbtk.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk.c,v
retrieving revision 1.2
diff -u -5 -p -r1.2 gdbtk.c
--- generic/gdbtk.c	2000/04/14 08:04:46	1.2
+++ generic/gdbtk.c	2000/04/17 20:05:46
@@ -528,11 +528,12 @@ gdbtk_find_main";
 
     /* fputs_unfiltered_hook = NULL; *//* Force errors to stdout/stderr */
 
     fputs_unfiltered_hook = gdbtk_fputs;
 
-    /* set gdb_stdtarg for now until gdbtk is changed to use struct ui_out. */
+    /* FIXME: set gdb_stdtarg for now until gdbtk is changed to use
+       struct ui_out. */
 
     gdb_stdtarg = gdb_stdout;
 
     if (Tcl_GlobalEval (gdbtk_interp, (char *) script) != TCL_OK)
       {
@@ -653,9 +654,6 @@ tk_command (cmd, from_tty)
 
   printf_unfiltered ("%s\n", result);
 
   do_cleanups (old_chain);
 }
-\f
-/* Local variables: */
-/* change-log-default-name: "ChangeLog-gdbtk" */
-/* End: */
+
Index: generic/gdbtk.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk.h,v
retrieving revision 1.2
diff -u -5 -p -r1.2 gdbtk.h
--- generic/gdbtk.h	2000/04/03 21:29:00	1.2
+++ generic/gdbtk.h	2000/04/17 20:05:46
@@ -178,9 +178,5 @@ extern void
 
 /* gdbtk_add_hooks - add all the hooks to gdb.  This will get called
    by the startup code to fill in the hooks needed by core gdb. */
 extern void gdbtk_add_hooks (void);
 
-\f
-/* Local variables: */
-/* change-log-default-name: "ChangeLog-gdbtk" */
-/* End: */
From jingham@cygnus.com Mon Apr 17 13:16:00 2000
From: James Ingham <jingham@cygnus.com>
To: Jonathan Larmour <jlarmour@redhat.co.uk>
Cc: James Ingham <jingham@cygnus.com>, insight@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Insight remote output doesn't output to console window immediately
Date: Mon, 17 Apr 2000 13:16:00 -0000
Message-id: <14587.29099.5122.345649@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> <14583.16305.343648.795283@leda.cygnus.com> <38FB6EEC.D2521EBC@redhat.co.uk>
X-SW-Source: 2000-04/msg00337.html
Content-length: 8319

Jonathan,

This looks fine to me.  Check it in.

Jim

 > James Ingham wrote:
 > > 
 > > 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.)
 > 
 > I've added a FIXME comment now.
 > 
 > >  >
 > >  > > 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.
 > 
 > I'll check in the attached patch to the trunk only once you say so. I added
 > ChangeLog entries:
 > 
 > 2000-04-17  Jonathan Larmour  <jlarmour@redhat.co.uk>
 >  
 >         * ChangeLog-gdbtk: Renamed to ChangeLog
 >         * ChangeLog: New file
 >         * README.GDBTK: No need for changelog-default-name hint for Emacs
 > now
 > 
 > generic/ChangeLog
 > 2000-04-17  Jonathan Larmour  <jlarmour@redhat.co.uk>
 >  
 >         * ChangeLog-gdbtk: Renamed to ChangeLog
 >         * ChangeLog: New file
 >         * gdbtk-cmds.c, gdbtk-hooks.c, gdbtk-variable.c, gdbtk-varobj.c,
 >         gdbtk-wrapper.h, gdbtk-wrapper.c, gdbtk.h, gdbtk.c: No need for
 >         changelog-default-name hint for Emacs now
 > 
 > I was tempted to just go ahead check this in, but I'm erring on the side of
 > caution.
 > 
 > Jifl
 > -- 
 > Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
 > "Plan to be spontaneous tomorrow."  ||  These opinions are all my own faultcvs server: ChangeLog is a new entry, no comparison available
 > cvs server: ChangeLog-gdbtk was removed, no comparison available
 > Index: README.GDBTK
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/gdbtk/README.GDBTK,v
 > retrieving revision 1.1.1.1
 > diff -u -5 -p -r1.1.1.1 README.GDBTK
 > --- README.GDBTK	2000/02/07 00:19:42	1.1.1.1
 > +++ README.GDBTK	2000/04/17 20:05:43
 > @@ -396,8 +396,5 @@ m68k-hp-hpux9.00:
 >  		. 
 >  		. 
 >  		. 
 >  
 >  
 > -/* Local variables: */
 > -/* change-log-default-name: "ChangeLog-gdbtk" */
 > -/* End: */
 > cvs server: generic/ChangeLog is a new entry, no comparison available
 > cvs server: generic/ChangeLog-gdbtk was removed, no comparison available
 > Index: generic/gdbtk-cmds.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-cmds.c,v
 > retrieving revision 1.6
 > diff -u -5 -p -r1.6 gdbtk-cmds.c
 > --- generic/gdbtk-cmds.c	2000/04/03 21:29:00	1.6
 > +++ generic/gdbtk-cmds.c	2000/04/17 20:05:45
 > @@ -4698,10 +4698,6 @@ setup_architecture_data ()
 >  {
 >    /* don't trust REGISTER_BYTES to be zero. */
 >    old_regs = xmalloc (REGISTER_BYTES + 1);
 >    memset (old_regs, 0, REGISTER_BYTES + 1);
 >  }
 > -\f
 >  
 > -/* Local variables: */
 > -/* change-log-default-name: "ChangeLog-gdbtk" */
 > -/* End: */
 > Index: generic/gdbtk-hooks.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-hooks.c,v
 > retrieving revision 1.3
 > diff -u -5 -p -r1.3 gdbtk-hooks.c
 > --- generic/gdbtk-hooks.c	2000/04/03 21:29:00	1.3
 > +++ generic/gdbtk-hooks.c	2000/04/17 20:05:45
 > @@ -905,8 +905,6 @@ gdbtk_detach ()
 >    if (Tcl_Eval (gdbtk_interp, "gdbtk_detached") != TCL_OK)
 >      {
 >        report_error ();
 >      }
 >  }
 > -/* Local variables: */
 > -/* change-log-default-name: "ChangeLog-gdbtk" */
 > -/* End: */
 > +
 > Index: generic/gdbtk-variable.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-variable.c,v
 > retrieving revision 1.1.1.1
 > diff -u -5 -p -r1.1.1.1 gdbtk-variable.c
 > --- generic/gdbtk-variable.c	2000/02/07 00:19:42	1.1.1.1
 > +++ generic/gdbtk-variable.c	2000/04/17 20:05:46
 > @@ -2409,9 +2409,6 @@ java_value_of_variable (var, obj)
 >       gdb_variable *var;
 >       Tcl_Obj **obj;
 >  {
 >    return cplus_value_of_variable (var, obj);
 >  }
 > -\f
 > -/* Local variables: */
 > -/* change-log-default-name: "ChangeLog-gdbtk" */
 > -/* End: */
 > +
 > Index: generic/gdbtk-varobj.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-varobj.c,v
 > retrieving revision 1.2
 > diff -u -5 -p -r1.2 gdbtk-varobj.c
 > --- generic/gdbtk-varobj.c	2000/03/13 21:51:45	1.2
 > +++ generic/gdbtk-varobj.c	2000/04/17 20:05:46
 > @@ -627,9 +627,6 @@ uninstall_variable (interp, varname)
 >       Tcl_Interp *interp;
 >       char *varname;
 >  {
 >    Tcl_DeleteCommand (interp, varname);
 >  }
 > -\f
 > -/* Local variables: */
 > -/* change-log-default-name: "ChangeLog-gdbtk" */
 > -/* End: */
 > +
 > Index: generic/gdbtk-wrapper.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-wrapper.c,v
 > retrieving revision 1.2
 > diff -u -5 -p -r1.2 gdbtk-wrapper.c
 > --- generic/gdbtk-wrapper.c	2000/02/24 03:11:47	1.2
 > +++ generic/gdbtk-wrapper.c	2000/04/17 20:05:46
 > @@ -826,11 +826,6 @@ wrap_get_current_frame (char *opaque_arg
 >    struct gdb_wrapper_arguments **args = (struct gdb_wrapper_arguments **) opaque_arg;
 >  
 >    (*args)->result = (char *) get_current_frame ();
 >    return 1;
 >  }
 > -\f
 >  
 > -
 > -/* Local variables: */
 > -/* change-log-default-name: "ChangeLog-gdbtk" */
 > -/* End: */
 > Index: generic/gdbtk-wrapper.h
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-wrapper.h,v
 > retrieving revision 1.2
 > diff -u -5 -p -r1.2 gdbtk-wrapper.h
 > --- generic/gdbtk-wrapper.h	2000/02/24 03:11:47	1.2
 > +++ generic/gdbtk-wrapper.h	2000/04/17 20:05:46
 > @@ -73,9 +73,6 @@ extern gdb_result GDB_get_next_frame PAR
 >  extern gdb_result GDB_find_relative_frame PARAMS ((struct frame_info *fi,
 >  						   int *start,
 >  						   struct frame_info **result));
 >  extern gdb_result GDB_get_current_frame PARAMS ((struct frame_info **result));
 >  #endif /* GDBTK_WRAPPER_H */
 > -\f
 > -/* Local variables: */
 > -/* change-log-default-name: "ChangeLog-gdbtk" */
 > -/* End: */
 > +
 > Index: generic/gdbtk.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk.c,v
 > retrieving revision 1.2
 > diff -u -5 -p -r1.2 gdbtk.c
 > --- generic/gdbtk.c	2000/04/14 08:04:46	1.2
 > +++ generic/gdbtk.c	2000/04/17 20:05:46
 > @@ -528,11 +528,12 @@ gdbtk_find_main";
 >  
 >      /* fputs_unfiltered_hook = NULL; *//* Force errors to stdout/stderr */
 >  
 >      fputs_unfiltered_hook = gdbtk_fputs;
 >  
 > -    /* set gdb_stdtarg for now until gdbtk is changed to use struct ui_out. */
 > +    /* FIXME: set gdb_stdtarg for now until gdbtk is changed to use
 > +       struct ui_out. */
 >  
 >      gdb_stdtarg = gdb_stdout;
 >  
 >      if (Tcl_GlobalEval (gdbtk_interp, (char *) script) != TCL_OK)
 >        {
 > @@ -653,9 +654,6 @@ tk_command (cmd, from_tty)
 >  
 >    printf_unfiltered ("%s\n", result);
 >  
 >    do_cleanups (old_chain);
 >  }
 > -\f
 > -/* Local variables: */
 > -/* change-log-default-name: "ChangeLog-gdbtk" */
 > -/* End: */
 > +
 > Index: generic/gdbtk.h
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk.h,v
 > retrieving revision 1.2
 > diff -u -5 -p -r1.2 gdbtk.h
 > --- generic/gdbtk.h	2000/04/03 21:29:00	1.2
 > +++ generic/gdbtk.h	2000/04/17 20:05:46
 > @@ -178,9 +178,5 @@ extern void
 >  
 >  /* gdbtk_add_hooks - add all the hooks to gdb.  This will get called
 >     by the startup code to fill in the hooks needed by core gdb. */
 >  extern void gdbtk_add_hooks (void);
 >  
 > -\f
 > -/* Local variables: */
 > -/* change-log-default-name: "ChangeLog-gdbtk" */
 > -/* End: */
From ac131313@cygnus.com Tue Apr 18 00:50:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: sim/d10v, fix SIGILL behavour
Date: Tue, 18 Apr 2000 00:50:00 -0000
Message-id: <38FC138D.850FE2E1@cygnus.com>
X-SW-Source: 2000-04/msg00338.html
Content-length: 2497

FYI,

I've committed the attatched.  For the curious, it allows the user to
step through a reserved instruction exception when using the simulator.

	Andrew
Tue Apr 18 16:26:41 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* interp.c (sim_resume): Deliver SIGILL.
	(lookup_hash): Do not print SIGILL message.

Tue Apr 18 16:32:07 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* t-rie-xx.s (test_rie_xx): New test.
	* Makefile.in (TESTS): Update.

Index: d10v/interp.c
===================================================================
RCS file: /cvs/cvsfiles/devo/sim/d10v/interp.c,v
retrieving revision 1.51.4.13
diff -p -r1.51.4.13 interp.c
*** interp.c	2000/02/23 07:27:42	1.51.4.13
--- interp.c	2000/04/18 07:21:24
*************** lookup_hash (ins, size)
*** 99,106 ****
      {
        if (h->next == NULL)
  	{
- 	  (*d10v_callback->printf_filtered)
- 	    (d10v_callback, "ERROR: Illegal instruction %x at PC %x\n", ins, PC);
  	  State.exception = SIGILL;
  	  State.pc_changed = 1; /* Don't increment the PC. */
  	  return NULL;
--- 99,104 ----
*************** sim_resume (sd, step, siggnal)
*** 977,982 ****
--- 975,987 ----
        SET_BPSW (PSW);
        SET_HW_PSW ((PSW & (PSW_F0_BIT | PSW_F1_BIT | PSW_C_BIT)));
        JMP (AE_VECTOR_START);
+       SLOT_FLUSH ();
+       break;
+     case SIGILL:
+       SET_BPC (PC);
+       SET_BPSW (PSW);
+       SET_HW_PSW ((PSW & (PSW_F0_BIT | PSW_F1_BIT | PSW_C_BIT)));
+       JMP (RIE_VECTOR_START);
        SLOT_FLUSH ();
        break;
      default:
Index: testsuite/d10v-elf/Makefile.in
===================================================================
RCS file: /cvs/cvsfiles/devo/sim/testsuite/d10v-elf/Makefile.in,v
retrieving revision 1.16.2.2
diff -p -r1.16.2.2 Makefile.in
*** Makefile.in	2000/02/23 07:30:13	1.16.2.2
--- Makefile.in	2000/04/18 07:21:27
*************** TESTS = \
*** 82,87 ****
--- 82,88 ----
  	t-ae-st2w-im.ok \
  	t-ae-st2w-ip.ok \
  	t-ae-st2w-is.ok \
+ 	t-rie-xx.ok \
  #
  
  AS_FOR_TARGET = `\
Index: testsuite/d10v-elf/t-rie-xx.s
===================================================================
RCS file: t-rie-xx.s
diff -N t-rie-xx.s
*** /dev/null	Tue May  5 13:32:27 1998
--- t-rie-xx.s	Tue Apr 18 00:21:27 2000
***************
*** 0 ****
--- 1,12 ----
+ .include "t-macros.i"
+ 
+ 	start
+ 
+ 	PSW_BITS = 0
+ 	point_dmap_at_imem
+ 	check_interrupt (VEC_RIE&DMAP_MASK)+DMAP_BASE PSW_BITS test_rie_xx
+ 	
+ test_rie_xx:
+         .short 0xe120, 0x0000  ;; Example of RIE code
+ 	nop
+ 	exit47
From ac131313@cygnus.com Tue Apr 18 01:02:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [PATCH/5] Don't delete gdb/testsuite/gdb.mi/testcmds
Date: Tue, 18 Apr 2000 01:02:00 -0000
Message-id: <38FC165E.DE02E720@cygnus.com>
X-SW-Source: 2000-04/msg00339.html
Content-length: 1110

FYI,

I've committed the attatched.  I suspect the test that went with
testcmds never made it onto sourceware?  Perhaphs something to add to
the trunk.

	Andrew
Tue Apr 18 15:36:07 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* Makefile.in (clean mostlyclean): Do not delete $(MISCELLANEOUS).

Index: testsuite/gdb.mi/Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/Makefile.in,v
retrieving revision 1.2
diff -p -r1.2 Makefile.in
*** Makefile.in	2000/03/14 05:02:03	1.2
--- Makefile.in	2000/04/18 07:03:09
*************** all: 
*** 11,17 ****
  #### host, target, and site specific Makefile frags come in here.
  
  clean mostlyclean:
! 	-rm -f *.ci *.o $(OBJS) $(PROGS) $(MISCELLANEOUS) *~ core
  
  distclean maintainer-clean realclean: clean
  	-rm -f Makefile config.status config.log
--- 11,17 ----
  #### host, target, and site specific Makefile frags come in here.
  
  clean mostlyclean:
! 	-rm -f *.ci *.o $(OBJS) $(PROGS) *~ core
  
  distclean maintainer-clean realclean: clean
  	-rm -f Makefile config.status config.log
From ac131313@cygnus.com Tue Apr 18 01:06:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [PATCH/5] Add cleanups to gdb/tui/Makefile.in
Date: Tue, 18 Apr 2000 01:06:00 -0000
Message-id: <38FC1754.6A7A1BF5@cygnus.com>
X-SW-Source: 2000-04/msg00340.html
Content-length: 879

FYI,

I've committed the attatched to both the trunk and the branch.  Thanks
to Eli for finding this.

	Andrew
Tue Apr 18 15:32:15 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* Makefile.in (distclean, maintainer-clean, realclean,
 	mostlyclean): New targets.

Index: tui/Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/tui/Makefile.in,v
retrieving revision 1.1.1.1
diff -p -r1.1.1.1 Makefile.in
*** Makefile.in	1999/04/16 01:34:12	1.1.1.1
--- Makefile.in	2000/04/18 07:02:57
*************** tuiInit.c: $(SOURCES)
*** 164,168 ****
  	@echo '}' >>init.c-tmp
  	@mv init.c-tmp tuiInit.c
  
! clean:
! 	rm -f *.o *.a
--- 164,171 ----
  	@echo '}' >>init.c-tmp
  	@mv init.c-tmp tuiInit.c
  
! clean mostlyclean:
! 	-rm -f *.o *.a
! 
! distclean maintainer-clean realclean: clean
! 	-rm -f Makefile config.log config.cache
From ac131313@cygnus.com Tue Apr 18 01:13: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: Tue, 18 Apr 2000 01:13:00 -0000
Message-id: <38FC18BA.61DB4A58@cygnus.com>
References: <200004160807.EAA10378@indy.delorie.com>
X-SW-Source: 2000-04/msg00341.html
Content-length: 1064

Eli Zaretskii wrote:
> 
> I have few problems with the 20000412 snapshot:
> 
> 1) It includes several changes in bfd/doc/Makefile.in which look like
>    this:
> 
>      .texi.dvi:
>     -   TEXINPUTS=$(top_srcdir)/../texinfo:$$TEXINPUTS \
>     +   TEXINPUTS=$(top_srcdir)/../texinfo/texinfo.tex:$$TEXINPUTS \
>               MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) $<
> 
>    This change is *wrong*.  The TEXINPUTS variable should point to a list
>    of directories, not a list of files.
> 
>    Is it a bug in Automake?

I've not yet looked at this.
(Ian, FYI, this also appears in the trunk)

> 2) The diffs include files that AFAIK shouldn't be there:
>    dejagnu/example/calc/config.log, dejagnu/example/calc/config.status,
>    gdb/tui/Makefile, intl/config.status.  I think these files are also
>    in md5.sum, which also seems wrong.

FYI,  I've so far fixed gdb/tui/Makefile (and another gdb/* bug).  I'm
still testing my dejagnu fix and have not yet checked the intl/* problem
but suspect it is straightforward.

Hopefully tomorrow.

	Andrew
From eliz@delorie.com Tue Apr 18 02:02:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: dima@Chg.RU
Cc: davidw@gordian.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Include GDB/MI docs in GDB manual
Date: Tue, 18 Apr 2000 02:02:00 -0000
Message-id: <200004180901.FAA13035@indy.delorie.com>
References: <Pine.LNX.4.04.10004170753370.19907-100000@pcx08> <200004171555.TAA63783@netserv1.chg.ru>
X-SW-Source: 2000-04/msg00342.html
Content-length: 1274

Date: Mon, 17 Apr 2000 19:55:58 +0400 (MSD)
From: Dmitry Sivachenko <dima@Chg.RU>

> I think it is bad idea to make a 'garbage heap' from the GDB manual,
> mainly intended for regular GDB users, not 'GDB hackers'.

I tend to the opposite ;-)

I think that, ideally, the documentation should include everything in
a single place.  If properly indexed, such a document, however large,
is a handy tool for finding any issue your are after, in a fast and
efficient way.

In contrast, cross-references between different manuals are usually
rare, and the facilities for searching multiple documents are abysmally
more primitive (and mostly unknown and unused) than what you have for
searching a single Info document.

Here's a simple demonstration: the GDB manual does not have a single
reference to the GDB Internals manual.  How do we expect a user who
reads gdb.info to know that more docs about GDB is available
elsewhere?

Btw, the fact that "make install" in the GDB distro doesn't install
the Info docs, unlike any other GNU project I've seen, actually makes
it more probable that gdbint.info will not be installed anywhere along
INFOPATH.  So even advanced features like "info --apropos" (how many
people around here even know about the --apropos switch?) might not
help.
From eliz@delorie.com Tue Apr 18 02:04:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: dima@Chg.RU
Cc: shebs@apple.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Index in gdb.texinfo
Date: Tue, 18 Apr 2000 02:04:00 -0000
Message-id: <200004180903.FAA13044@indy.delorie.com>
References: <200004162015.AAA39758@netserv1.chg.ru> <38FB54DC.9A7D3E8C@apple.com> <200004171823.WAA66644@netserv1.chg.ru>
X-SW-Source: 2000-04/msg00343.html
Content-length: 1564

Date: Mon, 17 Apr 2000 22:23:12 +0400 (MSD)
From: Dmitry Sivachenko <dima@Chg.RU>

>    > We have 'complete (@key{TAB})' in Readline chapter.
>    > I thought we should markup RET in a similar manner.
> 
>    Then how about including the command name, or a virtual command
>    name like "repeat (@key{RET})"?
> 
> Sounds good for me.

Based on discussions with Stan by private mail, I intend to change all
of the commands in the way Stan suggested above.  So RET will get the
same treatment.

I just need the thumbs-up from Stan to make this and other changes we
talked about, to get this done.  Most of the changes are already ready
on my disk.

> In the translated version of manual it is better to have translated
> part of Index separated from untranslated (command, functions, etc.)

This is an issue that no GNU manual currently handles correctly.  The
main problem is the sorting order, AFAIK, but a plethora of other
issues pop up as well.

You can easily separate the indices if you comment away the
@syncodeindex directives at the beginning of gdb.texinfo.

Sorting the entries will also effectively separate translated and
untranslated entries.

But by and large, this issue was not attacked by Texinfo yet.  You
could say that non-ASCII support in Texinfo is nothing more than a
kludgey hack, unfortunately.  I don't think we should expect GDB to
solve this ;-)

However, I do suggest to take these issues up with bug-texinfo mailing
list.  I think those who work on Texinfo should at least be aware of
the problem, if not start working on solutions.
From law@cygnus.com Tue Apr 18 11:00:00 2000
From: Jeffrey A Law <law@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: distinguish between pointers and addresses 
Date: Tue, 18 Apr 2000 11:00:00 -0000
Message-id: <2629.956053147@upchuck>
References: <np66tklb97.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-04/msg00344.html
Content-length: 406

  In message < np66tklb97.fsf@zwingli.cygnus.com >you write:
  > 
  > I've committed this patch, with everyone's approval but Jeff Law.  The
  > hppa-tdep.c changes are cosmetic, so I think it'll be okay.
FYI -- I'm on the road right now.  I trust your judgement on this stuff
to DTRT.  Thanks for taking care of it.

Sorry everyone, I should have put a .vacation auto-responder on my
mail address.


jeff
From jimb@zwingli.cygnus.com Tue Apr 18 11:46:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: "Philippe De Muyter" <phdm@macqel.be>
Cc: gdb-patches@sourceware.cygnus.com (gdb-patches@sourceware.cygnus.com)
Subject: Re: RFA free(NULL) in bcache.c
Date: Tue, 18 Apr 2000 11:46:00 -0000
Message-id: <npvh1fp7qw.fsf@zwingli.cygnus.com>
References: <200004120905.LAA10853@mail.macqel.be>
X-SW-Source: 2000-04/msg00345.html
Content-length: 863

Yes, please do.  Thanks.

> I recently have had a core dump there, and the other instance of
> `free (bcache->bucket)' in bache.c is protected against `free (NULL)', so
> I think this is safe.  OK to commit ?
> 
> Philippe De Muyter  <phdm@macqel.be>
> 
> 	* bcache.c (free_bcache): Do not free NULL.
> 
> Index: gdb/bcache.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/bcache.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 bcache.c
> --- bcache.c	2000/02/08 04:39:01	1.2
> +++ bcache.c	2000/04/12 08:52:26
> @@ -189,7 +189,8 @@ void
>  free_bcache (struct bcache *bcache)
>  {
>    obstack_free (&bcache->cache, 0);
> -  free (bcache->bucket);
> +  if (bcache->bucket)
> +    free (bcache->bucket);
>  
>    /* This isn't necessary, but at least the bcache is always in a
>       consistent state.  */
> 
From jimb@zwingli.cygnus.com Tue Apr 18 11:52:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: gdbarch IEEE_FLOAT
Date: Tue, 18 Apr 2000 11:52:00 -0000
Message-id: <npu2gzp7hf.fsf@zwingli.cygnus.com>
References: <200004110302.WAA13962@zwingli.cygnus.com> <38F41405.8F24928@cygnus.com> <np7le0lcjb.fsf@zwingli.cygnus.com> <38FA86D1.2E4CB93D@cygnus.com>
X-SW-Source: 2000-04/msg00346.html
Content-length: 679

> > > > + /* Provide a default value for IEEE_FLOAT.  */
> > > > + #ifndef IEEE_FLOAT
> > > > + #define IEEE_FLOAT (0)
> > > > + #endif
> > 
> > Sounds great to me!
> 
> BTW, is the default ``0'' or ``1''?  The above has zero, but for
> multi-arch it is set to one.  (Just let me know, I'll tweek it when I
> remove it :-).

Well, for old targets it has to be zero.

I was thinking that, for new gdbarch-style targets, 1 was the more
convenient default, but on more careful reflection, I'm not sure
that's smart: if someone is converting an existing port to gdbarch, it
would be very confusing for IEEE_FLOAT to suddenly change its default
value.

So the default should be zero.
From jimb@zwingli.cygnus.com Tue Apr 18 11:56:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: Jim Blandy <jimb@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] (try #2) cleanup section_addr_info struct
Date: Tue, 18 Apr 2000 11:56:00 -0000
Message-id: <npsnwjp7at.fsf@zwingli.cygnus.com>
References: <14583.21953.458777.593608@kwikemart.cygnus.com> <npzoqwju50.fsf@zwingli.cygnus.com> <14583.37982.780037.231156@kwikemart.cygnus.com>
X-SW-Source: 2000-04/msg00347.html
Content-length: 371

>  > Approved, with one change:
>  > 
>  > Could you rename the only remaining member of `struct
>  > section_addr_info' to `sections'?  It's kind of odd to have a
>  > structure with only one member, named `other'.  :)
>  > 
> 
> I was thinking of doing that in another commit, so that the cosmetic
> and functional changes would be distinct.

Okay, however you please.
From jimb@zwingli.cygnus.com Tue Apr 18 12:54:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: Document RETURN_VALUE_ON_STACK
Date: Tue, 18 Apr 2000 12:54:00 -0000
Message-id: <200004181954.OAA08866@zwingli.cygnus.com>
X-SW-Source: 2000-04/msg00348.html
Content-length: 1108

Is this okay?

Index: gdbint.texinfo
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/doc/gdbint.texinfo,v
retrieving revision 1.151
diff -c -c -r1.151 gdbint.texinfo
*** gdbint.texinfo	2000/04/16 14:54:43	1.151
--- gdbint.texinfo	2000/04/18 19:53:19
***************
*** 1875,1880 ****
--- 1875,1888 ----
  form.
  @xref{Target Architecture Definition, , Using Different Register and Memory Data Representations}.
  
+ @item RETURN_VALUE_ON_STACK(@var{type})
+ Return non-zero if values of type TYPE are returned on the stack, using
+ the ``struct convention''.  GDB assumes that structures, unions, arrays
+ passed by value (which never happens in C), and any other types this
+ predicate likes, might be returned in a struct-like fashion.  See the
+ function @code{using_struct_return} in @file{values.c} to see how this
+ gets used together with @code{USE_STRUCT_CONVENTION}.
+ 
  @item SOFTWARE_SINGLE_STEP_P
  Define this as 1 if the target does not have a hardware single-step
  mechanism. The macro @code{SOFTWARE_SINGLE_STEP} must also be defined.
From shebs@apple.com Tue Apr 18 13:22:00 2000
From: Stan Shebs <shebs@apple.com>
To: Jim Blandy <jimb@zwingli.cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: Document RETURN_VALUE_ON_STACK
Date: Tue, 18 Apr 2000 13:22:00 -0000
Message-id: <38FCC3DD.533C7037@apple.com>
References: <200004181954.OAA08866@zwingli.cygnus.com>
X-SW-Source: 2000-04/msg00349.html
Content-length: 1428

Jim Blandy wrote:
> 
> Is this okay?

Your wording could be taken to mean that structures can't be
passed by value in C - I would say "(note that arrays are
passed by value in some languages, but not in C)" or something
like that.  Other than that it looks fine to me.

Stan

> Index: gdbint.texinfo
> ===================================================================
> RCS file: /cvs/cvsfiles/devo/gdb/doc/gdbint.texinfo,v
> retrieving revision 1.151
> diff -c -c -r1.151 gdbint.texinfo
> *** gdbint.texinfo      2000/04/16 14:54:43     1.151
> --- gdbint.texinfo      2000/04/18 19:53:19
> ***************
> *** 1875,1880 ****
> --- 1875,1888 ----
>   form.
>   @xref{Target Architecture Definition, , Using Different Register and Memory Data Representations}.
> 
> + @item RETURN_VALUE_ON_STACK(@var{type})
> + Return non-zero if values of type TYPE are returned on the stack, using
> + the ``struct convention''.  GDB assumes that structures, unions, arrays
> + passed by value (which never happens in C), and any other types this
> + predicate likes, might be returned in a struct-like fashion.  See the
> + function @code{using_struct_return} in @file{values.c} to see how this
> + gets used together with @code{USE_STRUCT_CONVENTION}.
> +
>   @item SOFTWARE_SINGLE_STEP_P
>   Define this as 1 if the target does not have a hardware single-step
>   mechanism. The macro @code{SOFTWARE_SINGLE_STEP} must also be defined.
From davidw@gordian.com Tue Apr 18 14:50:00 2000
From: David Whedon <davidw@gordian.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFC] Change configure.in so -W arnings match reality
Date: Tue, 18 Apr 2000 14:50:00 -0000
Message-id: <Pine.LNX.4.04.10004181444000.19907-100000@pcx08>
X-SW-Source: 2000-04/msg00350.html
Content-length: 2255

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)

This error went away after I removed '-Wreturn-type' from the gdb/Makefile 
WARN_CFLAGS line.

Here is the error:

gmake[1]: Entering directory `/n/delphi2/irix_52/usr/local/src/gdb-build/68k/gdb'
gcc -c -O2    -I. -I/usr/local/src/rib/gdb-5.0/src//gdb -I/usr/local/src/rib/gdb-5.0/src//gdb/config -DHAVE_CONFIG_H -I/usr/local/src/rib/gdb-5.0/src//gdb/../include/opcode -I/usr/local/src/rib/gdb-5.0/src//gdb/../readline/.. -I../bfd -I/usr/local/src/rib/gdb-5.0/src//gdb/../bfd  -I/usr/local/src/rib/gdb-5.0/src//gdb/../include -I../intl -I/usr/local/src/rib/gdb-5.0/src//gdb/../intl -I/usr/local/src/rib/gdb-5.0/src//gdb/tui  -DUSE_INCLUDED_REGEX -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith  /usr/local/src/rib/gdb-5.0/src//gdb/main.c
cc1: Invalid option `-Wreturn-type'
gmake[1]: *** [main.o] Error 1
gmake[1]: Leaving directory `/n/delphi2/irix_52/usr/local/src/gdb-build/68k/gdb'
gmake: *** [all-gdb] Error 2

Other info:

# gcc -v
Reading specs from /usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.95.2/specs
gcc version 2.95.2 19991024 (release)

# /usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.95.2/cc1 --help | grep "\-W"
  -W                      Enable extra warnings
  -Winline                Warn when an inlined function cannot be inlined
  -Wuninitialized         Warn about unitialized automatic variables
  -Wcast-align            Warn about pointer casts which increase alignment
  -Waggregate-return      Warn about returning structures, unions or arrays
  -Wswitch                Warn about enumerated switches missing a specific ce
  -Wshadow                Warn when one local variable shadows another
snip . . . . snip

I'll spare you the whole list, but -Wreturn-type isn't in there.


I'm not sure what else it could be, and I figure others could be bitten by this too, unless my gcc install is somehow non-standard.

-David

Re: Include GDB/MI docs in GDB manual

[Dmitry Sivachenko]

   > I think it is bad idea to make a 'garbage heap' from the GDB manual,
   > mainly intended for regular GDB users, not 'GDB hackers'.

OK, I have nothing against including gdbmi.texi into GDB manual.

--dima


   I tend to the opposite ;-)

   I think that, ideally, the documentation should include everything in
   a single place.  If properly indexed, such a document, however large,
   is a handy tool for finding any issue your are after, in a fast and
   efficient way.

   In contrast, cross-references between different manuals are usually
   rare, and the facilities for searching multiple documents are abysmally
   more primitive (and mostly unknown and unused) than what you have for
   searching a single Info document.

   Here's a simple demonstration: the GDB manual does not have a single
   reference to the GDB Internals manual.  How do we expect a user who
   reads gdb.info to know that more docs about GDB is available
   elsewhere?

   Btw, the fact that "make install" in the GDB distro doesn't install
   the Info docs, unlike any other GNU project I've seen, actually makes
   it more probable that gdbint.info will not be installed anywhere along
   INFOPATH.  So even advanced features like "info --apropos" (how many
   people around here even know about the --apropos switch?) might not
   help.