Re: [PATCH]: add set/show debug, move gdb debugging flags into it

[Fernando Nasser <fnasser@redhat.com>]

Michael Snyder wrote:
> 
> Fernando Nasser wrote:
> 
> > The documentation problem may not be restricted to the debug command but
> > also to other maintenance class commands.  They have been considered to
> > be restricted to wizards that read source code instead of manuals and so
> > they have not been documented in the user's manual.
> 
> I always consider it questionable whether maintenance commands
> SHOULD be documented in the user's guide.  If they should,
> perhaps it should be in a separate section clearly identified
> as being for the maintenance and debugging of the debugger.
> 

I agree (I prefer the second option -- a separate section).  That is why
I said it was a policy issue.

I am not sure who is responsible for the content index (organization) of
the manual...

-- 
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 jimb@zwingli.cygnus.com Wed Mar 15 08:53: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_free
Date: Wed, 15 Mar 2000 08:53:00 -0000
Message-id: <npk8j49nv0.fsf@zwingli.cygnus.com>
References: <200002282302.SAA13215@zwingli.cygnus.com> <38BB1A9A.61A680AA@cygnus.com> <npg0ualjj3.fsf@zwingli.cygnus.com> <38C223E1.43260416@cygnus.com>
X-SW-Source: 2000-03/msg00276.html
Content-length: 524

> > > >From memory, I figured that if an _initialize* function failed to create
> > > a gdbarch the process was somewhat hosed and calling internal_error()
> > > was probably the best thing to do.
> 
> > This situation could arise if someone adds support for a new variant
> > of my architecture, but hasn't updated GDB yet.
> 
> So the real question is, is this an internal_error() and how should
> it be handled?  I can be convinced either way on this :-)

No, it's okay, I'll just drop the memory.  I withdraw the patch.
From dan@cgsoftware.com Wed Mar 15 09:33:00 2000
From: dan@cgsoftware.com (Daniel Berlin+mail.gdb)
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Daniel Berlin <dan@cgsoftware.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: add set/show debug, move gdb debugging flags into it
Date: Wed, 15 Mar 2000 09:33:00 -0000
Message-id: <d7ow9m0h.fsf@dan.resnet.rochester.edu>
References: <Pine.LNX.4.10.10003130852170.6968-200000@localhost.localdomain> <200003150919.EAA29966@indy.delorie.com> <r9dctixc.fsf@dan.resnet.rochester.edu> <200003151430.JAA01149@indy.delorie.com>
X-SW-Source: 2000-03/msg00277.html
Content-length: 1146

Eli Zaretskii <eliz@delorie.com> writes:


> > Are you saying i should write docs for the commands?
> 
> Yes.  Or at least Someone(tm) should.
Okey dokey.

I'm perfectly willing to document them, but personally, i don't think
they *should* be documented.
Or at least, the documentation shouldn't go with documentation for any
regular commands.
> 
> I consider the lack of any documentation for the commands you replaced
> to be part of the same bug that you were fixing.

In general, with those debug commands, if you can't figure out what
they do based on the one sentence docstring, you shouldn't be touching
them.
It's hard to say more about what "target debugging" is, except that it
enables printing of target debug info.

> 
> Even a simple one-liner that mentions the command's existence, with a
> @cindex entry to make it easy to find, is infinitely better than no
> documentation at all, because the latter doesn't leave the user any
> reasonable way of finding out that the commands exist.

They shouldn't find out they exist, unless specifically instructed by
someone.
IMHO.
They are for debugging GDB, not debugging *with* GDB.
--Dan
From dan@cgsoftware.com Wed Mar 15 09:42:00 2000
From: dan@cgsoftware.com (Daniel Berlin+mail.gdb)
To: Fernando Nasser <fnasser@redhat.com>
Cc: Eli Zaretskii <eliz@is.elta.co.il>, Daniel Berlin <dan@cgsoftware.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: add set/show debug, move gdb debugging flags into it
Date: Wed, 15 Mar 2000 09:42:00 -0000
Message-id: <8zzk9llj.fsf@dan.resnet.rochester.edu>
References: <Pine.LNX.4.10.10003130852170.6968-200000@localhost.localdomain> <200003150919.EAA29966@indy.delorie.com> <r9dctixc.fsf@dan.resnet.rochester.edu> <200003151430.JAA01149@indy.delorie.com> <38CFAE9E.39D1C081@redhat.com>
X-SW-Source: 2000-03/msg00278.html
Content-length: 1652

Fernando Nasser <fnasser@redhat.com> writes:

> First I agree with Eli that these commands must be documented.

I don't agree, but i'm perfectly willing to go with the consensus.

> 
> However, I don't think it is a must in Daniel's patch.  He is already
> fixing a big problem that is the horrible naming/organization of this
> commands.  As soon as I can get the deprecating patch in I am willing to
> check Daniel's patch so we get rid of those abnormalities. 


> 
> The documentation problem may not be restricted to the debug command but
> also to other maintenance class commands.  They have been considered to
> be restricted to wizards that read source code instead of manuals and so
> they have not been documented in the user's manual.
> 
This is why i don't think they should be documented.
Even if you knew what they did, the output wouldn't be useful unless
you went digging through the source code, or were familiar with the
source.

> It is a question of policy and, most importantly, willing of people to
> put some time into it (Someone(tm) will have to put some time to do
> it.)   

Hey, i'm Someone(tm).

> 
> Daniel could volunteer to write the debug ones, it would be nice, I just
> don't want to conditionalize his patch on that.  

I'll happily write the documentation for the debug ones, i just have
no idea what it should read like.
I mean, what do you want me to say about, fer instance, targetdebug?

All i can think of is "Controls printing of target_ops functions and
their arguments, as they get called".


> Eli could document some
> other ones.  I am not the maintainer of the manual but I guess it will
> be welcome.
From jimb@zwingli.cygnus.com Wed Mar 15 10:18:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: gdbarch_free
Date: Wed, 15 Mar 2000 10:18:00 -0000
Message-id: <nphfe89jwc.fsf@zwingli.cygnus.com>
References: <200002282302.SAA13215@zwingli.cygnus.com> <38BB1A9A.61A680AA@cygnus.com> <npg0ualjj3.fsf@zwingli.cygnus.com> <38C223E1.43260416@cygnus.com> <npk8j49nv0.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-03/msg00279.html
Content-length: 1703

> > > > >From memory, I figured that if an _initialize* function failed to create
> > > > a gdbarch the process was somewhat hosed and calling internal_error()
> > > > was probably the best thing to do.
> > 
> > > This situation could arise if someone adds support for a new variant
> > > of my architecture, but hasn't updated GDB yet.
> > 
> > So the real question is, is this an internal_error() and how should
> > it be handled?  I can be convinced either way on this :-)
> 
> No, it's okay, I'll just drop the memory.  I withdraw the patch.

