From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Guy Harris Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Minor fix to comment in "minsyms.c" Date: Wed, 19 Apr 2000 14:13:00 -0000 Message-id: References: <200004190133.SAA27375@tooting> X-SW-Source: 2000-04/msg00381.html Thanks, I've committed this. > "I see no MSYMBOL_HASH_ADD here." One version of the minsyms hashing > patch had that macro, but the code in the CVS tree has the > "add_minsym_to_hash_table()" function instead. > > *** /u/guy/src/cmd/gdb-cygnus-cvs/gdb/minsyms.c Tue Apr 18 17:35:37 2000 > --- ./minsyms.c Tue Apr 18 17:55:52 2000 > *************** > *** 685,691 **** > MSYMBOL_INFO (msymbol) = info; /* FIXME! */ > > /* The hash pointers must be cleared! If they're not, > ! MSYMBOL_HASH_ADD will NOT add this msymbol to the hash table. */ > msymbol->hash_next = NULL; > msymbol->demangled_hash_next = NULL; > > --- 685,691 ---- > MSYMBOL_INFO (msymbol) = info; /* FIXME! */ > > /* The hash pointers must be cleared! If they're not, > ! add_minsym_to_hash_table will NOT add this msymbol to the hash table. */ > msymbol->hash_next = NULL; > msymbol->demangled_hash_next = NULL; > > >From jimb@zwingli.cygnus.com Wed Apr 19 14:20:00 2000 From: Jim Blandy To: Andrew Cagney Cc: Jim Blandy , gdb-patches@sourceware.cygnus.com Subject: Re: RFA: gdbarchify RETURN_VALUE_ON_STACK Date: Wed, 19 Apr 2000 14:20:00 -0000 Message-id: References: <200004182327.SAA10393@zwingli.cygnus.com> <38FD0067.82067D1E@cygnus.com> X-SW-Source: 2000-04/msg00382.html Content-length: 1126 > > 2000-04-17 Jim Blandy > > > > Bring RETURN_VALUE_ON_STACK under gdbarch's control. > > * gdbarch.sh (RETURN_VALUE_ON_STACK): New entry. > > * gdbarch.c, gdbarch.h: Regenerated. > > * arch-utils.c (default_return_value_on_stack): New function. > > * arch-utils.h (default_return_value_on_stack): New declaration. > > I'd suggest the function name ``generic_return_value_on_stack_not'' (I > know the name grates) declared as: > extern gdbarch_return_value_on_stack_ftype ...; > > For the arch line, I'd suggest the change: > > - f:2:RETURN_VALUE_ON_STACK:int:return_value_on_stack:struct type > *type:type:::default_return_value_on_stack > + f:2:RETURN_VALUE_ON_STACK:int:return_value_on_stack:struct type > *type:type:::default_return_value_on_stack:0 > > (I think I've set valid_p=0). The generated gdbarch.[hc] will then > always provide a default. That in turn allowing the #ifndef > RETURN_VALUE_ON_STACK in values.c to be deleted. Have a look at > REGISTER_NAME. > > After that its ok, Okay --- I've made these changes, and will commit the result. >From ac131313@cygnus.com Wed Apr 19 16:07:00 2000 From: Andrew Cagney To: Alexandre Oliva Cc: Jim Blandy , gdb-patches@sourceware.cygnus.com Subject: Re: RFA: gdbarch IEEE_FLOAT Date: Wed, 19 Apr 2000 16:07:00 -0000 Message-id: <38FE3BC3.99920D3C@cygnus.com> References: <200004110302.WAA13962@zwingli.cygnus.com> <38F41405.8F24928@cygnus.com> X-SW-Source: 2000-04/msg00383.html Content-length: 689 Alexandre Oliva wrote: > > On Apr 14, 2000, Jim Blandy wrote: > > >> BTW, the need to add the below is going away soon. I've pending > >> multi-arch patches that will provide this as a non- multi-arch default. > >> > >> > + /* Provide a default value for IEEE_FLOAT. */ > >> > + #ifndef IEEE_FLOAT > >> > + #define IEEE_FLOAT (0) > >> > + #endif > > > Sounds great to me! > > BTW, are you aware that gdbarch.c fails to compile on a single-arch > build whose target header file doesn't define IEEE_FLOAT? For > example, I've configured --target=mn10300-elf, and gdbarch.c won't > build because IEEE_FLOAT is not defined. I believe this was fixed. Andrew >From ac131313@cygnus.com Wed Apr 19 17:49:00 2000 From: Andrew Cagney To: BINUTILS Patches Cc: Eli Zaretskii , gdb-patches@sourceware.cygnus.com Subject: Re: Problems with snapshot 20000412 Date: Wed, 19 Apr 2000 17:49:00 -0000 Message-id: <38FE53D4.F249A6FA@cygnus.com> References: <200004160807.EAA10378@indy.delorie.com> <38FD3F8C.B30CA4BF@cygnus.com> <200004190745.DAA14311@indy.delorie.com> <38FD6E92.8B94D0A0@cygnus.com> X-SW-Source: 2000-04/msg00384.html Content-length: 1895 [Mailing lists changed, take care] Hello, The automake-000227.tar.bz2 snapshot contains the bug fixed by the patch: http://sourceware.cygnus.com/cgi-bin/cvsweb.cgi/automake/automake.in.diff?r1=1.652&r2=1.653&cvsroot=automake The bug causes bfd/doc/Makefile.in to contain bogus lines like: .texi.dvi: TEXINPUTS=$(top_srcdir)/../texinfo/texinfo.tex:$$TEXINPUTS \ MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) $< (the ``/texinfo.tex'' shouldn't be there). This in turn (as Eli notes :-) leads to a failed (when there is no pre-installed texinfo.tex) or broken (when there is) build. Could I suggest an update to the automake snapshot. Then a fixed bfd/doc/Makefile.in can be re-generated (gdb-5.0 and binutils-N.NN branches + trunk). enjoy, Andrew Andrew Cagney wrote: > > Eli Zaretskii wrote: > > > > > It doesn't appear to affect the build > > > > Really? Did you try renaming your system-wide texinfo.tex (somewhere > > in the TeX installation tree)? > > Hmm, ok, yes point taken :-) > > > The special setting of TEXINPUTS before invoking TeX-related commands > > is there to make sure that the manual is produced using the specific > > version of texinfo.tex that was used by the maintainer(s), because > > another version of texinfo.tex might produce incorrect results or even > > fail. If you have the same or compatible version of texinfo.tex in > > another place where TeX can find it, you won't see the problems caused > > by TEXINPUTS being set incorrectly. > > Its already been reported: > > http://sourceware.cygnus.com/ml/bug-automake/1999/msg00007.html > > and the follow up: > > http://sourceware.cygnus.com/ml/bug-automake/1999/msg00019.html > > claims: > > > > TEXINPUTS should be a list of directories. > > > > Yup, this has been fixed in the CVS tree for quite some time. > > I'll double check my automake tools. > > Andrew >From jimb@zwingli.cygnus.com Wed Apr 19 18:34:00 2000 From: Jim Blandy To: Eli Zaretskii Cc: shebs@apple.com, gdb-patches@sourceware.cygnus.com Subject: Re: RFA: Document RETURN_VALUE_ON_STACK Date: Wed, 19 Apr 2000 18:34:00 -0000 Message-id: References: <200004181954.OAA08866@zwingli.cygnus.com> <38FCC3DD.533C7037@apple.com> <200004190737.DAA14301@indy.delorie.com> X-SW-Source: 2000-04/msg00385.html Content-length: 729 > From: Jim Blandy > Date: 18 Apr 2000 17:29:43 -0500 > > > + @item RETURN_VALUE_ON_STACK(@var{type}) > > I think gdbint.texinfo needs to index all the functions and macros it > documents. I know that some victim^H^H^H^H^H^Hvolunteer should go > through the entire file and add the indexing for what's already there, > but there should be no reason to make that job larger. > > So could we _please_ start adding such index entries to every new > function/macro/variable we add to the manual? I suggest @findex for > functions and macros and @vindex for variables (if there are any). I think we should be using @deftypefn for everything; that will build a function index for us automatically. No? >From ac131313@cygnus.com Wed Apr 19 21:23:00 2000 From: Andrew Cagney To: Jim Blandy Cc: gdb-patches@sourceware.cygnus.com Subject: Re: RFA: gdbarch IEEE_FLOAT Date: Wed, 19 Apr 2000 21:23:00 -0000 Message-id: <38FE85F2.5472031@cygnus.com> References: <200004110302.WAA13962@zwingli.cygnus.com> <38F41405.8F24928@cygnus.com> <38FA86D1.2E4CB93D@cygnus.com> X-SW-Source: 2000-04/msg00386.html Content-length: 818 Jim Blandy wrote: > > > > > > + /* Provide a default value for IEEE_FLOAT. */ > > > > > + #ifndef IEEE_FLOAT > > > > > + #define IEEE_FLOAT (0) > > > > > + #endif > > > > > > Sounds great to me! > > > > BTW, is the default ``0'' or ``1''? The above has zero, but for > > multi-arch it is set to one. (Just let me know, I'll tweek it when I > > remove it :-). > > Well, for old targets it has to be zero. > > I was thinking that, for new gdbarch-style targets, 1 was the more > convenient default, but on more careful reflection, I'm not sure > that's smart: if someone is converting an existing port to gdbarch, it > would be very confusing for IEEE_FLOAT to suddenly change its default > value. > > So the default should be zero. Everyone multi-arching please note. I've just committed this change. Andrew >From ac131313@cygnus.com Wed Apr 19 21:25:00 2000 From: Andrew Cagney To: GDB Patches Subject: Re: [RFC] Cleanup (TARGET_BFD_VMA_BIT, IEEE_FLOAT, CALL_DUMMY_WORDS and SIZEOF_CALL_DUMMY_WORDS Date: Wed, 19 Apr 2000 21:25:00 -0000 Message-id: <38FE8668.719EEF2C@cygnus.com> References: <38FA8EF2.BC8ACBFD@cygnus.com> X-SW-Source: 2000-04/msg00387.html Content-length: 1085 Andrew Cagney wrote: > > Hello, > > The attatched patch does to several multi-arch variables what my > previous patch did to functions. It changes gdbarch.h so that it > provides the default for both the multi-arch and non- multi-arch cases. > > (It isn't final as I need info from JimB) > > I'll look to apply it in a few days once the last patch has settled > down. > > Andrew > > ------------------------------------------------------------------------ > Mon Apr 17 13:37:10 2000 Andrew Cagney > > * gdbarch.sh: Make multi-arch variable defaults, defaults for non- > multi-arch targets. > (TARGET_BFD_VMA_BIT, IEEE_FLOAT, CALL_DUMMY_WORDS, > SIZEOF_CALL_DUMMY_WORDS): Update. > > * inferior.h (CALL_DUMMY_WORDS, SIZEOF_CALL_DUMMY_WORDS): Default > provided by gdbarch. > (CALL_DUMMY_P): Add FIXME. gdbarch should provide default. > > * valprint.c (IEEE_FLOAT): Default provided by gdbarch. I've committed this change to the trunk. IEEE_FLOAT is zero by default. Andrew >From ac131313@cygnus.com Thu Apr 20 01:09:00 2000 From: Andrew Cagney To: GDB Patches Subject: [RFC] Convert STACK_ALIGN to multi-arch .... Date: Thu, 20 Apr 2000 01:09:00 -0000 Message-id: <38FEBAE3.D0FD616D@cygnus.com> X-SW-Source: 2000-04/msg00388.html Content-length: 9322 Hello, The attached patch converts the STACK_ALIGN macro into a multi-arch runtime test/call. What was: #ifdef STACK_ALIGN x = STACK_ALIGN (x) #endif becomes if (STACK_ALIGN_P ()) x = STACK_ALIGN (x); The need for a predicate becomes clear if you look at valops.c. How it handles all the possible compatibility cases is pretty confusing so I'll quickly go through each case I thought of: !multi-arch && !defined (STACK_ALIGN) A legacy system that doesn't define STACK_ALIGN. STACK_ALIGN_P() is defined as gdbarch_stack_align_p() which will always return 0 (the stack_align function is never set). STACK_ALIGN() is defined as gdbarch_stack_align() which keeps things compiling. !multi-arch && defined (STACK_ALIGN) Legacy system providing STACK_ALIGN macro in tm.h. multi-arch && defined (STACK_ALIGN) Hybrid system (ex d10v) providing STACK_ALIGN macro in tm.h. That legacy #ifdef STACK_ALIGN in gdbarch.h forces STACK_ALIGN_P() to 1. multi-arch && !defined (STACK_ALIGN) normal case. Both STACK_ALIGN_P() and STACK_ALIGN() are mapped onto functions like any other gdbarch case. can anyone think of any other cases (did I get these cases right :-)? Other thoughts. Andrew Thu Apr 20 14:35:46 2000 Andrew Cagney * valops.c (hand_function_call): Replace #ifdef STACK_ALIGN with run-time test for STACK_ALIGN_P. * gdbarch.sh: Add support for function and variable predicates. (STACK_ALIGN): Add. Implement with predicate - STACK_ALIGN_P. Index: gdbarch.c =================================================================== RCS file: /cvs/src/src/gdb/gdbarch.c,v retrieving revision 1.14 diff -p -r1.14 gdbarch.c *** gdbarch.c 2000/04/20 04:24:03 1.14 --- gdbarch.c 2000/04/20 07:49:16 *************** struct gdbarch *** 213,218 **** --- 213,219 ---- gdbarch_frame_locals_address_ftype *frame_locals_address; gdbarch_saved_pc_after_call_ftype *saved_pc_after_call; gdbarch_frame_num_args_ftype *frame_num_args; + gdbarch_stack_align_ftype *stack_align; }; *************** struct gdbarch startup_gdbarch = { *** 317,322 **** --- 318,324 ---- 0, 0, 0, + 0, /* startup_gdbarch() */ }; struct gdbarch *current_gdbarch = &startup_gdbarch; *************** verify_gdbarch (struct gdbarch *gdbarch) *** 620,625 **** --- 622,628 ---- if ((GDB_MULTI_ARCH >= 2) && (gdbarch->frame_num_args == 0)) internal_error ("gdbarch: verify_gdbarch: frame_num_args invalid"); + /* Skip verify of stack_align, has predicate */ } *************** gdbarch_dump (void) *** 955,960 **** --- 958,967 ---- "gdbarch_update: FRAME_NUM_ARGS = 0x%08lx\n", (long) current_gdbarch->frame_num_args /*FRAME_NUM_ARGS ()*/); + fprintf_unfiltered (gdb_stdlog, + "gdbarch_update: STACK_ALIGN = 0x%08lx\n", + (long) current_gdbarch->stack_align + /*STACK_ALIGN ()*/); } struct gdbarch_tdep * *************** set_gdbarch_frame_num_args (struct gdbar *** 2485,2490 **** --- 2492,2520 ---- gdbarch_frame_num_args_ftype frame_num_args) { gdbarch->frame_num_args = frame_num_args; + } + + int + gdbarch_stack_align_p (struct gdbarch *gdbarch) + { + return gdbarch->stack_align != 0; + } + + CORE_ADDR + gdbarch_stack_align (struct gdbarch *gdbarch, CORE_ADDR sp) + { + if (gdbarch->stack_align == 0) + internal_error ("gdbarch: gdbarch_stack_align invalid"); + if (gdbarch_debug >= 2) + fprintf_unfiltered (gdb_stdlog, "gdbarch_stack_align called\n"); + return gdbarch->stack_align (sp); + } + + void + set_gdbarch_stack_align (struct gdbarch *gdbarch, + gdbarch_stack_align_ftype stack_align) + { + gdbarch->stack_align = stack_align; } Index: gdbarch.h =================================================================== RCS file: /cvs/src/src/gdb/gdbarch.h,v retrieving revision 1.10 diff -p -r1.10 gdbarch.h *** gdbarch.h 2000/04/20 04:24:04 1.10 --- gdbarch.h 2000/04/20 07:49:19 *************** extern void set_gdbarch_frame_num_args ( *** 798,803 **** --- 798,820 ---- #endif #endif + #if defined (STACK_ALIGN) + /* Legacy for systems yet to multi-arch STACK_ALIGN */ + #define STACK_ALIGN_P() (1) + #endif + + extern int gdbarch_stack_align_p (struct gdbarch *gdbarch); + #if (GDB_MULTI_ARCH > 1) || !defined (STACK_ALIGN_P) + #define STACK_ALIGN_P() (gdbarch_stack_align_p (current_gdbarch)) + #endif + + typedef CORE_ADDR (gdbarch_stack_align_ftype) (CORE_ADDR sp); + extern CORE_ADDR gdbarch_stack_align (struct gdbarch *gdbarch, CORE_ADDR sp); + extern void set_gdbarch_stack_align (struct gdbarch *gdbarch, gdbarch_stack_align_ftype *stack_align); + #if (GDB_MULTI_ARCH > 1) || !defined (STACK_ALIGN) + #define STACK_ALIGN(sp) (gdbarch_stack_align (current_gdbarch, sp)) + #endif + extern struct gdbarch_tdep *gdbarch_tdep (struct gdbarch *gdbarch); Index: valops.c =================================================================== RCS file: /cvs/src/src/gdb/valops.c,v retrieving revision 1.10 diff -p -r1.10 valops.c *** valops.c 2000/04/17 02:27:37 1.10 --- valops.c 2000/04/20 07:49:30 *************** You must use a pointer to function type *** 1534,1547 **** arg_type = check_typedef (VALUE_ENCLOSING_TYPE (args[i])); len = TYPE_LENGTH (arg_type); ! #ifdef STACK_ALIGN ! /* MVS 11/22/96: I think at least some of this stack_align code is ! really broken. Better to let PUSH_ARGUMENTS adjust the stack in ! a target-defined manner. */ ! aligned_len = STACK_ALIGN (len); ! #else ! aligned_len = len; ! #endif if (INNER_THAN (1, 2)) { /* stack grows downward */ --- 1534,1547 ---- arg_type = check_typedef (VALUE_ENCLOSING_TYPE (args[i])); len = TYPE_LENGTH (arg_type); ! if (STACK_ALIGN_P ()) ! /* MVS 11/22/96: I think at least some of this ! stack_align code is really broken. Better to let ! PUSH_ARGUMENTS adjust the stack in a target-defined ! manner. */ ! aligned_len = STACK_ALIGN (len); ! else ! aligned_len = len; if (INNER_THAN (1, 2)) { /* stack grows downward */ *************** You must use a pointer to function type *** 1583,1594 **** if (struct_return) { int len = TYPE_LENGTH (value_type); ! #ifdef STACK_ALIGN ! /* MVS 11/22/96: I think at least some of this stack_align code is ! really broken. Better to let PUSH_ARGUMENTS adjust the stack in ! a target-defined manner. */ ! len = STACK_ALIGN (len); ! #endif if (INNER_THAN (1, 2)) { /* stack grows downward */ --- 1583,1593 ---- if (struct_return) { int len = TYPE_LENGTH (value_type); ! if (STACK_ALIGN_P ()) ! /* MVS 11/22/96: I think at least some of this stack_align ! code is really broken. Better to let PUSH_ARGUMENTS adjust ! the stack in a target-defined manner. */ ! len = STACK_ALIGN (len); if (INNER_THAN (1, 2)) { /* stack grows downward */ *************** You must use a pointer to function type *** 1609,1619 **** hppa_push_arguments */ #ifndef NO_EXTRA_ALIGNMENT_NEEDED - #if defined(STACK_ALIGN) /* MVS 11/22/96: I think at least some of this stack_align code is really broken. Better to let PUSH_ARGUMENTS adjust the stack in a target-defined manner. */ ! if (INNER_THAN (1, 2)) { /* If stack grows down, we must leave a hole at the top. */ int len = 0; --- 1608,1617 ---- hppa_push_arguments */ #ifndef NO_EXTRA_ALIGNMENT_NEEDED /* MVS 11/22/96: I think at least some of this stack_align code is really broken. Better to let PUSH_ARGUMENTS adjust the stack in a target-defined manner. */ ! if (STACK_ALIGN_P () && INNER_THAN (1, 2)) { /* If stack grows down, we must leave a hole at the top. */ int len = 0; *************** You must use a pointer to function type *** 1624,1630 **** len += CALL_DUMMY_STACK_ADJUST; sp -= STACK_ALIGN (len) - len; } - #endif /* STACK_ALIGN */ #endif /* NO_EXTRA_ALIGNMENT_NEEDED */ sp = PUSH_ARGUMENTS (nargs, args, sp, struct_return, struct_addr); --- 1622,1627 ---- *************** You must use a pointer to function type *** 1642,1649 **** sp = PUSH_RETURN_ADDRESS (real_pc, sp); #endif /* PUSH_RETURN_ADDRESS */ ! #if defined(STACK_ALIGN) ! if (!INNER_THAN (1, 2)) { /* If stack grows up, we must leave a hole at the bottom, note that sp already has been advanced for the arguments! */ --- 1639,1645 ---- sp = PUSH_RETURN_ADDRESS (real_pc, sp); #endif /* PUSH_RETURN_ADDRESS */ ! if (STACK_ALIGN_P () && !INNER_THAN (1, 2)) { /* If stack grows up, we must leave a hole at the bottom, note that sp already has been advanced for the arguments! */ *************** You must use a pointer to function type *** 1651,1657 **** sp += CALL_DUMMY_STACK_ADJUST; sp = STACK_ALIGN (sp); } - #endif /* STACK_ALIGN */ /* XXX This seems wrong. For stacks that grow down we shouldn't do anything here! */ --- 1647,1652 ---- >From ac131313@cygnus.com Thu Apr 20 01:30:00 2000 From: Andrew Cagney To: GDB Patches Subject: [RFC] Convert d10v's STACK_ALIGN; Was: [RFC] Convert STACK_ALIGN to multi-arch .... Date: Thu, 20 Apr 2000 01:30:00 -0000 Message-id: <38FEBFF2.DCB46367@cygnus.com> References: <38FEBAE3.D0FD616D@cygnus.com> X-SW-Source: 2000-04/msg00389.html Content-length: 1934 Hello, The attatched is a follow-on to the previous STACK_ALIGN patch. It updates the d10v. Andrew Thu Apr 20 18:15:08 2000 Andrew Cagney * d10v-tdep.c (d10v_gdbarch_init): Initialize stack_align. (d10v_stack_align): Make static. * config/d10v/tm-d10v.h (STACK_ALIGN): Delete. Index: d10v-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/d10v-tdep.c,v retrieving revision 1.2 diff -p -r1.2 d10v-tdep.c *** d10v-tdep.c 2000/02/09 04:46:47 1.2 --- d10v-tdep.c 2000/04/20 08:25:38 *************** d10v_frame_chain_valid (chain, frame) *** 104,110 **** return ((chain) != 0 && (frame) != 0 && (frame)->pc > IMEM_START); } ! CORE_ADDR d10v_stack_align (CORE_ADDR len) { return (len + 1) & ~1; --- 104,110 ---- return ((chain) != 0 && (frame) != 0 && (frame)->pc > IMEM_START); } ! static CORE_ADDR d10v_stack_align (CORE_ADDR len) { return (len + 1) & ~1; *************** d10v_gdbarch_init (info, arches) *** 1655,1660 **** --- 1655,1661 ---- set_gdbarch_frame_locals_address (gdbarch, d10v_frame_locals_address); set_gdbarch_saved_pc_after_call (gdbarch, d10v_saved_pc_after_call); set_gdbarch_frame_num_args (gdbarch, frame_num_args_unknown); + set_gdbarch_stack_align (gdbarch, d10v_stack_align); return gdbarch; } Index: config/d10v/tm-d10v.h =================================================================== RCS file: /cvs/src/src/gdb/config/d10v/tm-d10v.h,v retrieving revision 1.2 diff -p -r1.2 tm-d10v.h *** tm-d10v.h 2000/02/09 04:46:47 1.2 --- tm-d10v.h 2000/04/20 08:25:38 *************** *** 25,31 **** extern int d10v_register_sim_regno (int reg); #define REGISTER_SIM_REGNO(NR) d10v_register_sim_regno((NR)) - extern CORE_ADDR d10v_stack_align (CORE_ADDR size); - #define STACK_ALIGN(SIZE) (d10v_stack_align (SIZE)) - #define NO_EXTRA_ALIGNMENT_NEEDED 1 --- 25,28 ---- >From eliz@delorie.com Thu Apr 20 02:24:00 2000 From: Eli Zaretskii To: jimb@cygnus.com Cc: shebs@apple.com, gdb-patches@sourceware.cygnus.com Subject: Re: RFA: Document RETURN_VALUE_ON_STACK Date: Thu, 20 Apr 2000 02:24:00 -0000 Message-id: <200004200924.FAA15717@indy.delorie.com> References: <200004181954.OAA08866@zwingli.cygnus.com> <38FCC3DD.533C7037@apple.com> <200004190737.DAA14301@indy.delorie.com> X-SW-Source: 2000-04/msg00390.html Content-length: 456 > From: Jim Blandy > Date: 19 Apr 2000 20:34:21 -0500 > > I think we should be using @deftypefn for everything; that will build > a function index for us automatically. No? If that's what people prefer, I don't mind. Personally, I dislike the @defXXX commands, because they violate the Texinfo language rules (e.g., use unescaped braces). Their handling in makeinfo is a horrible kludge which has subtle problems and idiosyncrasies. >From ac131313@cygnus.com Thu Apr 20 02:56:00 2000 From: Andrew Cagney To: Philippe De Muyter Cc: gdb-patches@sourceware.cygnus.com Subject: Re: PATCH/RFA free(NULL) bomb in printcmd.c Date: Thu, 20 Apr 2000 02:56:00 -0000 Message-id: <38FED326.69E89A2B@cygnus.com> References: <200004110900.LAA01874@mail.macqel.be> X-SW-Source: 2000-04/msg00391.html Content-length: 1288 Philippe De Muyter wrote: > > Andrew Cagney wrote : > > Um, I'm confused. wouldn't it be easier to just delete the two cleanup > > calls (the first, perhaphs, replaced with make_cleanup (null_cleanup, > > NULL))? > > Of course. But I did not know if the number of cleanups mattered, so I made > my change as small as possible. > > [ 10 minutes reflexion and search ] > > The current situation and my and your `fixes' would have caused memory leaks, > because the intention of the programmer there was actually to `free (name)' > and `free (filename)', but `make_cleanup' is called before `name' and `filename' > are allocated. > I now think I have the correct fix. OK to commit ? > > Philippe De Muyter > > * printcmd.c (print_address_symbolic): Call `make_cleanup' with > `(free_current_contents, &x)', not `(free, x)'. > * utils.c (free_current_contents): Do not `free (NULL)'. FYI, Something wierd is going on. For the d10v-elf target, FreeBSD 3.4 host. I see the regression: x/d &oct 0x2007dc0: -1490098887 gdb in free(): warning: junk pointer, too high to make sense. (gdb) FAIL: gdb.base/long_long.exp: x/d &oct The warning appears all over the place. It suggests that something is corrupting one of those pointers. Andrew >From ac131313@cygnus.com Thu Apr 20 03:31:00 2000 From: Andrew Cagney To: Philippe De Muyter , gdb-patches@sourceware.cygnus.com Subject: Re: PATCH/RFA free(NULL) bomb in printcmd.c Date: Thu, 20 Apr 2000 03:31:00 -0000 Message-id: <38FEDC0A.F915966C@cygnus.com> References: <200004110900.LAA01874@mail.macqel.be> <38FED326.69E89A2B@cygnus.com> X-SW-Source: 2000-04/msg00392.html Content-length: 4051 Andrew Cagney wrote: > > Philippe De Muyter > > > > * printcmd.c (print_address_symbolic): Call `make_cleanup' with > > `(free_current_contents, &x)', not `(free, x)'. > > * utils.c (free_current_contents): Do not `free (NULL)'. > > FYI, > > Something wierd is going on. For the d10v-elf target, FreeBSD 3.4 > host. I see the regression: > > x/d &oct > 0x2007dc0: -1490098887 > gdb in free(): warning: junk pointer, too high to make sense. > (gdb) FAIL: gdb.base/long_long.exp: x/d &oct > > The warning appears all over the place. It suggests that something is > corrupting one of those pointers. The attached appears to work much better. The function wasn't cleaning up when build_address_symbolic failed. This led to a later cleanup call freeing a garbage pointer on the stack. Philippe, can you try it on your platform. Andrew Thu Apr 20 17:39:11 2000 Andrew Cagney * defs.h, utils.c (free_current_contents): Change parameter to void*. From Philippe De Muyter : * printcmd.c (print_address_symbolic): Call `make_cleanup' with `(free_current_contents, &x)', not `(free, x)'. * utils.c (free_current_contents): Do not `free (NULL)'. * printcmd.c (print_address_symbolic): Cleanup after a failed call to build_address_symbolic. Index: defs.h =================================================================== RCS file: /cvs/src/src/gdb/defs.h,v retrieving revision 1.13 diff -p -r1.13 defs.h *** defs.h 2000/03/30 18:54:28 1.13 --- defs.h 2000/04/20 10:17:47 *************** extern void restore_cleanups (struct cle *** 354,360 **** extern void restore_final_cleanups (struct cleanup *); extern void restore_my_cleanups (struct cleanup **, struct cleanup *); ! extern void free_current_contents (char **); extern void null_cleanup (void *); --- 354,360 ---- extern void restore_final_cleanups (struct cleanup *); extern void restore_my_cleanups (struct cleanup **, struct cleanup *); ! extern void free_current_contents (void *); extern void null_cleanup (void *); Index: printcmd.c =================================================================== RCS file: /cvs/src/src/gdb/printcmd.c,v retrieving revision 1.3 diff -p -r1.3 printcmd.c *** printcmd.c 2000/04/04 04:16:48 1.3 --- printcmd.c 2000/04/20 10:17:54 *************** print_address_symbolic (addr, stream, do *** 562,573 **** int offset = 0; int line = 0; ! struct cleanup *cleanup_chain = make_cleanup (free, name); ! if (print_symbol_filename) ! make_cleanup (free, filename); if (build_address_symbolic (addr, do_demangle, &name, &offset, &filename, &line, &unmapped)) ! return; fputs_filtered (leadin, stream); if (unmapped) --- 562,576 ---- int offset = 0; int line = 0; ! /* throw away both name and filename */ ! struct cleanup *cleanup_chain = make_cleanup (free_current_contents, &name); ! make_cleanup (free_current_contents, &filename); if (build_address_symbolic (addr, do_demangle, &name, &offset, &filename, &line, &unmapped)) ! { ! do_cleanups (cleanup_chain); ! return; ! } fputs_filtered (leadin, stream); if (unmapped) Index: utils.c =================================================================== RCS file: /cvs/src/src/gdb/utils.c,v retrieving revision 1.6 diff -p -r1.6 utils.c *** utils.c 2000/03/30 18:54:28 1.6 --- utils.c 2000/04/20 10:17:59 *************** restore_my_cleanups (pmy_chain, chain) *** 375,384 **** to arrange to free the object thus allocated. */ void ! free_current_contents (location) ! char **location; { ! free (*location); } /* Provide a known function that does nothing, to use as a base for --- 375,385 ---- to arrange to free the object thus allocated. */ void ! free_current_contents (void *ptr) { ! void **location = ptr; ! if (*location != NULL) ! free (*location); } /* Provide a known function that does nothing, to use as a base for >From ac131313@cygnus.com Thu Apr 20 04:00:00 2000 From: Andrew Cagney To: Tim Mooney Cc: "Daniel Berlin+gnu.gdb.bug" , gdb-patches@sourceware.cygnus.com Subject: Re: [RFA]: Fix crashing bug in set follow-fork-mode Date: Thu, 20 Apr 2000 04:00:00 -0000 Message-id: <38FEE2A9.E83C0059@cygnus.com> References: X-SW-Source: 2000-04/msg00393.html Content-length: 2902 Tim Mooney wrote: > > >Someone please commit this to the branch if it gets approved. > >I have no idea how to make a testcase for it. > >I knew something screwy was up when "set follow-fork-mode parent" said > >"ambiguous command: \"parent\"", and it clearly wasn't ambiguous at > >all. > >So, i looked, and it had trashed our stack, and thought we had 6 > >million matches, rather than one. > > scheduler-lock seems to have the same problem (see the enum at line 765 of > infrun.c). Conditions under which it happens are the exact same as in my > report for the follow-fork-mode problem. I've left the patch to fix the > problem for you or someone else, since it's again very small. Thanks! I've applied the attatched to the 5.0 branch and trunk. Anyone come up with a testsuite addition to add to the trunk? Andrew Thu Apr 20 18:54:15 2000 Andrew Cagney From Daniel Berlin and Tim Mooney : * infrun.c (follow_fork_mode_kind_names): NULL terminate array. Re-indent. (scheduler_enums): Ditto. Index: infrun.c =================================================================== RCS file: /cvs/src/src/gdb/infrun.c,v retrieving revision 1.7 diff -p -r1.7 infrun.c *** infrun.c 2000/04/13 10:22:22 1.7 --- infrun.c 2000/04/20 10:32:34 *************** static int follow_vfork_when_exec; *** 436,448 **** static char *follow_fork_mode_kind_names[] = { ! /* ??rehrauer: The "both" option is broken, by what may be a 10.20 ! kernel problem. It's also not terribly useful without a GUI to ! help the user drive two debuggers. So for now, I'm disabling ! the "both" option. ! "parent", "child", "both", "ask" }; ! */ ! "parent", "child", "ask"}; static char *follow_fork_mode_string = NULL; --- 436,448 ---- static char *follow_fork_mode_kind_names[] = { ! /* ??rehrauer: The "both" option is broken, by what may be a 10.20 ! kernel problem. It's also not terribly useful without a GUI to ! help the user drive two debuggers. So for now, I'm disabling the ! "both" option. */ ! /* "parent", "child", "both", "ask" */ ! "parent", "child", "ask", NULL ! }; static char *follow_fork_mode_string = NULL; *************** static char schedlock_on[] = "on"; *** 762,768 **** static char schedlock_step[] = "step"; static char *scheduler_mode = schedlock_off; static char *scheduler_enums[] = ! {schedlock_off, schedlock_on, schedlock_step}; static void set_schedlock_func (char *args, int from_tty, struct cmd_list_element *c) --- 762,773 ---- static char schedlock_step[] = "step"; static char *scheduler_mode = schedlock_off; static char *scheduler_enums[] = ! { ! schedlock_off, ! schedlock_on, ! schedlock_step, ! NULL ! }; static void set_schedlock_func (char *args, int from_tty, struct cmd_list_element *c) >From dan@cgsoftware.com Thu Apr 20 09:48:00 2000 From: dan@cgsoftware.com (Daniel Berlin+list.gdb-patches) To: Andrew Cagney Cc: Tim Mooney , "Daniel Berlin+gnu.gdb.bug" , gdb-patches@sourceware.cygnus.com Subject: Re: [RFA]: Fix crashing bug in set follow-fork-mode Date: Thu, 20 Apr 2000 09:48:00 -0000 Message-id: References: <38FEE2A9.E83C0059@cygnus.com> X-SW-Source: 2000-04/msg00394.html Content-length: 696 Andrew Cagney writes: I have a better idea. I just made it check the enum list, when the command is added, like so: while(1) { if enumlist[i]==0 break (this means it's properly null terminated) if (!isalnum(enumlist[i][0])) internal_error("'s enum list is not null terminated, or contains non-alphanumeric characters."); i++; } This is better than the testsuite addition, because if you screw up, gdb won't start, or it'll crash (it depends on where enumlist[i][0] is located.) Watch: bash-2.03# ./gdb -nw gdb-internal-error: follow-fork-mode has non-null terminated enum list, or non alpha-numeric character in enum list bash-2.03# Patch attached >From law@cygnus.com Thu Apr 20 10:20:00 2000 From: Jeffrey A Law To: Alexandre Oliva Cc: binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: AM33 disassembler: fix for long-standing bug Date: Thu, 20 Apr 2000 10:20:00 -0000 Message-id: <5434.956247166@upchuck> References: X-SW-Source: 2000-04/msg00395.html Content-length: 650 In message < orzoqqv7ux.fsf@zecarneiro.lsd.ic.unicamp.br >you write: > --=-=-= > > As written in the previous message, AM30 insns are *not* supposed to > be accepted on AM33. However, I'd still like to install a patch like > this, to keep the platform-detection code identical to that in gas. > Ok to install? > > > --=-=-= > Content-Type: text/x-patch > Content-Disposition: inline; filename=am33-opcodes-fix.patch > > Index: opcodes/ChangeLog > by Alexandre Oliva > > * m10300-dis.c (HAVE_AM30, HAVE_AM33): Define. > (disassemble): Use them. This is fine. Please install it. jeff