Re: patch for gdb.texinfo

Re: patch for gdb.texinfo

[Stan Shebs]

(Hi everybody!)

Dmitry Sivachenko wrote:
> 
> >
> > > -intent is to aid the debugging of @dfn{dynamic arrays}, which cannot be
> > > +intent is to aid the debugging of dynamic arrays, which cannot be
> >
> > Why is it a good idea to remove the @dfn here?
> 
> Because there is no definition of 'dynamic arrays' here in the text.

Which makes sense, although perhaps it would be better to include
a quick definition of dynamic arrays.  The reader may or may not
know what is being referred to here - indeed I'm not entirely sure
myself, although the term seems to be used in a generic sense,
rather than as a reference to a specific language construct.

> > As for the replacements of @code and @samp with @env and @option:
> > please note that this makes the GDB manual incompatible with all
> > versions of Texinfo except the latest v4.0.
> 
> That is true.
> 
> > Are you sure it's a good
> > idea to break back-compatibility for no good reason (since they
> > typeset in the same way)?
> 
> Do you use any new features of whatever OS you use?  This is also
> incompatible with older versions...
> 
> I think we should use new features of texinfo.  May be in future versions
> typeseting @env and @command  will differ from the current behaviour.
> By the way, FreeBSD team already updated texinfo to 4.0 in base distribution.

I disagree here.  We do have to worry about backward compatibility,
just as we had to support K&R compilers for a long time, and just
as we support many old OS versions.  Certainly many GDB users would
be disappointed if we trashed Linux support for any kernel older
than, say, 2.2.5!

In the case at hand, older versions of texinfo will just choke and
stop processing the file, right?  So to forestall many bug reports,
we should stick with an older version.  I would say 3.0, but if
somebody knows of a need for compat with 2.x, speak up now...

                                                Stan
                                                shebs@shebs.cnchost.com
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ezannoni@cygnus.com
Cc: shebs@apple.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Handle_inferior_event() problem
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003091332.IAA19945@indy.delorie.com>
References: <14533.28395.325377.920332@kwikemart.cygnus.com>
X-SW-Source: 2000-q1/msg00616.html
Content-length: 511

> Say you have stepped your way to the first instruction of the prologue
> of a function (using stepi, for instance) and now you do a 'nexti'.
> The programs runs away to the end of the function or somewhere else and
> gdb gets really confused.

Confirmed in the DJGPP version: the problem exists just like you
described.

> Anyway, long story short...  How about this patch? It doesn't take
> care of everything, but it solves that immediate problem.

Confirmed again: problem solved with this patch.  Thanks!
From Julian.Bock@t-online.de Sat Apr 01 00:00:00 2000
From: Julian.Bock@t-online.de (Julian v. Bock)
To: gdb-patches@sourceware.cygnus.com
Subject: gdb 4.18 / libiberty bugfix
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <00011802175801.00321@KernelPanic>
X-SW-Source: 2000-q1/msg00024.html
Content-length: 690

Hi!

problem:
gdb segfaulted when demangling a (rather complex) c++ name while reading a
symbol table.

bug:
In the remember_type function (gdb-4.18/libiberty/cplus-dem.c) the typevec
array of the work structure was zero, but work -> typevec_size was 3, so the
function didn't allocate memory for typevec. When typevec was accessed gdb
went down.
The reason for this seems to be that when work -> typevec is freed in the mop_up
function (same file; line 882) work -> typevec_size is not set zero.

solution:
setting work -> typevec_size to zero after freeing work -> typevec should do
the trick. After I have done this everything worked fine.

I hope this bug wasn't already known.

Julian
From cgf@cygnus.com Sat Apr 01 00:00:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [PATCH} maint.c remove quoted trailing space
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000325193022.H802@cygnus.com>
References: <38DC70E4.C2ECB4E9@cygnus.com>
X-SW-Source: 2000-q1/msg01031.html
Content-length: 279

On Sat, Mar 25, 2000 at 06:55:16PM +1100, Andrew Cagney wrote:
>I've applied the following.  As an aside, we can start using:
>
>	"a string that"
>	"extends over several lines"

But this only works in ISO C!

Oh.  Wait.  Never mind.

I always forget that you can do this...

cgf
From scottb@netwinder.org Sat Apr 01 00:00:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Patches and the patch database...
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BEC141.9D299C3B@netwinder.org>
X-SW-Source: 2000-q1/msg00460.html
Content-length: 427

Hi guys,

I decided to exercise the patch database.  I sent a whole whack of patches to
get rid of the deprecated macros TARGET_BYTE_ORDER and
TARGET_BYTE_ORDER_SELECTABLE.  It might be useful to have an architecture field
on the web form.  That would make it easier to search for ARM patches for
instance.

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From jimb@zwingli.cygnus.com Sat Apr 01 00:00: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: Sat, 01 Apr 2000 00:00: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-q1/msg00718.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 taylor@cygnus.com Sat Apr 01 00:00:00 2000
From: David Taylor <taylor@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] Another utils.c patch
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003202011.PAA22504@texas.cygnus.com>
X-SW-Source: 2000-q1/msg00822.html
Content-length: 1799

    Date: Mon, 20 Mar 2000 12:35:19 -0700
    From: Kevin Buettner <kevinb@cygnus.com>

    On Mar 20, 12:45pm, David Taylor wrote:

    >        memcpy (&dfrom, from, sizeof (dfrom));
    >     -  memset (uto, 0, fmt->totalsize / FLOATFORMAT_CHAR_BIT);
    >     +  memset (uto, 0, fmt->totalsize / FLOATFORMAT_CHAR_BIT
    >     +                  + ((fmt->totalsize % FLOATFORMAT_CHAR_BIT) == 0 ? 0 : 1));
    > 
    > Approved.

    Thanks for approving this so quickly.  However, I had withdrawn the
    above patch in favor of the one below.  I would prefer to get approval
    for the one below.  They are, however, functionally equivalent.  If
    you prefer the one above for some reason, I can check that one in
    instead.