Well, actually...

I don't think this is an internal error.  It's simply a case where GDB
has been given an executable that it doesn't recognize.  That
executable may have been produced by a completely different toolchain.

GDB gets the architecture and the machine (a variant within an
architecture, like 32-bit or 64-bit) from BFD.  BFD gets the
architecture from the ELF header's e_machine field (note the
unfortunate conflict in terminology), and gets the machine by masking
off some bits of the ELF header's e_flags field.

Suppose e_flags uses a three-bit field to identify the machine
variant, and uses 001 and 010 to identify two existing variants.  In
my foo_gdbarch_init function, I can recognize 001 and 010, but what
should I do with other values?

If I'm using a newer toolchain with an older GDB executable, this
situation could certainly arise, and GDB should report it nicely.

I guess I don't see the rationale for assuming that nobody will ever
put anything in an executable file that some GDB *_gdbarch_init
function won't recognize.  GDB should print an error message.

This isn't an internal error: the source of the data is external.
From jingham@cygnus.com Wed Mar 15 10:21:00 2000
From: James Ingham <jingham@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: "Insight (GDB GUI)" <insight@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFC: More fixes to insights ln -s
Date: Wed, 15 Mar 2000 10:21:00 -0000
Message-id: <14543.54628.527337.770021@leda.cygnus.com>
References: <38CF37E7.AADF52CF@cygnus.com>
X-SW-Source: 2000-03/msg00280.html
Content-length: 2803

Andrew,

I haven't really been paying that much attention to this configure
stuff of late, sorry...  But now that I think of it, I am pretty sure
all these link machinations are wholly unnecessary.  I munged the gdb
startup code around so that gdb will find its library files from the
build directory without using the link at all.  Moreover, when you
fail at making the link gdb will still work in GUI mode.  So maybe we
can just bag all this?  

However, it would be good to make sure that this is not some wierdness 
in my environment that makes it work.  What about others?  If you
delete the gdbtcl link in your build directory, can you still run gdb
in gui mode from the gdb build directory?  If this is true for others
as well, then we should just drop the extra complexity.

