From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Sivachenko To: shebs@shebs.cnchost.com Cc: eliz@is.elta.co.il, gdb-patches@sourceware.cygnus.com Subject: Re: patch for gdb.texinfo Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200001281711.UAA05817@netserv1.chg.ru> References: <3891CD13.A68984BA@shebs.cnchost.com> X-SW-Source: 2000-q1/msg00042.html > (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 Cc: Kevin Buettner , Andrew Cagney , GDB Patches 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: X-SW-Source: 2000-q1/msg00677.html Content-length: 640 >>>>> "Daniel" == Daniel Berlin 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" 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 To: Jonathan Larmour , GDB Patches 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 * 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 To: GDB Patches 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 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 * 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 + + * 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 From David Whedon 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 To: Daniel Berlin 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: 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 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 To: Eli Zaretskii Cc: Mark Kettenis , 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/ 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/ 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 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 * 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 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 > This is just a cosmetic change. Let me know. > > 2000-03-17 Jim Blandy > > * 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 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 To: Andrew Cagney Cc: GDB Patches 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 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 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> <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 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