Either version is okay; I prefer the newer one, but either is acceptable.

	    * utils.c (floatformat_from_doublest): Make sure space that we're
	    writing the float to is completely initialized to zeroes, even
	    when the number of bits in the float is not evenly divisible
	    by FLOATFORMAT_CHAR_BIT.

    Index: utils.c
    ===================================================================
    RCS file: /cvs/src/src/gdb/utils.c,v
    retrieving revision 1.4
    diff -u -p -r1.4 utils.c
    --- utils.c     2000/03/04 02:23:06     1.4
    +++ utils.c     2000/03/19 17:36:49
    @@ -2722,7 +2722,8 @@ floatformat_from_doublest (fmt, from, to
       unsigned char *uto = (unsigned char *) to;

       memcpy (&dfrom, from, sizeof (dfrom));
    -  memset (uto, 0, fmt->totalsize / FLOATFORMAT_CHAR_BIT);
    +  memset (uto, 0, (fmt->totalsize + FLOATFORMAT_CHAR_BIT - 1) 
    +                    / FLOATFORMAT_CHAR_BIT);
       if (dfrom == 0)
	 return;                    /* Result is zero */
       if (dfrom != dfrom)          /* Result is NaN */

Re: patch for gdb.texinfo

[Dmitry Sivachenko]

> (Hi everybody!)
>
> Dmitry Sivachenko wrote:
> > 
> > >
> > > > -intent is to aid the debugging of @dfn{dynamic arrays}, which cannot be
> > > > +intent is to aid the debugging of dynamic arrays, which cannot be
> > >
> > > Why is it a good idea to remove the @dfn here?
> > 
> > Because there is no definition of 'dynamic arrays' here in the text.
>
> Which makes sense, although perhaps it would be better to include
> a quick definition of dynamic arrays.  The reader may or may not
> know what is being referred to here - indeed I'm not entirely sure
> myself, although the term seems to be used in a generic sense,
> rather than as a reference to a specific language construct.

Yes, I agree, but don't feel myself in English so well to do it without
grammar mistakes, sorry...   :)

>
> > > As for the replacements of @code and @samp with @env and @option:
> > > please note that this makes the GDB manual incompatible with all
> > > versions of Texinfo except the latest v4.0.
> > 
> > That is true.
> > 
> > > Are you sure it's a good
> > > idea to break back-compatibility for no good reason (since they
> > > typeset in the same way)?
> > 
> > Do you use any new features of whatever OS you use?  This is also
> > incompatible with older versions...
> > 
> > I think we should use new features of texinfo.  May be in future versions
> > typeseting @env and @command  will differ from the current behaviour.
> > By the way, FreeBSD team already updated texinfo to 4.0 in base distribution.
>
> I disagree here.  We do have to worry about backward compatibility,
> just as we had to support K&R compilers for a long time, and just
> as we support many old OS versions.  Certainly many GDB users would
> be disappointed if we trashed Linux support for any kernel older
> than, say, 2.2.5!

Well, sounds reasonable.

>
> In the case at hand, older versions of texinfo will just choke and
> stop processing the file, right?  So to forestall many bug reports,
> we should stick with an older version.  I would say 3.0, but if
> somebody knows of a need for compat with 2.x, speak up now...
>

--dima
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Daniel Berlin <dan@cgsoftware.com>
Cc: Kevin Buettner <kevinb@cygnus.com>, Andrew Cagney <ac131313@cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [RFC] Notes on QUIT and STREQ et.al.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5mwvn6ljbd.fsf@jtc.redbacknetworks.com>
References: <Pine.LNX.4.10.10003130829420.6968-100000@localhost.localdomain>
X-SW-Source: 2000-q1/msg00677.html
Content-length: 640

>>>>> "Daniel" == Daniel Berlin <dan@cgsoftware.com> writes:

>> 
>> I haven't looked to see how often (or where) STREQ and STRCMP are
>> used, but these macros compare the first characters inline in an
>> attempt to improve performance.  Have you assessed the benefits of
>> doing this?  (If these optimizations significantly improve
>> performance, I think they should stay.)

Daniel> I'll check out the performance.  I know GCC has a strlen
Daniel> expander, but no strcmp expander, so it might be a benefit.

I thought that GCC can expand strcmp() if the target has a cmpstrsi
pattern.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From Peter.Schauer@regent.e-technik.tu-muenchen.de Sat Apr 01 00:00:00 2000
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: eliz@delorie.com (Eli Zaretskii)
Cc: jimb@zwingli.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: minor watchpoint code cleanup
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003192107.WAA12743@reisser.regent.e-technik.tu-muenchen.de>
References: <200003190944.EAA07454@indy.delorie.com>
X-SW-Source: 2000-q1/msg00788.html
Content-length: 1635

> While we are talking: someone (H.J. Lu?) suggested to make the
> watchpoint insertion code common to all x86 targets.  What's the
> current say-so on this?

With Solaris x86 2.6 and beyond we can get an unlimited amount of watchpoints
with only a few restrictions via page fault handling, procfs and appropriate
Solaris kernel support.

I don't object to common watchpoint insertion code (using x86 debug registers)
for other x86 targets, but we should be able to override it via the tm/nm
config files.


My (currently experimental) version of config/nm-i386sol2.h has this:


#if defined (NEW_PROC_API)

/* Solaris supports procfs watchpoints starting with 2.6. */
#define TARGET_HAS_HARDWARE_WATCHPOINTS

#define TARGET_CAN_USE_HARDWARE_WATCHPOINT(type, cnt, ot) 1

/* When a hardware watchpoint fires off the PC will be left after the
   instruction which caused the watchpoint.  */

#define STOPPED_BY_WATCHPOINT(W) \
     procfs_stopped_by_watchpoint(inferior_pid)
extern int procfs_stopped_by_watchpoint PARAMS ((int));

#define HAVE_CONTINUABLE_WATCHPOINT

#define CANNOT_STEP_HW_WATCHPOINTS

/* Use these macros for watchpoint insertion/deletion.  */
/* TYPE is target_hw_bp_type. */
#define target_insert_watchpoint(ADDR, LEN, TYPE) \
     procfs_set_watchpoint (inferior_pid, ADDR, LEN, TYPE, 1)
#define target_remove_watchpoint(ADDR, LEN, TYPE) \
     procfs_set_watchpoint (inferior_pid, ADDR, 0, 0, 1)
extern int procfs_set_watchpoint PARAMS ((int, CORE_ADDR, int, int, int));

#define TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(SIZE) 1

#endif /* NEW_PROC_API */


-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jonathan Larmour <jlarmour@redhat.co.uk>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: copyright banner and reporting bugs
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E012B1.D959B46C@cygnus.com>
References: <38CFF922.6BA6928E@redhat.co.uk> <38DF418A.42355DAD@cygnus.com>
X-SW-Source: 2000-q1/msg01074.html
Content-length: 1461