Jim
 > Hello,
 > 
 > The attatched patch makes the make target ``all-gdbtk'' which creates a
 > link more robust.  Fernando noted that it issued a warning when it
 > didn't need to.  It could also trip up if there was an invalid old link.
 > 
 > Ok?
 > 
 > 	AndrewWed Mar 15 17:32:48 2000  Andrew Cagney  <cagney@b1.cygnus.com>
 > 
 > 	* Makefile.in (all-gdbtk): Check for an existing link/directory.
 >   	Re-format warning message.
 > 
 > Index: Makefile.in
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/Makefile.in,v
 > retrieving revision 1.12
 > diff -p -r1.12 Makefile.in
 > *** Makefile.in	2000/03/04 07:11:38	1.12
 > --- Makefile.in	2000/03/15 07:09:53
 > *************** fork-child.o: fork-child.c gdb_wait.h $(
 > *** 1260,1273 ****
 >   	$(inferior_h) target.h terminal.h gdbthread.h gdb_string.h
 >   
 >   all-gdbtk:
 > ! 	if test "$(LN_S)" = "ln -s" -a ! -d gdbtcl/images ; then \
 > ! 	  echo linking ${srcdir}/gdbtk/library to gdbtcl ; \
 > ! 	  $(LN_S) ${srcdir}/gdbtk/library gdbtcl ; \
 > ! 	else \
 > ! 	  echo Warning: Unable to link ${srcdir}/gdbtk/library to gdbtcl. ; \
 > ! 	  echo "         " You will need to do a ; \
 > ! 	  echo "         " make install before you are able to run the GUI. ; \
 > ! 	fi
 >   
 >   clean-gdbtk:
 >   	rm -f gdbtcl
 > --- 1260,1278 ----
 >   	$(inferior_h) target.h terminal.h gdbthread.h gdb_string.h
 >   
 >   all-gdbtk:
 > ! 	@if test ! -d gdbtcl/images ; then \
 > ! 	  if test "$(LN_S)" = "ln -s" ; then \
 > ! 	    echo linking ${srcdir}/gdbtk/library to gdbtcl ; \
 > ! 	    rm -f gdbtcl ; \
 > ! 	    test ! -r gdbtcl || exit 1 ; \
 > ! 	    $(LN_S) ${srcdir}/gdbtk/library gdbtcl ; \
 > ! 	  else \
 > ! 	    echo "Warning:" ; \
 > ! 	    echo "Unable to link ${srcdir}/gdbtk/library to gdbtcl." ; \
 > ! 	    echo "You will need to do a \`make install' before you are" ; \
 > ! 	    echo "able to run the GUI." ; \
 > ! 	  fi ; \
 > ! 	else true ; fi
 >   
 >   clean-gdbtk:
 >   	rm -f gdbtcl
From msnyder@cygnus.com Wed Mar 15 11:15:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Linux/i386 testresults & gdb_proc_service.h patch
Date: Wed, 15 Mar 2000 11:15:00 -0000
Message-id: <38CFE0A4.12BB@cygnus.com>
References: <200002091522.e19FMU318441@delius.kettenis.local> <38AA3DF5.6BAAC6D4@cygnus.com>
X-SW-Source: 2000-03/msg00281.html
Content-length: 615

Andrew Cagney wrote:
> 
> This patch is ok with me. (Michael is on holidays)
> 
>         Andrew
> 
> Mark Kettenis wrote:
> 
> > 2000-02-09  Mark Kettenis  <kettenis@gnu.org>
> >
> >         * configure.in: Check for lwpid_t, psaddr_t, prgregset_t and
> >         fpgregset_t in <sys/procfs.h>.c
> >         * config.in: Add HAVE_LWPID_T, HAVE_PSADDR_T, HAVE_PRGREGSET_T,
> >         HAVE_PRFPREGSET_T.
> >         * gdb_proc_service.h: Only provide typedefs for lwpid_t, psaddr_t,
> >         prgregset_t and prfpregset_t if they are not already present.

I'm back.  This is good stuff.  Thanks!
From dima@Chg.RU Wed Mar 15 11:32:00 2000
From: Dmitry Sivachenko <dima@Chg.RU>
To: gdb-patches@sourceware.cygnus.com
Subject: typo in gdb.texinfo
Date: Wed, 15 Mar 2000 11:32:00 -0000
Message-id: <200003151932.WAA39200@netserv1.chg.ru>
X-SW-Source: 2000-03/msg00282.html
Content-length: 681

There is no value for GDBINIT!
Consider this fix:


--dima


--- gdb.texinfo.orig	Wed Mar 15 22:31:16 2000
+++ gdb.texinfo	Wed Mar 15 22:31:32 2000
@@ -10611,7 +10611,7 @@
 @cindex floating point, MIPS remote
 If your target board does not support the MIPS floating point
 coprocessor, you should use the command @samp{set mipsfpu none} (if you
-need this, you may wish to put the command in your @value{GDBINIT}
+need this, you may wish to put the command in your @file{.gdbinit}
 file).  This tells @value{GDBN} how to find the return value of
 functions which return floating point values.  It also allows
 @value{GDBN} to avoid saving the floating point registers when calling
From msnyder@cygnus.com Wed Mar 15 11:37:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Dmitry Sivachenko <dima@Chg.RU>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: typo in gdb.texinfo
Date: Wed, 15 Mar 2000 11:37:00 -0000
Message-id: <38CFE64A.2BBB@cygnus.com>
References: <200003151932.WAA39200@netserv1.chg.ru>
X-SW-Source: 2000-03/msg00283.html
Content-length: 954

Dmitry Sivachenko wrote:
> 
> There is no value for GDBINIT!
> Consider this fix:
> 
> --dima
> 
> --- gdb.texinfo.orig    Wed Mar 15 22:31:16 2000
> +++ gdb.texinfo Wed Mar 15 22:31:32 2000
> @@ -10611,7 +10611,7 @@
>  @cindex floating point, MIPS remote
>  If your target board does not support the MIPS floating point
>  coprocessor, you should use the command @samp{set mipsfpu none} (if you
> -need this, you may wish to put the command in your @value{GDBINIT}
> +need this, you may wish to put the command in your @file{.gdbinit}
>  file).  This tells @value{GDBN} how to find the return value of
>  functions which return floating point values.  It also allows
>  @value{GDBN} to avoid saving the floating point registers when calling

I think the purpose of having GDBINIT be a variable is
because it has a different filename on windows/CYGWIN.
Isn't it called "gdb.ini" or something?

If the variable truly isn't defined, it probably should be.
From ezannoni@cygnus.com Wed Mar 15 11:41:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: ezannoni@cygnus.com, ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: GDB-5 2000-03-03
Date: Wed, 15 Mar 2000 11:41:00 -0000
Message-id: <14543.59234.407028.669194@kwikemart.cygnus.com>
References: <38BFBD74.79263683@cygnus.com> <200003040702.CAA08162@indy.delorie.com> <38C0E240.FC02154E@cygnus.com> <14531.54961.880860.662139@kwikemart.cygnus.com> <200003151417.JAA01137@indy.delorie.com>
X-SW-Source: 2000-03/msg00284.html
Content-length: 19022

Eli Zaretskii writes:
 > 
 > > Andrew Cagney writes:
 > >  > Eli Zaretskii wrote:
 > >  > 
 > >  > > But there's a similar issue with Readline.  The current version in the
 > >  > > GDB CVS tree has bugs in the DJGPP-specific code, one of which simply
 > >  > > prevents GDB from linking.  I see that most of these problems are
 > >  > > solved in the current beta version of Readline, but will you be
 > >  > > synchronizing the GDB tree with that version before release?  If not,
 > >  > > I don't see any solution but a local patch.  Please advise.
 > >  > 
 > >  > Consider yourself the maintainer of the DJGPP specific readline stuff
 > >  > (like mmalloc).  (I'll add a note to MAINTAINERS.)
 > >  > 
 > >  > The main thing is to make certain that the true readline sources have
 > >  > the fix as well.  I wasn't planning on importing readline (I'll add a
 > >  > note stateing that this is something that won't make it).
 > >  > 
 > >  > 	Andrew
 > > 
 > > Eli, yes, please check in you fix to readline, I have no time this
 > > week to do another import.
 > 
 > I just committed the changes below.
 > 
 > (It seems the readline directory doesn't have a ChangeLog file, 'cause
 > CVS won't check it out for me.  Am I missing something?)
 > 

There is ChangeLog.Cygnus file. You can use that for the time
being. The readline package doesn't include a ChangeLog. I wonder
though if this makes any sense anymore, I mean, the name 'Cygnus'.

Elena

 > --- readline/support/shobj-conf.~	Tue Aug  3 02:08:42 1999
 > +++ readline/support/shobj-conf	Sat Feb 26 15:07:52 2000
 > @@ -305,6 +305,12 @@
 >  
 >  	SHLIB_LIBVERSION='$(SHLIB_LIBSUFF).$(SHLIB_MAJOR)'
 >  	;;
 > +
 > +msdosdjgpp*)
 > +	SHOBJ_STATUS=unsupported
 > +	SHLIB_STATUS=unsupported
 > +	;;
 > +
 >  #
 >  # Rely on correct gcc configuration for everything else
 >  #
 > --- readline/bind.c~	Tue Aug  3 02:08:36 1999
 > +++ readline/bind.c	Wed Feb 23 16:05:52 2000
 > @@ -62,6 +62,10 @@ extern int errno;
 >  extern char *strchr (), *strrchr ();
 >  #endif /* !strchr && !__STDC__ */
 >  
 > +#ifndef O_BINARY
 > +# define O_BINARY 0
 > +#endif
 > +
 >  extern int _rl_horizontal_scroll_mode;
 >  extern int _rl_mark_modified_lines;
 >  extern int _rl_bell_preference;
 > @@ -646,7 +650,7 @@ _rl_read_file (filename, sizep)
 >    char *buffer;
 >    int i, file;
 >  
 > -  if ((stat (filename, &finfo) < 0) || (file = open (filename, O_RDONLY, 0666)) < 0)
 > +  if ((stat (filename, &finfo) < 0) || (file = open (filename, O_RDONLY | O_BINARY, 0666)) < 0)
 >      return ((char *)NULL);
 >  
 >    file_size = (size_t)finfo.st_size;
 > @@ -667,7 +671,7 @@ _rl_read_file (filename, sizep)
 >    i = read (file, buffer, file_size);
 >    close (file);
 >  
 > -#if 0
 > +#if 1
 >    if (i < file_size)
 >  #else
 >    if (i < 0)
 > @@ -678,6 +682,30 @@ _rl_read_file (filename, sizep)
 >      }
 >  
 >    buffer[file_size] = '\0';
 > +
 > +#if O_BINARY
 > +  {
 > +    /* Systems which distinguish between text and binary files need
 > +       to strip the CR characters before each Newline, otherwise the
 > +       parsing functions won't work.  */
 > +    char *s, *d;
 > +    size_t removed = 0;
 > +
 > +    for (s = buffer, d = buffer; s < buffer + file_size; s++)
 > +      {
 > +	if (removed)
 > +	  *d = *s;
 > +	if (*s != '\r' || s[1] != '\n')
 > +	  d++;
 > +	else
 > +	  removed++;
 > +      }
 > +
 > +    file_size -= removed;
 > +    buffer[file_size] = '\0';
 > +  }
 > +#endif
 > +
 >    if (sizep)
 >      *sizep = file_size;
 >    return (buffer);
 > @@ -699,6 +728,7 @@ rl_re_read_init_file (count, ignore)
 >       1. the filename used for the previous call
 >       2. the value of the shell variable `INPUTRC'
 >       3. ~/.inputrc
 > +     4. (for __MSDOS__ only) ~/_inputrc
 >     If the file existed and could be opened and read, 0 is returned,
 >     otherwise errno is returned. */
 >  int
 > @@ -718,6 +748,20 @@ rl_read_init_file (filename)
 >    if (*filename == 0)
 >      filename = DEFAULT_INPUTRC;
 >  
 > +#ifdef __MSDOS__
 > +  {
 > +    /* DOS doesn't allow leading dots in file names.  If the original
 > +       name fails (it could work if we are on Windows), fall back to
 > +       ~/_inputrc.  */
 > +    int retval = _rl_read_init_file (filename, 0);
 > +
 > +    if (retval == 0)
 > +      return retval;
 > +    else if (strcmp (filename, "~/.inputrc") == 0)
 > +      filename = "~/_inputrc";
 > +  }
 > +#endif
 > +
 >    return (_rl_read_init_file (filename, 0));
 >  }
 >  
 > --- readline/complete.c~	Tue Aug  3 02:08:36 1999
 > +++ readline/complete.c	Wed Feb 23 18:02:32 2000
 > @@ -1407,9 +1410,9 @@ username_completion_function (text, stat
 >       char *text;
 >       int state;
 >  {
 > -#if defined (__GO32__) || defined (__WIN32__) || defined (__OPENNT)
 > +#if defined (__WIN32__) || defined (__OPENNT)
 >    return (char *)NULL;
 > -#else /* !__GO32__ */
 > +#else /* !__WIN32__ && !__OPENNT */
 >    static char *username = (char *)NULL;
 >    static struct passwd *entry;
 >    static int namelen, first_char, first_char_loc;
 > @@ -1499,6 +1502,14 @@ filename_completion_function (text, stat
 >  	  strcpy (filename, ++temp);
 >  	  *temp = '\0';
 >  	}
 > +#if defined (__WIN32__) || defined (__OPENNT) || defined (__MSDOS__)
 > +      /* Handle the drive-relative names "d:foo/bar".  */
 > +      else if (dirname[1] == ':')
 > +	{
 > +	  strcpy (filename, dirname + 2);
 > +	  dirname[2] = '\0';
 > +	}
 > +#endif
 >        else
 >  	{
 >  	  dirname[0] = '.';
 > --- readline/display.c~	Tue Aug  3 02:08:36 1999
 > +++ readline/display.c	Wed Feb 23 16:13:52 2000
 > @@ -1126,8 +1126,10 @@ _rl_move_vert (to)
 >    {
 >      int row, col;
 >  
 > +    i = fflush (rl_outstream);	/* make sure the cursor pos is current! */
 >      ScreenGetCursor (&row, &col);
 >      ScreenSetCursor ((row + to - _rl_last_v_pos), col);
 > +    delta = i;
 >    }
 >  #else /* !__GO32__ */
 >  
 > @@ -1377,7 +1379,10 @@ space_to_eol (count)
 >  void
 >  _rl_clear_screen ()
 >  {
 > -#if !defined (__GO32__)
 > +#if defined (__GO32__)
 > +  ScreenClear ();	/* FIXME: only works in text modes */
 > +  ScreenSetCursor (0, 0);  /* term_clrpag is "cl" which homes the cursor */
 > +#else
 >    if (term_clrpag)
 >      tputs (term_clrpag, 1, _rl_output_character_function);
 >    else
 > @@ -1392,6 +1397,7 @@ insert_some_chars (string, count)
 >       int count;
 >  {
 >  #if defined (__GO32__)
 > +#ifndef __DJGPP__
 >    int row, col, width;
 >    char *row_start;
 >  
 > @@ -1400,7 +1406,7 @@ insert_some_chars (string, count)
 >    row_start = ScreenPrimary + (row * width);
 >  
 >    memcpy (row_start + col + count, row_start + col, width - col - count);
 > -
 > +#endif /* !__DJGPP__ */
 >    /* Place the text on the screen. */
 >    _rl_output_some_chars (string, count);
 >  #else /* !_GO32 */
 > @@ -1445,6 +1451,7 @@ static void
 >  delete_chars (count)
 >       int count;
 >  {
 > +#if !defined (__DJGPP__)
 >  #if defined (__GO32__)
 >    int row, col, width;
 >    char *row_start;
 > @@ -1473,6 +1480,7 @@ delete_chars (count)
 >  	  tputs (term_dc, 1, _rl_output_character_function);
 >      }
 >  #endif /* !__GO32__ */
 > +#endif /* !__DJGPP__ */
 >  }
 >  
 >  void
 > --- readline/histfile.c~	Tue Aug  3 02:08:38 1999
 > +++ readline/histfile.c	Wed Feb 23 18:11:46 2000
 > @@ -140,6 +140,16 @@ read_history_range (filename, from, to)
 >    input = history_filename (filename);
 >    file = open (input, O_RDONLY|O_BINARY, 0666);
 >  
 > +
 > +#ifdef __MSDOS__
 > +  /* MSDOS doesn't allow leading dots in file names.  Try again
 > +     with the dot replaced by an underscore.  */
 > +  if (file < 0 && !filename)
 > +    {
 > +      input[strlen (input) - 8] = '_';
 > +      file = open (input, O_RDONLY|O_BINARY, 0666);
 > +    }
 > +#endif
 >    if ((file < 0) || (fstat (file, &finfo) == -1))
 >      goto error_and_exit;
 >  
 > @@ -233,6 +243,16 @@ history_truncate_file (fname, lines)
 >    filename = history_filename (fname);
 >    file = open (filename, O_RDONLY|O_BINARY, 0666);
 >  
 > +#ifdef __MSDOS__
 > +  /* MSDOS doesn't allow leading dots in file names.  Try again
 > +     with the dot replaced by an underscore.  */
 > +  if (file < 0 && !fname)
 > +    {
 > +      filename[strlen (filename) - 8] = '_';
 > +      file = open (filename, O_RDONLY|O_BINARY, 0666);
 > +    }
 > +#endif
 > +
 >    if (file == -1 || fstat (file, &finfo) == -1)
 >      goto truncate_exit;
 >  
 > @@ -314,8 +334,23 @@ history_do_write (filename, nelements, o
 >  
 >    if ((file = open (output, mode, 0600)) == -1)
 >      {
 > +#ifdef __MSDOS__
 > +      /* MSDOS doesn't allow leading dots in file names.  If this is
 > +	 the default file name, try again with the dot replaced by an
 > +	 underscore.  */
 > +      if (!filename)
 > +	{
 > +	  output[strlen (output) - 8] = '_';
 > +	  if ((file = open (output, mode, 0600)) == -1)
 > +	    {
 > +	      FREE (output);
 > +	      return (errno);
 > +	    }
 > +	}
 > +#else
 >        FREE (output);
 >        return (errno);
 > +#endif
 >      }
 >  
 >    if (nelements > history_length)
 > --- readline/input.c~	Tue Aug  3 02:08:38 1999
 > +++ readline/input.c	Wed Feb 23 16:25:20 2000
 > @@ -96,7 +96,7 @@ extern Keymap _rl_keymap;
 >  
 >  extern int _rl_convert_meta_chars_to_ascii;
 >  
 > -#if defined (__GO32__)
 > +#if defined (__GO32__) && !defined (HAVE_SELECT)
 >  #  include <pc.h>
 >  #endif /* __GO32__ */
 >  
 > @@ -176,7 +176,7 @@ rl_unget_char (key)
 >  static void
 >  rl_gather_tyi ()
 >  {
 > -#if defined (__GO32__)
 > +#if defined (__GO32__) && !defined (HAVE_SELECT)
 >    char input;
 >  
 >    if (isatty (0) && kbhit () && ibuffer_space ())
 > @@ -397,7 +397,7 @@ rl_getc (stream)
 >    int result, flags;
 >    unsigned char c;
 >  
 > -#if defined (__GO32__)
 > +#if defined (__GO32__) && !defined (HAVE_TERMIOS_H)
 >    if (isatty (0))
 >      return (getkey () & 0x7F);
 >  #endif /* __GO32__ */
 > @@ -448,7 +448,7 @@ rl_getc (stream)
 >  	}
 >  #endif /* _POSIX_VERSION && EAGAIN && O_NONBLOCK */
 >  
 > -#if !defined (__GO32__)
 > +#if !defined (__GO32__) || defined (HAVE_TERMIOS_H)
 >        /* If the error that we received was SIGINT, then try again,
 >  	 this is simply an interrupted system call to read ().
 >  	 Otherwise, some error ocurred, also signifying EOF. */
 > --- readline/readline.c~	Tue Aug  3 02:08:38 1999
 > +++ readline/readline.c	Wed Feb 23 17:58:46 2000
 > @@ -163,14 +163,16 @@ static void readline_initialize_everythi
 >  static void start_using_history ();
 >  static void bind_arrow_keys ();
 >  
 > -#if !defined (__GO32__)
 > +#if !defined (__GO32__) || defined (HAVE_TERMIOS_H)
 >  static void readline_default_bindings ();
 >  #endif /* !__GO32__ */
 >  
 >  #if defined (__GO32__)
 >  #  include <go32.h>
 >  #  include <pc.h>
 > -#  undef HANDLE_SIGNALS
 > +#  if !defined (__DJGPP__)
 > +#    undef HANDLE_SIGNALS
 > +#  endif /* !__DJGPP__ */
 >  #endif /* __GO32__ */
 >  
 >  extern char *xmalloc (), *xrealloc ();
 > @@ -745,10 +747,10 @@ readline_initialize_everything ()
 >    /* Initialize the terminal interface. */
 >    _rl_init_terminal_io ((char *)NULL);
 >  
 > -#if !defined (__GO32__)
 > +#if !defined (__GO32__) || defined (HAVE_TERMIOS_H)
 >    /* Bind tty characters to readline functions. */
 >    readline_default_bindings ();
 > -#endif /* !__GO32__ */
 > +#endif /* !__GO32__ || HAVE_TERMIOS_H */
 >  
 >    /* Initialize the function names. */
 >    rl_initialize_funmap ();
 > @@ -1272,7 +1279,7 @@ rl_refresh_line (ignore1, ignore2)
 >    _rl_move_vert (curr_line);
 >    _rl_move_cursor_relative (0, the_line);   /* XXX is this right */
 >  
 > -#if defined (__GO32__)
 > +#if defined (__GO32__) && !defined (__DJGPP__)
 >    {
 >      int row, col, width, row_start;
 >  
 > @@ -1281,9 +1288,9 @@ rl_refresh_line (ignore1, ignore2)
 >      row_start = ScreenPrimary + (row * width);
 >      memset (row_start + col, 0, (width - col) * 2);
 >    }
 > -#else /* !__GO32__ */
 > +#else /* !__GO32__ || __DJGPP__ */
 >    _rl_clear_to_eol (0);		/* arg of 0 means to not use spaces */
 > -#endif /* !__GO32__ */
 > +#endif /* !__GO32__ || __DJGPP__ */
 >  
 >    rl_forced_update_display ();
 >    rl_display_fixed = 1;
 > --- readline/rltty.c~	Mon Aug 16 22:17:56 1999
 > +++ readline/rltty.c	Wed Feb 23 15:56:42 2000
 > @@ -57,7 +57,9 @@ extern void _rl_control_keypad ();
 >  
 >  #if defined (__GO32__)
 >  #  include <pc.h>
 > -#  undef HANDLE_SIGNALS
 > +#  if !defined (__DJGPP__)
 > +#    undef HANDLE_SIGNALS
 > +#  endif /* !__DJGPP__ */
 >  #endif /* __GO32__ */
 >  
 >  /* Indirect functions to allow apps control over terminal management. */
 > @@ -260,7 +262,7 @@ prepare_terminal_settings (meta_flag, ot
 >       int meta_flag;
 >       TIOTYPE otio, *tiop;
 >  {
 > -#if !defined (__GO32__)
 > +#if !defined (__GO32__) || defined (HAVE_TERMIOS_H)
 >    readline_echoing_p = (otio.sgttyb.sg_flags & ECHO);
 >  
 >    /* Copy the original settings to the structure we're going to use for
 > @@ -326,7 +328,7 @@ prepare_terminal_settings (meta_flag, ot
 >    tiop->ltchars.t_dsuspc = -1;	/* C-y */
 >    tiop->ltchars.t_lnextc = -1;	/* C-v */
 >  #endif /* TIOCGLTC */
 > -#endif /* !__GO32__ */
 > +#endif /* !__GO32__ || HAVE_TERMIOS_H */
 >  }
 >  
 >  #else  /* !defined (NEW_TTY_DRIVER) */
 > @@ -524,7 +526,7 @@ void
 >  rl_prep_terminal (meta_flag)
 >       int meta_flag;
 >  {
 > -#if !defined (__GO32__)
 > +#if !defined (__GO32__) || defined (HAVE_TERMIOS_H)
 >    int tty;
 >    TIOTYPE tio;
 >  
 > @@ -559,14 +561,14 @@ rl_prep_terminal (meta_flag)
 >    terminal_prepped = 1;
 >  
 >    release_sigint ();
 > -#endif /* !__GO32__ */
 > +#endif /* !__GO32__ || HAVE_TERMIOS_H */
 >  }
 >  
 >  /* Restore the terminal's normal settings and modes. */
 >  void
 >  rl_deprep_terminal ()
 >  {
 > -#if !defined (__GO32__)
 > +#if !defined (__GO32__) || defined (HAVE_TERMIOS_H)
 >    int tty;
 >  
 >    if (!terminal_prepped)
 > @@ -591,7 +593,7 @@ rl_deprep_terminal ()
 >    terminal_prepped = 0;
 >  
 >    release_sigint ();
 > -#endif /* !__GO32__ */
 > +#endif /* !__GO32__ || HAVE_TERMIOS_H */
 >  }
 >  \f
 >  /* **************************************************************** */
 > --- readline/signals.c~	Tue Aug  3 02:08:38 1999
 > +++ readline/signals.c	Wed Feb 23 18:04:20 2000
 > @@ -40,9 +40,9 @@
 >  #  include <sys/ioctl.h>
 >  #endif /* GWINSZ_IN_SYS_IOCTL */
 >  
 > -#if defined (__GO32__)
 > +#if defined (__GO32__) && !defined(__DJGPP__)
 >  #  undef HANDLE_SIGNALS
 > -#endif /* __GO32__ */
 > +#endif /* __GO32__  && !__DJGPP__ */
 >  
 >  #if defined (HANDLE_SIGNALS)
 >  /* Some standard library routines. */
 > @@ -93,7 +93,9 @@ int rl_catch_sigwinch = 1;
 >  #endif
 >  
 >  static int signals_set_flag;
 > +#ifdef SIGWINCH
 >  static int sigwinch_set_flag;
 > +#endif
 >  
 >  /* **************************************************************** */
 >  /*					        		    */
 > --- readline/terminal.c~	Tue Aug  3 02:08:38 1999
 > +++ readline/terminal.c	Wed Feb 23 18:07:12 2000
 > @@ -57,6 +57,10 @@
 >  #  include <sys/ioctl.h>
 >  #endif /* GWINSZ_IN_SYS_IOCTL && !TIOCGWINSZ */
 >  
 > +#if defined (__GO32__)
 > +#  include <pc.h>
 > +#endif
 > +
 >  #include "rltty.h"
 >  #include "tcap.h"
 >  
 > @@ -77,19 +81,24 @@ extern void _rl_bind_if_unbound ();
 >  extern void set_lines_and_columns ();
 >  extern char *get_env_value ();
 >  
 > +/* Functions imported from display.c */
 > +extern void _rl_redisplay_after_sigwinch ();
 > +
 >  /* **************************************************************** */
 >  /*								    */
 >  /*			Terminal and Termcap			    */
 >  /*								    */
 >  /* **************************************************************** */
 >  
 > +#ifndef __DJGPP__
 >  static char *term_buffer = (char *)NULL;
 >  static char *term_string_buffer = (char *)NULL;
 >  
 > -static int tcap_initialized;
 > -
 >  /* Non-zero means this terminal can't really do anything. */
 >  static int dumb_term;
 > +#endif
 > +
 > +static int tcap_initialized;
 >  
 >  #if !defined (__linux__)
 >  #  if defined (__EMX__) || defined (NEED_EXTERN_PC)
 > @@ -186,7 +195,11 @@ _rl_get_screen_size (tty, ignore_env)
 >        if (ignore_env == 0 && (ss = get_env_value ("COLUMNS")))
 >  	screenwidth = atoi (ss);
 >  
 > -#if !defined(__DJGPP__)
 > +#if defined(__DJGPP__)
 > +      tty = tty;
 > +      if (screenwidth <= 0)
 > +	screenwidth = ScreenCols ();
 > +#else
 >        if (screenwidth <= 0 && term_string_buffer)
 >  	screenwidth = tgetnum ("co");
 >  #endif
 > @@ -199,7 +212,10 @@ _rl_get_screen_size (tty, ignore_env)
 >        if (ignore_env == 0 && (ss = get_env_value ("LINES")))
 >  	screenheight = atoi (ss);
 >  
 > -#if !defined(__DJGPP__)
 > +#if defined(__DJGPP__)
 > +      if (screenheight <= 0)
 > +	screenheight = ScreenRows ();
 > +#else
 >        if (screenheight <= 0 && term_string_buffer)
 >  	screenheight = tgetnum ("li");
 >  #endif
 > @@ -291,7 +307,9 @@ static void
 >  get_term_capabilities (bp)
 >       char **bp;
 >  {
 > -#if !defined(__DJGPP__)
 > +#if defined(__DJGPP__)
 > +  bp = bp;
 > +#else
 >    register int i;
 >  
 >    for (i = 0; i < NUM_TC_STRINGS; i++)
 > @@ -305,9 +323,10 @@ _rl_init_terminal_io (terminal_name)
 >       char *terminal_name;
 >  {
 >  #if defined (__GO32__)
 > -  screenwidth = ScreenCols ();
 > -  screenheight = ScreenRows ();
 > -  screenchars = screenwidth * screenheight;
 > +  terminal_name = terminal_name;
 > +  screenwidth = screenheight = 0;
 > +  _rl_get_screen_size (rl_instream ? fileno (rl_instream) : 0, 0);
 > +
 >    term_cr = "\r";
 >    term_im = term_ei = term_ic = term_IC = (char *)NULL;
 >    term_up = term_dc = term_DC = visible_bell = (char *)NULL;
 > @@ -323,7 +342,7 @@ _rl_init_terminal_io (terminal_name)
 >    term_forward_char = (char *)NULL;
 >  #endif /* HACK_TERMCAP_MOTION */
 >    terminal_can_insert = _rl_term_autowrap = 0;
 > -  return;
 > +  return 0;
 >  #else /* !__GO32__ */
 >  
 >    char *term, *buffer;
 > @@ -510,28 +529,28 @@ ding ()
 >  {
 >    if (readline_echoing_p)
 >      {
 > -#if !defined (__GO32__)
 >        switch (_rl_bell_preference)
 >          {
 >  	case NO_BELL:
 >  	default:
 >  	  break;
 >  	case VISIBLE_BELL:
 > +#if defined (__GO32__)
 > +	  ScreenVisualBell ();
 > +	  break;
 > +#else
 >  	  if (visible_bell)
 >  	    {
 >  	      tputs (visible_bell, 1, _rl_output_character_function);
 >  	      break;
 >  	    }
 > +#endif
 >  	  /* FALLTHROUGH */
 >  	case AUDIBLE_BELL:
 >  	  fprintf (stderr, "\007");
 >  	  fflush (stderr);
 >  	  break;
 >          }
 > -#else /* __GO32__ */
 > -      fprintf (stderr, "\007");
 > -      fflush (stderr);
 > -#endif /* __GO32__ */
 >        return (0);
 >      }
 >    return (-1);
 > @@ -556,7 +575,9 @@ void
 >  _rl_control_keypad (on)
 >       int on;
 >  {
 > -#if !defined(__DJGPP__)
 > +#if defined(__DJGPP__)
 > +  on = on;
 > +#else
 >    if (on && term_ks)
 >      tputs (term_ks, 1, _rl_output_character_function);
 >    else if (!on && term_ke)
From ezannoni@cygnus.com Wed Mar 15 11:43:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: ezannoni@cygnus.com, shebs@apple.com, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] GDB command-line switches and annotations docs
Date: Wed, 15 Mar 2000 11:43:00 -0000
Message-id: <14543.59354.570747.545184@kwikemart.cygnus.com>
References: <14537.5048.99180.910863@kwikemart.cygnus.com> <200003101809.NAA22092@indy.delorie.com> <14537.18119.116000.442262@kwikemart.cygnus.com> <200003120754.CAA24393@indy.delorie.com> <14539.49127.700844.807495@kwikemart.cygnus.com> <200003151414.JAA01131@indy.delorie.com>
X-SW-Source: 2000-03/msg00285.html
Content-length: 2610

Eli Zaretskii writes:
 > 
 > >  > If it would help, I could add a note telling that the event loop is
 > >  > still not fully asynchronous, with a FIXME comment that the note
 > >  > should be removed when the target side is done.  Okay?
 > > 
 > > Perfect, thanks!
 > 
 > I attach below the changes which address the above, and also what Stan
 > said about moving the Annotations chapter before the appendices.
 > These changes are to be applied _on top_ of those I sent in the
 > previous message.
 > 
 > Is it okay to commit this and the previous patch?
 > 

Ok with me for contents, but I am not the docs maintainer.

Elena

 > --- gdb/doc/gdb.t~1	Fri Mar 10 16:39:30 2000
 > +++ gdb/doc/gdb.texi	Tue Mar 14 22:34:26 2000
 > @@ -146,6 +146,7 @@
 >  * Controlling GDB::             Controlling @value{GDBN}
 >  * Sequences::                   Canned sequences of commands
 >  * Emacs::                       Using @value{GDBN} under @sc{gnu} Emacs
 > +* Annotations::                 @value{GDBN}'s annotations interface.
 >  
 >  * GDB Bugs::                    Reporting bugs in @value{GDBN}
 >  * Formatting Documentation::    How to format and print @value{GDBN} documentation
 > @@ -153,7 +154,6 @@
 >  * Command Line Editing::        Command Line Editing
 >  * Using History Interactively:: Using History Interactively
 >  * Installing GDB::              Installing GDB
 > -* Annotations::                 @value{GDBN}'s annotations interface.
 >  * Index::                       Index
 >  @end menu
 >  
 > @@ -945,6 +945,11 @@
 >  MS-DOS/MS-Windows supports this mode of operation, but the event loop is
 >  suspended when the debuggee runs.}, so you don't need to wait for
 >  control to return to @value{GDBN} before you type the next command.
 > +(@emph{Note:} as of version 5.0, the target side of the asynchronous
 > +operation is not yet in place, so @samp{-async} does not work fully
 > +yet.)
 > +@c FIXME: when the target side of the event loop is done, the above NOTE
 > +@c should be removed.
 >  
 >  When the standard input is connected to a terminal device, @value{GDBN}
 >  uses the asynchronous event loop by default, unless disabled by the
 > @@ -11970,6 +11975,8 @@
 >  each value is printed in its own window.
 >  @end ignore
 >  
 > +@include annotate.texi
 > +
 >  @node GDB Bugs
 >  @chapter Reporting Bugs in @value{GDBN}
 >  @cindex bugs in @value{GDBN}
 > @@ -12592,8 +12599,6 @@
 >  
 >  There are many other options available as well, but they are generally
 >  needed for special purposes only.
 > -
 > -@include annotate.texi
 >   
 >  @node Index
 >  @unnumbered Index
From msnyder@cygnus.com Wed Mar 15 11:45:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: symfile.c: Fix for GDB crash when rereading symbols
Date: Wed, 15 Mar 2000 11:45:00 -0000
Message-id: <38CFE802.E14@cygnus.com>
References: <200003141046.LAA08835@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-03/msg00286.html
Content-length: 342

Peter.Schauer wrote:
> 
> symfile.c:reread_symbols does not clear the new msymbol hash tables in the
> objfile, causing stale pointers and a GDB crash during the reread.exp
> test on Solaris.
> 
> Here is a fix:
> 
>         * symfile.c (reread_symbols):  Clear msymbol hash table.

I've checked it in.  Thanks again.

			Michael
From shebs@apple.com Wed Mar 15 11:55:00 2000
From: Stan Shebs <shebs@apple.com>
To: Dmitry Sivachenko <dima@Chg.RU>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: typo in gdb.texinfo
Date: Wed, 15 Mar 2000 11:55:00 -0000
Message-id: <38CFEAA9.E74A4A9F@apple.com>
References: <200003151932.WAA39200@netserv1.chg.ru>
X-SW-Source: 2000-03/msg00287.html
Content-length: 447

Dmitry Sivachenko wrote:
> 
> There is no value for GDBINIT!
> Consider this fix:

Good catch!  This was supposed to come from the configuration file, but that's
being phased out, I must have missed the GDBINIT ref.  I'll figure out
what to
say here and check something in; it shouldn't be @code{.gdbinit} literally,
because a) it's not correct for Unix, and b) it's possible to have a config-
specific name, such as .vxgdbinit for VxWorks.

Stan
From shebs@apple.com Wed Mar 15 12:13:00 2000
From: Stan Shebs <shebs@apple.com>
To: msnyder@cygnus.com
Cc: Fernando Nasser <fnasser@redhat.com>, Eli Zaretskii <eliz@is.elta.co.il>, Daniel Berlin <dan@cgsoftware.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: add set/show debug, move gdb debugging flags into it
Date: Wed, 15 Mar 2000 12:13:00 -0000
Message-id: <38CFEEE2.3AD118BD@apple.com>
References: <Pine.LNX.4.10.10003130852170.6968-200000@localhost.localdomain> <200003150919.EAA29966@indy.delorie.com> <r9dctixc.fsf@dan.resnet.rochester.edu> <200003151430.JAA01149@indy.delorie.com> <38CFAE9E.39D1C081@redhat.com> <38CFB57A.1900@cygnus.com>
X-SW-Source: 2000-03/msg00288.html
Content-length: 1138

Michael Snyder wrote:
> 
> Fernando Nasser wrote:
> 
> > The documentation problem may not be restricted to the debug command but
> > also to other maintenance class commands.  They have been considered to
> > be restricted to wizards that read source code instead of manuals and so
> > they have not been documented in the user's manual.
> 
> I always consider it questionable whether maintenance commands
> SHOULD be documented in the user's guide.  If they should,
> perhaps it should be in a separate section clearly identified
> as being for the maintenance and debugging of the debugger.

I've been in favor of including them, just because users sometimes have need
of those commands.  remotedebug is perhaps the best-known example; while
nominally for maintenance on the standard protocol, it's become a staple
for embedded developers, since bugs in the application can trash the stub,
and remotedebug will help you see what is happening.

You're right that maint commands should generally be documented in their
own section, so they're only found by the truly desperate users... :-)

It's on my list, but at a low priority.

Stan
From shebs@apple.com Wed Mar 15 12:18:00 2000
From: Stan Shebs <shebs@apple.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Daniel Berlin <dan@cgsoftware.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: add set/show debug, move gdb debugging flags into it
Date: Wed, 15 Mar 2000 12:18:00 -0000
Message-id: <38CFF02C.B39564B7@apple.com>
References: <Pine.LNX.4.10.10003130852170.6968-200000@localhost.localdomain> <200003150919.EAA29966@indy.delorie.com> <r9dctixc.fsf@dan.resnet.rochester.edu> <200003151430.JAA01149@indy.delorie.com>
X-SW-Source: 2000-03/msg00289.html
Content-length: 1054

Eli Zaretskii wrote:
> 
> > Are you saying i should write docs for the commands?
> 
> Yes.  Or at least Someone(tm) should.
> 
> I consider the lack of any documentation for the commands you replaced
> to be part of the same bug that you were fixing.

Agree completely.

> Even a simple one-liner that mentions the command's existence, with a
> @cindex entry to make it easy to find, is infinitely better than no
> documentation at all, because the latter doesn't leave the user any
> reasonable way of finding out that the commands exist.

Yes.  While in theory GDB's online help will eventually find you the
documentation for a command, its organization means that you have to
do a bunch of thumbing around to find something (and it was a *real*
pain before things got alphabetized!).

Online also doesn't work if the command is configuration-specific
and not in your configuration - you would be led to the conclusion
that the command didn't exist, and could only find out otherwise
by doing a mass search through the sources.  Sad, very sad...

Stan
From shebs@apple.com Wed Mar 15 12:20:00 2000
From: Stan Shebs <shebs@apple.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: ezannoni@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] GDB command-line switches and annotations docs
Date: Wed, 15 Mar 2000 12:20:00 -0000
Message-id: <38CFF074.B275A986@apple.com>
References: <14537.5048.99180.910863@kwikemart.cygnus.com> <200003101809.NAA22092@indy.delorie.com> <14537.18119.116000.442262@kwikemart.cygnus.com> <200003120754.CAA24393@indy.delorie.com> <14539.49127.700844.807495@kwikemart.cygnus.com> <200003151414.JAA01131@indy.delorie.com>
X-SW-Source: 2000-03/msg00290.html
Content-length: 560

Eli Zaretskii wrote:
> 
> >  > If it would help, I could add a note telling that the event loop is
> >  > still not fully asynchronous, with a FIXME comment that the note
> >  > should be removed when the target side is done.  Okay?
> >
> > Perfect, thanks!
> 
> I attach below the changes which address the above, and also what Stan
> said about moving the Annotations chapter before the appendices.
> These changes are to be applied _on top_ of those I sent in the
> previous message.
> 
> Is it okay to commit this and the previous patch?

Go for it!

Stan
From kingdon@redhat.com Wed Mar 15 13:15:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: RFD: infrun.c:  No bpstat_stop_status call after proceed over break ?
Date: Wed, 15 Mar 2000 13:15:00 -0000
Message-id: <bem9cx7kb.fsf@rtl.cygnus.com>
References: <200003130948.KAA07547@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-03/msg00291.html
Content-length: 1740

> I am currently trying to fix a GDB bug with missing watchpoint triggers
> after proceeding over a breakpoint on x86 targets.
> 
> Here is an example, using gdb.c++/annota2:

Yeah, I ran into the same bug (the testsuite hits it on x86 Linux).

My fix was similar to what you suggest (identical, unless I'm missing
something).  I don't remember it as creating testsuite regressions but
I'm not sure I checked - it was a while ago that I looked into this.

Index: infrun.c
===================================================================
RCS file: /cvs/gdb/gdb/gdb/infrun.c,v
retrieving revision 1.1.1.27
diff -u -r1.1.1.27 infrun.c
--- infrun.c	2000/02/05 07:29:43	1.1.1.27
+++ infrun.c	2000/02/07 13:22:02
@@ -2076,6 +2076,18 @@
 	    return;
 	  }
 
+#if 0
+	/* We might not want to think about breakpoints, but what
+	   about hardware watchpoints?  We yanked out the hardware
+	   (debug register or whatever) when we stepped over the breakpoint,
+	   so we need to check manually the watchpoint condition (mildly
+	   painful because it could get expensive, but I don't see how
+	   using the hardware could work without lots of spaghetti trying
+	   to keep track of what is inserted and what isn't (and how they
+	   interact)).
+
+	   TODO: Need to think more about this, test it, &c.  Right now it
+	   is kind of an idea more so than a well-thought-out solution.  */
 	/* Don't even think about breakpoints
 	   if just proceeded over a breakpoint.
 
@@ -2087,6 +2099,7 @@
 	    && through_sigtramp_breakpoint == NULL)
 	  bpstat_clear (&stop_bpstat);
 	else
+#endif /* 0 */
 	  {
 	    /* See if there is a breakpoint at the current PC.  */
 	    stop_bpstat = bpstat_stop_status