* Re: patch for gdb.texinfo
2000-04-01 0:00 ` Stan Shebs
@ 2000-04-01 0:00 ` Dmitry Sivachenko
0 siblings, 0 replies; 4+ messages in thread
From: Dmitry Sivachenko @ 2000-04-01 0:00 UTC (permalink / raw)
To: shebs; +Cc: eliz, gdb-patches
> (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
®isters[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, ®isters[REGISTER_BYTE (REGNO)], \
- sizeof (fpregsetp->MEMBER))
+ fpregsetp->MEMBER \
+ = ((fpregsetp->MEMBER & ~0xffff) \
+ | (* (int *) ®isters[REGISTER_BYTE (REGNO)] & 0xffff))
+
+#define fill_register(MEMBER, REGNO) \
+ if (! valid || valid[(REGNO)]) \
+ memcpy (&fpregsetp->MEMBER, ®isters[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
^ permalink raw reply [flat|nested] 4+ messages in thread