Andrew Cagney wrote:
> 
> Jonathan Larmour wrote:
> >
> > I just noticed two minor things: surely the copyright banner when GDB starts
> > should be something more recent than 1998 even now - i.e. it shouldn't need
> > to wait for the release.
> 
> Good point.  It should pick up Makefile.in:VERSION.

I've applied the attatched.  VERSION, unfortunatly can't be trusted to
contain the information we need. (I actually wonder if it shouldn't read
``Copyright 1985-2000'').

	Andrew
Tue Mar 28 11:52:45 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* top.c (print_gdb_version): Bump copyright year to 2000.

Index: top.c
===================================================================
RCS file: /cvs/src/src/gdb/top.c,v
retrieving revision 1.5
diff -p -r1.5 top.c
*** top.c	2000/03/23 23:43:19	1.5
--- top.c	2000/03/28 01:55:15
*************** print_gdb_version (stream)
*** 3173,3179 ****
  
    /* Second line is a copyright notice. */
  
!   fprintf_filtered (stream, "Copyright 1998 Free Software Foundation, Inc.\n");
  
    /* Following the copyright is a brief statement that the program is
       free software, that users are free to copy and change it on
--- 3173,3179 ----
  
    /* Second line is a copyright notice. */
  
!   fprintf_filtered (stream, "Copyright 2000 Free Software Foundation, Inc.\n");
  
    /* Following the copyright is a brief statement that the program is
       free software, that users are free to copy and change it on
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Heads up - Alpha ISO-C fixes
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BF7D8C.BE18FAAF@cygnus.com>
X-SW-Source: 2000-q1/msg00468.html
Content-length: 788

FYI,

I've got hold of an Alpha machine and am now able to work through all
the Alpha ISO-C errors (and oh, boy is it picky :-).

Using ChrisF's older patch as a guide, I know I'll be tweeking:

diff -upr gdb-19991116.orig/gdb/command.h gdb-19991116/gdb/command.h
+++ gdb-19991116/gdb/command.h  Sat Sep 25 03:59:38 1999
diff -upr gdb-19991116.orig/gdb/findvar.c gdb-19991116/gdb/findvar.c
+++ gdb-19991116/gdb/findvar.c  Tue Nov 23 14:50:48 1999
diff -upr gdb-19991116.orig/gdb/target.c gdb-19991116/gdb/target.c
+++ gdb-19991116/gdb/target.c   Tue Nov 23 15:11:12 1999

where the change is cosmetic (changing a K&R function into ISO-C) I'll
be just cheking it in.  For some, however (where a void* chashes with
some other type) I might toss out for the maintainers to chew on.

	Andrew
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Cc: ezannoni@cygnus.com
Subject: [PATCH]: minor fix for async
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003240034.QAA20870@cleaver.cygnus.com>
X-SW-Source: 2000-q1/msg00958.html
Content-length: 10023

I'd like to suggest this change, replacing a void pointer field
(which is sometimes used to hold an integer) with a union.  
This will prevent problems on hosts where an integer and a pointer
are not the same size.

2000-03-23  Michael Snyder  <msnyder@seadog.cygnus.com>

        * defs.h (struct continuation_arg): make 'data' a union, to avoid
        casting problems when int and pointer are not the  same size.
        event-top.c (command_handler): use data as a union.
        (command_line_handler_continuation): ditto.
        * infcmd.c (step_1_continuation): use data as a union.
        (step_once): ditto.  (finish_command_continuation): ditto.
        (finish_command): ditto.  
        * breakpoint.c (until_break_command): use data as a union.
        (until_break_command_continuation): ditto.
        * utils.c (add_intermediate_continuation): fix typo in comment.

Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.170
diff -c -r1.170 ChangeLog
*** ChangeLog	2000/03/23 23:43:19	1.170
--- ChangeLog	2000/03/24 00:14:45
***************
*** 1,3 ****
--- 1,16 ----
+ 2000-03-23  Michael Snyder  <msnyder@seadog.cygnus.com>
+ 
+ 	* defs.h (struct continuation_arg): make 'data' a union, to avoid
+ 	casting problems when int and pointer are not the  same size.
+ 	* event-top.c (command_handler): use data as a union.
+ 	(command_line_handler_continuation): ditto.
+ 	* infcmd.c (step_1_continuation): use data as a union.
+ 	(step_once): ditto.  (finish_command_continuation): ditto.
+ 	(finish_command): ditto.  
+ 	* breakpoint.c (until_break_command): use data as a union.
+ 	(until_break_command_continuation): ditto.
+ 	* utils.c (add_intermediate_continuation): fix typo in comment.
+ 
  2000-03-23  Fernando Nasser  <fnasser@cygnus.com>
  
  	From David Whedon <dwhedon@gordian.com>
Index: defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.12
diff -c -r1.12 defs.h
*** defs.h	2000/03/14 02:37:25	1.12
--- defs.h	2000/03/24 00:14:45
***************
*** 650,656 ****
  struct continuation_arg
    {
      struct continuation_arg *next;
!     void *data;
    };
  
  struct continuation
--- 650,660 ----
  struct continuation_arg
    {
      struct continuation_arg *next;
!     union continuation_data {
!       void *pointer;
!       int   integer;
!       long  longint;
!     } data;
    };
  
  struct continuation
Index: event-top.c
===================================================================
RCS file: /cvs/src/src/gdb/event-top.c,v
retrieving revision 1.4
diff -c -r1.4 event-top.c
*** event-top.c	2000/03/19 12:30:38	1.4
--- event-top.c	2000/03/24 00:14:45
***************
*** 525,532 ****
  	(struct continuation_arg *) xmalloc (sizeof (struct continuation_arg));
        arg1->next = arg2;
        arg2->next = NULL;
!       arg1->data = (void *) time_at_cmd_start;
!       arg2->data = (void *) space_at_cmd_start;
        add_continuation (command_line_handler_continuation, arg1);
      }
  
--- 525,532 ----
  	(struct continuation_arg *) xmalloc (sizeof (struct continuation_arg));
        arg1->next = arg2;
        arg2->next = NULL;
!       arg1->data.integer = time_at_cmd_start;
!       arg2->data.integer = space_at_cmd_start;
        add_continuation (command_line_handler_continuation, arg1);
      }
  
***************
*** 572,579 ****
    extern int display_time;
    extern int display_space;
  
!   long time_at_cmd_start = (long) arg->data;
!   long space_at_cmd_start = (long) arg->next->data;
  
    bpstat_do_actions (&stop_bpstat);
    /*do_cleanups (old_chain); *//*?????FIXME????? */
--- 572,579 ----
    extern int display_time;
    extern int display_space;
  
!   long time_at_cmd_start  = arg->data.longint;
!   long space_at_cmd_start = arg->next->data.longint;
  
    bpstat_do_actions (&stop_bpstat);
    /*do_cleanups (old_chain); *//*?????FIXME????? */
Index: infcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/infcmd.c,v
retrieving revision 1.2
diff -c -r1.2 infcmd.c
*** infcmd.c	2000/02/23 15:53:33	1.2
--- infcmd.c	2000/03/24 00:14:45
***************
*** 576,602 ****
  step_1_continuation (arg)
       struct continuation_arg *arg;
  {
!  int count;
!  int skip_subroutines;
!  int single_inst;
! 
!  skip_subroutines = (int) arg->data;
!  single_inst = (int) (arg->next)->data;
!  count = (int) ((arg->next)->next)->data;
! 
!  if (stop_step)
!    {
!      /* FIXME: On nexti, this may have already been done (when we hit the
! 	step resume break, I think).  Probably this should be moved to
! 	wait_for_inferior (near the top).  */
  #if defined (SHIFT_INST_REGS)
!      SHIFT_INST_REGS ();
  #endif
!      step_once (skip_subroutines, single_inst, count - 1);
!    }
!  else
!    if (!single_inst || skip_subroutines)
!      do_exec_cleanups (ALL_CLEANUPS);
  }
  
  /* Do just one step operation. If count >1 we will have to set up a
--- 576,602 ----
  step_1_continuation (arg)
       struct continuation_arg *arg;
  {
!   int count;
!   int skip_subroutines;
!   int single_inst;
! 
!   skip_subroutines = arg->data.integer;
!   single_inst      = arg->next->data.integer;
!   count            = arg->next->next->data.integer;
! 
!   if (stop_step)
!     {
!       /* FIXME: On nexti, this may have already been done (when we hit the
! 	 step resume break, I think).  Probably this should be moved to
! 	 wait_for_inferior (near the top).  */
  #if defined (SHIFT_INST_REGS)
!       SHIFT_INST_REGS ();
  #endif
!       step_once (skip_subroutines, single_inst, count - 1);
!     }
!   else
!     if (!single_inst || skip_subroutines)
!       do_exec_cleanups (ALL_CLEANUPS);
  }
  
  /* Do just one step operation. If count >1 we will have to set up a
***************
*** 662,672 ****
        arg3 =
  	(struct continuation_arg *) xmalloc (sizeof (struct continuation_arg));
        arg1->next = arg2;
!       arg1->data = (PTR) skip_subroutines;
        arg2->next = arg3;
!       arg2->data = (PTR) single_inst;
        arg3->next = NULL;
!       arg3->data = (PTR) count;
        add_intermediate_continuation (step_1_continuation, arg1);
        proceed ((CORE_ADDR) -1, TARGET_SIGNAL_DEFAULT, 1);
      }
--- 662,672 ----
        arg3 =
  	(struct continuation_arg *) xmalloc (sizeof (struct continuation_arg));
        arg1->next = arg2;
!       arg1->data.integer = skip_subroutines;
        arg2->next = arg3;
!       arg2->data.integer = single_inst;
        arg3->next = NULL;
!       arg3->data.integer = count;
        add_intermediate_continuation (step_1_continuation, arg1);
        proceed ((CORE_ADDR) -1, TARGET_SIGNAL_DEFAULT, 1);
      }
***************
*** 1108,1116 ****
    struct breakpoint *breakpoint;
    struct cleanup *cleanups;
  
!   breakpoint = (struct breakpoint *) arg->data;
!   function = (struct symbol *) (arg->next)->data;
!   cleanups = (struct cleanup *) (arg->next->next)->data;
  
    if (bpstat_find_breakpoint (stop_bpstat, breakpoint) != NULL
        && function != 0)
--- 1108,1116 ----
    struct breakpoint *breakpoint;
    struct cleanup *cleanups;
  
!   breakpoint = (struct breakpoint *) arg->data.pointer;
!   function   = (struct symbol *)     arg->next->data.pointer;
!   cleanups   = (struct cleanup *)    arg->next->next->data.pointer;
  
    if (bpstat_find_breakpoint (stop_bpstat, breakpoint) != NULL
        && function != 0)
***************
*** 1225,1233 ****
        arg1->next = arg2;
        arg2->next = arg3;
        arg3->next = NULL;
!       arg1->data = (PTR) breakpoint;
!       arg2->data = (PTR) function;
!       arg3->data = (PTR) old_chain;
        add_continuation (finish_command_continuation, arg1);
      }
  
--- 1225,1233 ----
        arg1->next = arg2;
        arg2->next = arg3;
        arg3->next = NULL;
!       arg1->data.pointer = breakpoint;
!       arg2->data.pointer = function;
!       arg3->data.pointer = old_chain;
        add_continuation (finish_command_continuation, arg1);
      }
  
Index: breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.4
diff -c -r1.4 breakpoint.c
*** breakpoint.c	2000/03/21 20:41:39	1.4
--- breakpoint.c	2000/03/24 00:14:46
***************
*** 5686,5692 ****
  {
    struct cleanup *cleanups;
  
!   cleanups = (struct cleanup *) arg->data;
    do_exec_cleanups (cleanups);
  }
  
--- 5686,5692 ----
  {
    struct cleanup *cleanups;
  
!   cleanups = (struct cleanup *) arg->data.pointer;
    do_exec_cleanups (cleanups);
  }
  
***************
*** 5750,5757 ****
           the exec_cleanup_chain. */
        arg1 =
  	(struct continuation_arg *) xmalloc (sizeof (struct continuation_arg));
!       arg1->next = NULL;
!       arg1->data = (PTR) old_chain;
  
        add_continuation (until_break_command_continuation, arg1);
      }
--- 5750,5757 ----
           the exec_cleanup_chain. */
        arg1 =
  	(struct continuation_arg *) xmalloc (sizeof (struct continuation_arg));
!       arg1->next         = NULL;
!       arg1->data.pointer = old_chain;
  
        add_continuation (until_break_command_continuation, arg1);
      }
Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.5
diff -c -r1.5 utils.c
*** utils.c	2000/03/20 22:15:58	1.5
--- utils.c	2000/03/24 00:14:46
***************
*** 456,462 ****
      }
  }
  
! /* Add a continuation to the continuation list, the gloabl list
     intermediate_continuation. The new continuation will be added at the front.*/
  void
  add_intermediate_continuation (continuation_hook, arg_list)
--- 456,462 ----
      }
  }
  
! /* Add a continuation to the continuation list, the global list
     intermediate_continuation. The new continuation will be added at the front.*/
  void
  add_intermediate_continuation (continuation_hook, arg_list)
From fnasser@redhat.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFC] Better apropos patch
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D935D1.7AF0B073@redhat.com>
References: <Pine.LNX.4.10.10003221256250.20082-200000@propylaea.anduin.com>
X-SW-Source: 2000-q1/msg00916.html
Content-length: 537

Daniel Berlin wrote:
> 
> Won't double print, works *much* faster, properly displays prefixes.
> 
> Let me know what you guys think.
> 

Thanks for doing this Daniel.  I am eager to incorporate it.

It seems that your patch is not in GNU style though 
(unless the diff "> " are distorting it).

Can you double check it?


-- 
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 kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH RFA] testsuite changes needed for AIX 4.3
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000215230816.ZM2175@ocotillo.lan>
X-SW-Source: 2000-q1/msg00159.html
Content-length: 6628

I hereby reqest approval for committing the following changes:

	* gdb.base/pointers.c (usevar): New function.
	(main): Make sure that global variables v_int_pointer2, rptr,
	and y are all referenced someplace in the program by calling
	usevar() on them.  [Some linkers delete symbols which are
	never referenced.  The space remains, but there's no way to
	get a (symbolic) handle on the variable from the debugger.]

	* gdb.base/scope.exp: For powerpc-*-*, xfail the same tests
	that rs6000-*-* does.

Index: testsuite/gdb.base/pointers.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/pointers.c,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 pointers.c
--- pointers.c	1999/08/02 23:46:51	1.1.1.3
+++ pointers.c	2000/02/15 22:56:07
@@ -71,33 +71,26 @@ float ** ptr_to_ptr_to_float;
 
 int y;
 
+/* Do nothing function used for forcing some of the above variables to
+   be referenced by the program source.  If the variables are not
+   referenced, some linkers will remove the symbol from the symbol
+   table making it impossible to refer to the variable in gdb.  */
+void usevar (void *var) {}
+
 int main ()
 {
-    void dummy();
-    int more_code();
-    
-    /* Ensure that malloc is a pointer type; avoid use of "void" and any include files. */
-    /* extern char *malloc();*/
-
-    /*  void *malloc(size_t);*/
-    
-
-    
+  void dummy();
+  int more_code();
+  
 #ifdef usestubs
   set_debug_traps();
   breakpoint();
 #endif
   dummy();
-/*  v_int_pointer2 = &v_int_pointer;
-  v_unsigned_int_pointer = &v_int;
-  
-  y = (v_unsigned_int_pointer == v_double_pointer);
-  
-  x = v_unsigned_int_pointer * v_double_pointer;
-  
-  v_unsigned_int_pointer = v_double_pointer;
-  
-  v_unsigned_int_pointer = v_unsigned_int;*/
+
+  usevar (&v_int_pointer2);
+  usevar (&rptr);
+  usevar (&y);
 
   more_code ();
 
Index: testsuite/gdb.base/scope.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/scope.exp,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 scope.exp
--- scope.exp	1999/08/02 23:46:51	1.1.1.3
+++ scope.exp	2000/02/15 22:56:08
@@ -130,6 +130,7 @@ proc test_at_main {} {
     # Print scope1.c::filelocal_ro, which is 202
 
     if {$gcc_compiled} then { setup_xfail "rs6000-*-*" }
+    setup_xfail "powerpc-*-*"
     if {$hp_cc_compiler} then { setup_xfail "hppa2.0w-*-*" 11747CLLbs}
     if [gdb_test "print 'scope1.c'::filelocal_ro" "\\\$$decimal = 202" "print 'scope1.c'::filelocal_ro"  "No symbol \"scope1.c\" in current context.*" "print '$srcdir/$subdir/scope1.c'::filelocal_ro"] { 
       gdb_suppress_tests ; 
@@ -144,6 +145,7 @@ proc test_at_main {} {
 
 
     if {$gcc_compiled} then { setup_xfail "rs6000-*-*" }
+    setup_xfail "powerpc-*-*"
     if [gdb_test "print 'scope1.c'::foo::funclocal" "\\\$$decimal = 3" "print 'scope1.c'::foo::funclocal"  "No symbol \"scope1.c\" in current context.*" "print '$srcdir/$subdir/scope1.c'::foo::funclocal"] { 
       gdb_suppress_tests ; 
     }
@@ -157,6 +159,7 @@ proc test_at_main {} {
 
 
     if {$gcc_compiled} then { setup_xfail "rs6000-*-*" }
+    setup_xfail "powerpc-*-*"
     if [gdb_test "print 'scope1.c'::foo::funclocal_ro" "\\\$$decimal = 203" "print 'scope1.c'::foo::funclocal_ro"  "No symbol \"scope1.c\" in current context.*" "print '$srcdir/$subdir/scope1.c'::foo::funclocal_ro"] { 
       gdb_suppress_tests ; 
     }
@@ -170,6 +173,7 @@ proc test_at_main {} {
 
 
     if {$gcc_compiled} then { setup_xfail "rs6000-*-*" }
+    setup_xfail "powerpc-*-*"
     if [gdb_test "print 'scope1.c'::bar::funclocal" "\\\$$decimal = 4" "print 'scope1.c'::bar::funclocal"  "No symbol \"scope1.c\" in current context.*" "print '$srcdir/$subdir/scope1.c'::bar::funclocal"] { 
       gdb_suppress_tests ; 
     }
@@ -218,6 +222,7 @@ proc test_at_foo {} {
     # Print scope1.c::filelocal, which is 2
 
     if {$gcc_compiled} then { setup_xfail "rs6000-*-*" }
+    setup_xfail "powerpc-*-*"
     if [gdb_test "print 'scope1.c'::filelocal" "\\\$$decimal = 2" "print 'scope1.c'::filelocal at foo"  "No symbol \"scope1.c\" in current context.*" "print '$srcdir/$subdir/scope1.c'::filelocal"] { 
       gdb_suppress_tests ; 
     }
@@ -227,6 +232,7 @@ proc test_at_foo {} {
 	"print filelocal_bss at foo"
 
     if {$gcc_compiled} then { setup_xfail "rs6000-*-*" }
+    setup_xfail "powerpc-*-*"
     gdb_test "print 'scope1.c'::filelocal_bss" "\\\$$decimal = 102" "print 'scope1.c'::filelocal_bss at foo"  "No symbol \"scope1.c\" in current context.*" "print '$srcdir/$subdir/scope1.c'::filelocal_bss"
 
 
@@ -234,6 +240,7 @@ proc test_at_foo {} {
 	"print filelocal_ro at foo"
 
     if {$gcc_compiled} then { setup_xfail "rs6000-*-*" }
+    setup_xfail "powerpc-*-*"
     gdb_test "print 'scope1.c'::filelocal_ro" "\\\$$decimal = 202" "print 'scope1.c'::filelocal_ro at foo"  "No symbol \"scope1.c\" in current context.*" "print '$srcdir/$subdir/scope1.c'::filelocal_ro"
 
 
@@ -245,6 +252,7 @@ proc test_at_foo {} {
 	"print foo::funclocal at foo"
 
     if {$gcc_compiled} then { setup_xfail "rs6000-*-*" }
+    setup_xfail "powerpc-*-*"
     gdb_test "print 'scope1.c'::foo::funclocal" "\\\$$decimal = 3" "print 'scope1.c'::foo::funclocal at foo"  "No symbol \"scope1.c\" in current context.*" "print '$srcdir/$subdir/scope1.c'::foo::funclocal"
 
 
@@ -257,6 +265,7 @@ proc test_at_foo {} {
 	"print foo::funclocal_bss at foo"
 
     if {$gcc_compiled} then { setup_xfail "rs6000-*-*" }
+    setup_xfail "powerpc-*-*"
     gdb_test "print 'scope1.c'::foo::funclocal_bss" "\\\$$decimal = 103" "print 'scope1.c'::foo::funclocal_bss at foo"  "No symbol \"scope1.c\" in current context.*" "print '$srcdir/$subdir/scope1.c'::foo::funclocal_bss"
 
 
@@ -269,6 +278,7 @@ proc test_at_foo {} {
 	"print foo::funclocal_ro at foo"
 
     if {$gcc_compiled} then { setup_xfail "rs6000-*-*" }
+    setup_xfail "powerpc-*-*"
     gdb_test "print 'scope1.c'::foo::funclocal_ro" "\\\$$decimal = 203" "print 'scope1.c'::foo::funclocal_ro at foo"  "No symbol \"scope1.c\" in current context.*" "print '$srcdir/$subdir/scope1.c'::foo::funclocal_ro"
 
 
@@ -278,6 +288,7 @@ proc test_at_foo {} {
 	"print bar::funclocal at foo"
 
     if {$gcc_compiled} then { setup_xfail "rs6000-*-*" }
+    setup_xfail "powerpc-*-*"
     gdb_test "print 'scope1.c'::bar::funclocal" "\\\$$decimal = 4" "print 'scope1.c'::bar::funclocal at foo"  "No symbol \"scope1.c\" in current context.*" "print '$srcdir/$subdir/scope1.c'::bar::funclocal"
     gdb_stop_suppressing_tests;
 


-- 
Kevin Buettner
kev@primenet.com, kevinb@redhat.com
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gdb-patches@sourceware.cygnus.com
Subject: Re: Linux sigtramp detection code moved to its proper place
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D8ACDE.DA82F9E6@cygnus.com>
References: <200003201529.KAA10589@indy.delorie.com> <38D73C78.4B2B3562@cygnus.com> <200003220858.DAA12990@indy.delorie.com>
X-SW-Source: 2000-q1/msg00901.html
Content-length: 1013

Eli Zaretskii wrote:

> > As a suggestion from left field, I've wondered if gdb.base/selftest.exp
> > should be moved to gdb.wb/selftest.exp (wb == white box) so that people
> > can freely add additional white box tests to GDB.  Checking consistency
> > between config/djgpp/<that-file> and the GDB sources could be part of
> > that testsuite.
> 
> Does that mean that you always run the test suite before preparing the
> snapshots?  If so, how do you know whether a certain new failure is
> grave enough to prevent you from making the snapshot?  I mean, if the
> test for consistency in config/djgpp/<that-file> were added, and it
> failed, how would you know that this is not some minor regression
> (which I assume do happen in other parts of GDB)?

No a snapshot is just that.  No guarentee that it will even build :-/

The reason for suggesting a check in the testsuite was that someone
adding a new file would hopefully run the testsuite after adding their
badly named file and notice the failure.

	Andrew
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] Linux/i386 FPU registers fix
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003061615.e26GF0x03081@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00532.html
Content-length: 3512

FYI,

I checked in the attached patch.  It makes sure that GDB ignores the
reserved bits in the FPU state.

Mark


2000-03-06  Mark Kettenis  <kettenis@gnu.org>

	* i386-linux-nat.c (supply_fpregset): Mask off the reserved bits
	in *FPREGSETP.
	(convert_to_fpregset): Don't touch the reserved bits in *FPREGSETP.


Index: i386-linux-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-linux-nat.c,v
retrieving revision 1.3
diff -u -p -r1.3 i386-linux-nat.c
--- i386-linux-nat.c	2000/03/05 22:57:05	1.3
+++ i386-linux-nat.c	2000/03/06 16:04:44
@@ -393,28 +393,33 @@ void 
 supply_fpregset (elf_fpregset_t *fpregsetp)
 {
   int reg;
+  long l;
 
   /* Supply the floating-point registers.  */
   for (reg = 0; reg < 8; reg++)
     supply_register (FP0_REGNUM + reg, FPREG_ADDR (fpregsetp, reg));
 
-  supply_register (FCTRL_REGNUM, (char *) &fpregsetp->cwd);
-  supply_register (FSTAT_REGNUM, (char *) &fpregsetp->swd);
-  supply_register (FTAG_REGNUM,  (char *) &fpregsetp->twd);
+  /* We have to mask off the reserved bits in *FPREGSETP before
+     storing the values in GDB's register file.  */
+#define supply(REGNO, MEMBER)                                           \
+  l = fpregsetp->MEMBER & 0xffff;                                       \
+  supply_register (REGNO, (char *) &l)
+
+  supply (FCTRL_REGNUM, cwd);
+  supply (FSTAT_REGNUM, swd);
+  supply (FTAG_REGNUM, twd);
   supply_register (FCOFF_REGNUM, (char *) &fpregsetp->fip);
-  supply_register (FDS_REGNUM,   (char *) &fpregsetp->fos);
+  supply (FDS_REGNUM, fos);
   supply_register (FDOFF_REGNUM, (char *) &fpregsetp->foo);
-  
-  /* Extract the code segment and opcode from the  "fcs" member.  */
-  {
-    long l;
+
+#undef supply
 
-    l = fpregsetp->fcs & 0xffff;
-    supply_register (FCS_REGNUM, (char *) &l);
+  /* Extract the code segment and opcode from the  "fcs" member.  */
+  l = fpregsetp->fcs & 0xffff;
+  supply_register (FCS_REGNUM, (char *) &l);
 
-    l = (fpregsetp->fcs >> 16) & ((1 << 11) - 1);
-    supply_register (FOP_REGNUM, (char *) &l);
-  }
+  l = (fpregsetp->fcs >> 16) & ((1 << 11) - 1);
+  supply_register (FOP_REGNUM, (char *) &l);
 }
 
 /* Convert the valid floating-point register values in GDB's register
@@ -434,19 +439,28 @@ convert_to_fpregset (elf_fpregset_t *fpr
 	      &registers[REGISTER_BYTE (FP0_REGNUM + reg)],
 	      REGISTER_RAW_SIZE(FP0_REGNUM + reg));
 
+  /* We're not supposed to touch the reserved bits in *FPREGSETP.  */
+
 #define fill(MEMBER, REGNO)						\
   if (! valid || valid[(REGNO)])					\
-    memcpy (&fpregsetp->MEMBER, &registers[REGISTER_BYTE (REGNO)],	\
-	    sizeof (fpregsetp->MEMBER))
+    fpregsetp->MEMBER                                                   \
+      = ((fpregsetp->MEMBER & ~0xffff)                                  \
+         | (* (int *) &registers[REGISTER_BYTE (REGNO)] & 0xffff))
+
+#define fill_register(MEMBER, REGNO)                                    \
+  if (! valid || valid[(REGNO)])                                        \
+    memcpy (&fpregsetp->MEMBER, &registers[REGISTER_BYTE (REGNO)],      \
+            sizeof (fpregsetp->MEMBER))
 
   fill (cwd, FCTRL_REGNUM);
   fill (swd, FSTAT_REGNUM);
   fill (twd, FTAG_REGNUM);
-  fill (fip, FCOFF_REGNUM);
+  fill_register (fip, FCOFF_REGNUM);
   fill (foo, FDOFF_REGNUM);
-  fill (fos, FDS_REGNUM);
+  fill_register (fos, FDS_REGNUM);
 
 #undef fill
+#undef fill_register
 
   if (! valid || valid[FCS_REGNUM])
     fpregsetp->fcs
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: eliz@is.elta.co.il
Cc: jimb@zwingli.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: minor watchpoint code cleanup
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003192255.e2JMtcs00643@delius.kettenis.local>
References: <200003180006.TAA26919@zwingli.cygnus.com> <200003190944.EAA07454@indy.delorie.com>
X-SW-Source: 2000-q1/msg00792.html
Content-length: 808

   Date: Sun, 19 Mar 2000 04:44:56 -0500 (EST)
   From: Eli Zaretskii <eliz@delorie.com>

   > This is just a cosmetic change.  Let me know.
   > 
   > 2000-03-17  Jim Blandy  <jimb@redhat.com>
   > 
   > 	* i386v-nat.c (i386_insert_nonaligned_watchpoint): Use a
   > 	two-dimensional array, instead of faking it with explicit index
   > 	arithmetic.

   While we are talking: someone (H.J. Lu?) suggested to make the
   watchpoint insertion code common to all x86 targets.  What's the
   current say-so on this?

I haven't yet looked into the HW watchpoints yet.  We probably could
use the same logic for choosing the appropriate debug registers, but
the way the registers are accessed wil differ considerably among the
various i386 targets.  When fiddling the code we should keep
multi-arch in mind.

Mark
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: RDBrown@mira.net, RodneyBrown@pmsc.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: 20000117 portability patches
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AA58BB.16956F23@cygnus.com>
References: <200001260432.PAA00810@ppp188.dyn136.pacific.net.au>
X-SW-Source: 2000-q1/msg00176.html
Content-length: 793

Rodney Brown wrote:

> --- include/ansidecl.h.orig     Sat Dec 25 04:26:54 1999
> +++ include/ansidecl.h  Sat Jan 22 16:19:55 2000
> @@ -94,7 +94,7 @@
>  /* LINTLIBRARY */
> 
> 
> -#if defined (__STDC__) || defined (_AIX) || (defined (__mips) && defined (_SYSTYPE_SVR4)) || defined(_WIN32)
> +#if defined (__STDC__) || defined (_AIX) || (defined (__mips) && defined (_SYSTYPE_SVR4)) || defined(_WIN32) || defined(__DECC)
>  /* All known AIX compilers implement these things (but don't always
>     define __STDC__).  The RISC/OS MIPS compiler defines these things
>     in SVR4 mode, but does not define __STDC__.  */

FYI, the include/ansidecl.h patch needs to go to binutils@sourceware. 
Fortunatly, gdb and binutils have the a common CVS repository so it will
appear pretty quick.

	Andrew
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [PATCH] Fix texinfo problems...
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DBB937.126C95E@apple.com>
References: <38DB1875.4B504618@cygnus.com>
X-SW-Source: 2000-q1/msg00992.html
Content-length: 850

Andrew Cagney wrote:
> 
> Hello,
> 
> I've applied the attatched patch.  It probably isn't elegant and
> probably isn't the best way of handling this :-/ However, after applying
> it I'm able to use makeinfo versions 3.12, 3.12f and 4.0 :-)

*Please* don't add the node links back!!  I went to some trouble to get
rid of them all, because they make for an utter nightmare when you're
trying to add new material.  They're only useful if you want to link
nodes in some fashion other than that implied by the chapter/section
structure, and as of yet I haven't heard anyone come up with a good
rationale for linking in any other way.

The replication of the TOC node with ifinfo and ifhtml is sufficient
to make the manual generate correctly with three versions of texinfo,
so I'm mystified as to why you think these other changes are necessary...

Stan
From fnasser@cygnus.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: set rewindonsignal
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A30E94.F92D0E35@cygnus.com>
X-SW-Source: 2000-q1/msg00113.html
Content-length: 1408

We have two groups of users who want different behavior of gdb when a
signal is received as a consequence of a "call somefunction()" command.

One wants gdb to return to the state it was before and the other wants
gdb to stay in the stack frame where the signal was received, as this
can be used to debug some situations (note that, depending on the OS and
the context, this can result in a state where execution is not possible
anymore).

The way to get everyone happy is to add a "set rewindonsignal" which, if
"on", will cause the stack to be rewound and the context fully restored
when a signal happens on the inferior call.  It does not affect
breakpoints, which do stop in the frame where they occurred (even if
inner than a dummy frame).

The default will be "off", as the original gdb behavior was to stop
inside the frame.  I have changed this temporarily in the snapshots due
to a few bugs that we are working on, but as the switch will be
available for those affected (they can add it to their .gdbinit files),
I will revert in time for the next release.

If you think this may have any impact on your work please let me know
(but remember you can set the switch anyway you want).

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kettenis@wins.uva.nl
Cc: jimb@zwingli.cygnus.com, kevinb@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Linux sigtramp detection code moved to its proper place
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003201002.FAA09374@indy.delorie.com>
References: <200003162241.RAA19616@zwingli.cygnus.com> <1000316225504.ZM3009@ocotillo.lan> <npsnxp8ix6.fsf@zwingli.cygnus.com> <200003182227.RAA07058@indy.delorie.com> <200003192248.e2JMm1H00626@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00809.html
Content-length: 2218

>    How about i386linux-tdep.c, for example?
> 
> Yuck, that's ugly!

How is it uglier than i386gnu-nat.c?

> Is it really important that these Linux-specific files are correctly
> extracted on MS-DOS?  I believe your argument was about buggy tar
> programs floating around, but I don't think it is too much too ask
> people to fix their tar before trying to build GDB.

What would you suggest for a non-buggy Tar program to do, exactly?

Let's take GNU Tar, for example.  It specifically supports the case
where you can untar over an existing source tree, so it by default
silently overwrites existing files.  How can Tar tell whether the file
only *seems* to exist, due to the silent truncation of the long file
names by the OS?  I don't think it can, but I'd love to hear ideas.
(I spent lots of time making the DJGPP port of GNU Tar friendlier to
DOS/Windows systems, and solved many problems, but couldn't find any
good solution to this one.)

Sure, there are options such as --backup to take care of overwriting.
But you don't want to trust users to use non-default options, because
they will surely forget (and yours truly then gets to answer the FAQs
on comp.os.msdos.djgpp ;-).

Besides, --backup only prevents files from being overwritten, but it
still leaves it to the user to sort out the mess it left behind (by
deleting unneeded files, renaming needed ones, etc.).  How exactly do
we expect the user to know which files are needed and which aren't?

Also, --backup cannot help much when you are unpacking over an
existing tree.

Then there's DJTAR, supplied as part of the DJGPP development kit.
This makes a point of refusing to overwrite files (so it doesn't
support updating existing trees).  But it does so by prompting for a
new name for each file which seems to exist.  Try to unpack a distro
with a few dozens of such files, and reflect on the resulting
frustration...

In other words, a distribution which has too many files whose names
clash after truncation to 8+3 limits cannot in good faith claim that
it supports DJGPP.  And the goal of the DJGPP project is to have all
major GNU packages support DJGPP in their official distributions, to
prevent wasting effort on re-porting each release.
From dima@Chg.RU Sat Apr 01 00:00:00 2000
From: Dmitry Sivachenko <dima@Chg.RU>
To: eliz@delorie.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: patch for gdb.texinfo
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001301809.VAA59866@netserv1.chg.ru>
References: <200001281722.MAA28565@indy.delorie.com>
X-SW-Source: 2000-q1/msg00048.html
Content-length: 1085

> Dmitry Sivachenko writes:
>
> > > Why is it a good idea to remove the @dfn here?
> > 
> > Because there is no definition of 'dynamic arrays' here in the text.
>
> @dfn is not only for something that is being defined.  Here's what the
> Texinfo manual says:
>
>     Use the `@dfn' command to identify the introductory or defining use
>     of a technical term.  Use the command only in passages whose purpose is
>     to introduce a term which will be used again or which the reader ought
>     to know.  Mere passing mention of a term for the first time does not
>     deserve @dfn.
>
> This doesn't seem to be limited to text that defines a term.  It does
> say that if the term is never to be used again, it doesn't deserve a
> @dfn.  OTOH, if ``dynamic arrays'' aren't mentioned anywhere else,
> then why was it important to mention them here?  Perhaps it should be
> removed altogether.

Yes, it is just a mention of 'dynamic arrays' there.  So we should exclude
any emphasis there.  But we may leave the words 'dynamic array', because
it is well known what it means...

--dima

Re: patch for gdb.texinfo

[Eli Zaretskii]

On Sun, 27 Jan 2002, Dmitry Sivachenko wrote:

> Could you please apply the following patch to gdb.texinfo.

Thanks, I applied them with the exception of this one:

> -The command @code{info symbol 0x54320} yields similar results.
> +The command @samp{info symbol 0x54320} yields similar results.
>  @xref{Symbols, info symbol}.

I didn't make this change because the GDB manual traditionally uses
@code for all the commands it describes.

patch for gdb.texinfo

[Dmitry Sivachenko]

Hello!

Could you please apply the following patch to gdb.texinfo.

Thank you in advance,
--mitya



--- gdb.texinfo.orig    Sun Jan 27 02:35:39 2002
+++ gdb.texinfo Sun Jan 27 02:35:41 2002
@@ -4699,7 +4699,7 @@
 @end example
 
 @noindent
-The command @code{info symbol 0x54320} yields similar results.
+The command @samp{info symbol 0x54320} yields similar results.
 @xref{Symbols, info symbol}.
 
 @item c
@@ -5584,23 +5584,23 @@
 
 @table @code
 @kindex mem
-@item mem @var{address1} @var{address1} @var{attributes}@dots{}
+@item mem @var{address1} @var{address2} @var{attributes}@dots{}
 Define memory region bounded by @var{address1} and @var{address2}
 with attributes @var{attributes}@dots{}.
 
 @kindex delete mem
 @item delete mem @var{nums}@dots{}
-Remove memory region numbers @var{nums}.
+Remove memory regions @var{nums}@dots{}.
 
 @kindex disable mem
 @item disable mem @var{nums}@dots{}
-Disable memory region numbers @var{nums}.
+Disable memory regions @var{nums}@dots{}.
 A disabled memory region is not forgotten.  
 It may be enabled again later.
 
 @kindex enable mem
 @item enable mem @var{nums}@dots{}
-Enable memory region numbers @var{nums}.
+Enable memory regions @var{nums}@dots{}.
 
 @kindex info mem
 @item info mem