From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Sivachenko To: davidw@gordian.com Cc: eliz@is.elta.co.il, gdb-patches@sourceware.cygnus.com Subject: Re: Include GDB/MI docs in GDB manual Date: Mon, 17 Apr 2000 08:56:00 -0000 Message-id: <200004171555.TAA63783@netserv1.chg.ru> References: X-SW-Source: 2000-04/msg00331.html Just one more thought: we can make third book (GDB manual, GDB internals) plus smth like 'GDB technicals' and include both annotate.texi and gdbmi.texi there. Even if it will not be accepted, I think it is bad idea to make a 'garbage heap' from the GDB manual, mainly intended for regular GDB users, not 'GDB hackers'. >From shebs@apple.com Mon Apr 17 11:16:00 2000 From: Stan Shebs To: Dmitry Sivachenko Cc: eliz@is.elta.co.il, gdb-patches@sourceware.cygnus.com Subject: Re: Index in gdb.texinfo Date: Mon, 17 Apr 2000 11:16:00 -0000 Message-id: <38FB54DC.9A7D3E8C@apple.com> References: <200004162015.AAA39758@netserv1.chg.ru> X-SW-Source: 2000-04/msg00332.html Content-length: 819 Dmitry Sivachenko wrote: > > > > -@kindex RET > > > +@kindex @key{RET} > > > > I don't think it's a good idea to have @key in the index, it looks > > awkward there. Isn't @code{RET} good enough for the index? > > We have 'complete (@key{TAB})' in Readline chapter. > I thought we should markup RET in a similar manner. Then how about including the command name, or a virtual command name like "repeat (@key{RET})"? > By the way, what people think about splitting Index into two parts: > Concept index and Functions and Commands index (or smth similar)? Hmmm. The combined index isn't really that large, less than 10 pages, and it doesn't seem too hard to find the command names in it. I think we'd want to think about it at the 20-30 page level, or if concept entries massively outnumber command entries. Stan >From dima@Chg.RU Mon Apr 17 11:23:00 2000 From: Dmitry Sivachenko To: shebs@apple.com Cc: eliz@is.elta.co.il, gdb-patches@sourceware.cygnus.com Subject: Re: Index in gdb.texinfo Date: Mon, 17 Apr 2000 11:23:00 -0000 Message-id: <200004171823.WAA66644@netserv1.chg.ru> References: <200004162015.AAA39758@netserv1.chg.ru> <38FB54DC.9A7D3E8C@apple.com> X-SW-Source: 2000-04/msg00333.html Content-length: 797 > We have 'complete (@key{TAB})' in Readline chapter. > I thought we should markup RET in a similar manner. Then how about including the command name, or a virtual command name like "repeat (@key{RET})"? Sounds good for me. > By the way, what people think about splitting Index into two parts: > Concept index and Functions and Commands index (or smth similar)? Hmmm. The combined index isn't really that large, less than 10 pages, and it doesn't seem too hard to find the command names in it. I think we'd want to think about it at the 20-30 page level, or if concept entries massively outnumber command entries. In the translated version of manual it is better to have translated part of Index separated from untranslated (command, functions, etc.) --dima >From shebs@apple.com Mon Apr 17 11:31:00 2000 From: Stan Shebs To: Eli Zaretskii Cc: ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: [RFA] Include GDB/MI docs in GDB manual (was: Re: GDB 5 2000-03-29) Date: Mon, 17 Apr 2000 11:31:00 -0000 Message-id: <38FB5864.1ADA6A08@apple.com> References: <38E17D2C.F7EB65B9@cygnus.com> <200003312306.SAA07143@indy.delorie.com> <38E6945F.66938F0@cygnus.com> <200004160759.DAA10364@indy.delorie.com> <200004170823.EAA11690@indy.delorie.com> X-SW-Source: 2000-04/msg00334.html Content-length: 4978 Eli Zaretskii wrote: > > What, no responses at all? I'd expect a thousand flowers by now ;-) OK... (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) (*) |/ |/ |/ |/ |/ |/ |/ |/ |/ |/ |/ |/ |/ |/ |/ |/ |/ |/ |/ |/ \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| > The message at the URL below includes the patches to make GDB/MI docs > part of the GDB manual. Please tell me if it's okay to commit. > > http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00309.html Looks fine to me. Since the MI is part of 5.0, we ought to have this bit of the manual in it too, so people know about it. Stan >From shebs@apple.com Mon Apr 17 11:50:00 2000 From: Stan Shebs To: Dmitry Sivachenko Cc: eliz@delorie.com, gdb-patches@sourceware.cygnus.com Subject: Re: Include GDB/MI docs in GDB manual Date: Mon, 17 Apr 2000 11:50:00 -0000 Message-id: <38FB5CE4.6B79E410@apple.com> References: <200004170956.NAA55866@netserv1.chg.ru> X-SW-Source: 2000-04/msg00335.html Content-length: 1710 Dmitry Sivachenko wrote: > > I think it is not good thing to include gdbmi.texinfo into > GDB manual. It contains very technical issues, which regular users > would not be happy to see in the Manual. > GDB manual should contain things which describe using of the debugger > from the users's point of view. You're right that the MI interface is not obviously part of the regular manual. But after thinking about it for awhile, considering the alternatives, and looking at other manuals, it seemed that the user manual was the best home. The MI is one of the interfaces presented by GDB. In that respect it is similar to annotations, which we also added docs for recently, and the remote protocol, which has been documented in the manual for a long time - along with C programming hints for the stub. The MI is at least as appropriate as these other examples. The MI audience is narrow, namely people building GUIs that use GDB. But we also document commands like "target dink32", for which I can assure you the audience is even narrower! Multiple manuals are more work to maintain, and historically they seem to result in more style and sync problems. The GCC manual actually includes full porting instructions, which goes well outside being just a user's manual. However, I've long wondered if that actually encourages people to start on GCC ports; certainly when I started working with GCC in 1989, having that info in the main manual smoothed the way. One of the underlying goals for the GNU project is to encourage the creation of more free software, and so it's a good idea to have programmer-oriented manuals that encourage and inform programmers about all the avenues for adding to GNU. Stan >From jlarmour@redhat.co.uk Mon Apr 17 13:07:00 2000 From: Jonathan Larmour To: James Ingham Cc: insight@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Insight remote output doesn't output to console window immediately Date: Mon, 17 Apr 2000 13:07:00 -0000 Message-id: <38FB6EEC.D2521EBC@redhat.co.uk> References: <38F6404E.5959A4E0@redhat.co.uk> <38F65D4D.8B390EFA@cygnus.com> <38F67617.D1A2A6B3@redhat.co.uk> <14582.31502.754152.913822@leda.cygnus.com> <38F6873A.8284A61B@redhat.co.uk> <14583.16305.343648.795283@leda.cygnus.com> X-SW-Source: 2000-04/msg00336.html Content-length: 7576 James Ingham wrote: > > Jonathan, > > > James Ingham wrote: > > > > > > Okay, check this in. > > > > Trunk, branch or both? > > Both. Maybe add a FIXME to the comment, since I often grep for FIXME > when I am trying to figure out what I should do next (though as I > said, this one is already on the short list.) I've added a FIXME comment now. > > > > > As for the Changelog-gdbtk's. They should be changed to just > > > ChangeLog - the gdbtk is historic; the C-code files used to live at > > > the top level, but since Insight couldn't be included in the FSF gdb > > > releases, we had to have separate ChangeLogs... > > > > Would you like me to rename those two then? Obviously not forgetting to > > remove all the change-log-default-name emacs variables. That would be trunk > > only of course. > > That would be lovely, thanks. I'll check in the attached patch to the trunk only once you say so. I added ChangeLog entries: 2000-04-17 Jonathan Larmour * ChangeLog-gdbtk: Renamed to ChangeLog * ChangeLog: New file * README.GDBTK: No need for changelog-default-name hint for Emacs now generic/ChangeLog 2000-04-17 Jonathan Larmour * ChangeLog-gdbtk: Renamed to ChangeLog * ChangeLog: New file * gdbtk-cmds.c, gdbtk-hooks.c, gdbtk-variable.c, gdbtk-varobj.c, gdbtk-wrapper.h, gdbtk-wrapper.c, gdbtk.h, gdbtk.c: No need for changelog-default-name hint for Emacs now I was tempted to just go ahead check this in, but I'm erring on the side of caution. Jifl -- Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762 "Plan to be spontaneous tomorrow." || These opinions are all my own fault cvs server: ChangeLog is a new entry, no comparison available cvs server: ChangeLog-gdbtk was removed, no comparison available Index: README.GDBTK =================================================================== RCS file: /cvs/src/src/gdb/gdbtk/README.GDBTK,v retrieving revision 1.1.1.1 diff -u -5 -p -r1.1.1.1 README.GDBTK --- README.GDBTK 2000/02/07 00:19:42 1.1.1.1 +++ README.GDBTK 2000/04/17 20:05:43 @@ -396,8 +396,5 @@ m68k-hp-hpux9.00: . . . -/* Local variables: */ -/* change-log-default-name: "ChangeLog-gdbtk" */ -/* End: */ cvs server: generic/ChangeLog is a new entry, no comparison available cvs server: generic/ChangeLog-gdbtk was removed, no comparison available Index: generic/gdbtk-cmds.c =================================================================== RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-cmds.c,v retrieving revision 1.6 diff -u -5 -p -r1.6 gdbtk-cmds.c --- generic/gdbtk-cmds.c 2000/04/03 21:29:00 1.6 +++ generic/gdbtk-cmds.c 2000/04/17 20:05:45 @@ -4698,10 +4698,6 @@ setup_architecture_data () { /* don't trust REGISTER_BYTES to be zero. */ old_regs = xmalloc (REGISTER_BYTES + 1); memset (old_regs, 0, REGISTER_BYTES + 1); } - -/* Local variables: */ -/* change-log-default-name: "ChangeLog-gdbtk" */ -/* End: */ Index: generic/gdbtk-hooks.c =================================================================== RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-hooks.c,v retrieving revision 1.3 diff -u -5 -p -r1.3 gdbtk-hooks.c --- generic/gdbtk-hooks.c 2000/04/03 21:29:00 1.3 +++ generic/gdbtk-hooks.c 2000/04/17 20:05:45 @@ -905,8 +905,6 @@ gdbtk_detach () if (Tcl_Eval (gdbtk_interp, "gdbtk_detached") != TCL_OK) { report_error (); } } -/* Local variables: */ -/* change-log-default-name: "ChangeLog-gdbtk" */ -/* End: */ + Index: generic/gdbtk-variable.c =================================================================== RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-variable.c,v retrieving revision 1.1.1.1 diff -u -5 -p -r1.1.1.1 gdbtk-variable.c --- generic/gdbtk-variable.c 2000/02/07 00:19:42 1.1.1.1 +++ generic/gdbtk-variable.c 2000/04/17 20:05:46 @@ -2409,9 +2409,6 @@ java_value_of_variable (var, obj) gdb_variable *var; Tcl_Obj **obj; { return cplus_value_of_variable (var, obj); } - -/* Local variables: */ -/* change-log-default-name: "ChangeLog-gdbtk" */ -/* End: */ + Index: generic/gdbtk-varobj.c =================================================================== RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-varobj.c,v retrieving revision 1.2 diff -u -5 -p -r1.2 gdbtk-varobj.c --- generic/gdbtk-varobj.c 2000/03/13 21:51:45 1.2 +++ generic/gdbtk-varobj.c 2000/04/17 20:05:46 @@ -627,9 +627,6 @@ uninstall_variable (interp, varname) Tcl_Interp *interp; char *varname; { Tcl_DeleteCommand (interp, varname); } - -/* Local variables: */ -/* change-log-default-name: "ChangeLog-gdbtk" */ -/* End: */ + Index: generic/gdbtk-wrapper.c =================================================================== RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-wrapper.c,v retrieving revision 1.2 diff -u -5 -p -r1.2 gdbtk-wrapper.c --- generic/gdbtk-wrapper.c 2000/02/24 03:11:47 1.2 +++ generic/gdbtk-wrapper.c 2000/04/17 20:05:46 @@ -826,11 +826,6 @@ wrap_get_current_frame (char *opaque_arg struct gdb_wrapper_arguments **args = (struct gdb_wrapper_arguments **) opaque_arg; (*args)->result = (char *) get_current_frame (); return 1; } - - -/* Local variables: */ -/* change-log-default-name: "ChangeLog-gdbtk" */ -/* End: */ Index: generic/gdbtk-wrapper.h =================================================================== RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-wrapper.h,v retrieving revision 1.2 diff -u -5 -p -r1.2 gdbtk-wrapper.h --- generic/gdbtk-wrapper.h 2000/02/24 03:11:47 1.2 +++ generic/gdbtk-wrapper.h 2000/04/17 20:05:46 @@ -73,9 +73,6 @@ extern gdb_result GDB_get_next_frame PAR extern gdb_result GDB_find_relative_frame PARAMS ((struct frame_info *fi, int *start, struct frame_info **result)); extern gdb_result GDB_get_current_frame PARAMS ((struct frame_info **result)); #endif /* GDBTK_WRAPPER_H */ - -/* Local variables: */ -/* change-log-default-name: "ChangeLog-gdbtk" */ -/* End: */ + Index: generic/gdbtk.c =================================================================== RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk.c,v retrieving revision 1.2 diff -u -5 -p -r1.2 gdbtk.c --- generic/gdbtk.c 2000/04/14 08:04:46 1.2 +++ generic/gdbtk.c 2000/04/17 20:05:46 @@ -528,11 +528,12 @@ gdbtk_find_main"; /* fputs_unfiltered_hook = NULL; *//* Force errors to stdout/stderr */ fputs_unfiltered_hook = gdbtk_fputs; - /* set gdb_stdtarg for now until gdbtk is changed to use struct ui_out. */ + /* FIXME: set gdb_stdtarg for now until gdbtk is changed to use + struct ui_out. */ gdb_stdtarg = gdb_stdout; if (Tcl_GlobalEval (gdbtk_interp, (char *) script) != TCL_OK) { @@ -653,9 +654,6 @@ tk_command (cmd, from_tty) printf_unfiltered ("%s\n", result); do_cleanups (old_chain); } - -/* Local variables: */ -/* change-log-default-name: "ChangeLog-gdbtk" */ -/* End: */ + Index: generic/gdbtk.h =================================================================== RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk.h,v retrieving revision 1.2 diff -u -5 -p -r1.2 gdbtk.h --- generic/gdbtk.h 2000/04/03 21:29:00 1.2 +++ generic/gdbtk.h 2000/04/17 20:05:46 @@ -178,9 +178,5 @@ extern void /* gdbtk_add_hooks - add all the hooks to gdb. This will get called by the startup code to fill in the hooks needed by core gdb. */ extern void gdbtk_add_hooks (void); - -/* Local variables: */ -/* change-log-default-name: "ChangeLog-gdbtk" */ -/* End: */ >From jingham@cygnus.com Mon Apr 17 13:16:00 2000 From: James Ingham To: Jonathan Larmour Cc: James Ingham , insight@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Insight remote output doesn't output to console window immediately Date: Mon, 17 Apr 2000 13:16:00 -0000 Message-id: <14587.29099.5122.345649@leda.cygnus.com> References: <38F6404E.5959A4E0@redhat.co.uk> <38F65D4D.8B390EFA@cygnus.com> <38F67617.D1A2A6B3@redhat.co.uk> <14582.31502.754152.913822@leda.cygnus.com> <38F6873A.8284A61B@redhat.co.uk> <14583.16305.343648.795283@leda.cygnus.com> <38FB6EEC.D2521EBC@redhat.co.uk> X-SW-Source: 2000-04/msg00337.html Content-length: 8319 Jonathan, This looks fine to me. Check it in. Jim > James Ingham wrote: > > > > Jonathan, > > > > > James Ingham wrote: > > > > > > > > Okay, check this in. > > > > > > Trunk, branch or both? > > > > Both. Maybe add a FIXME to the comment, since I often grep for FIXME > > when I am trying to figure out what I should do next (though as I > > said, this one is already on the short list.) > > I've added a FIXME comment now. > > > > > > > > As for the Changelog-gdbtk's. They should be changed to just > > > > ChangeLog - the gdbtk is historic; the C-code files used to live at > > > > the top level, but since Insight couldn't be included in the FSF gdb > > > > releases, we had to have separate ChangeLogs... > > > > > > Would you like me to rename those two then? Obviously not forgetting to > > > remove all the change-log-default-name emacs variables. That would be trunk > > > only of course. > > > > That would be lovely, thanks. > > I'll check in the attached patch to the trunk only once you say so. I added > ChangeLog entries: > > 2000-04-17 Jonathan Larmour > > * ChangeLog-gdbtk: Renamed to ChangeLog > * ChangeLog: New file > * README.GDBTK: No need for changelog-default-name hint for Emacs > now > > generic/ChangeLog > 2000-04-17 Jonathan Larmour > > * ChangeLog-gdbtk: Renamed to ChangeLog > * ChangeLog: New file > * gdbtk-cmds.c, gdbtk-hooks.c, gdbtk-variable.c, gdbtk-varobj.c, > gdbtk-wrapper.h, gdbtk-wrapper.c, gdbtk.h, gdbtk.c: No need for > changelog-default-name hint for Emacs now > > I was tempted to just go ahead check this in, but I'm erring on the side of > caution. > > Jifl > -- > Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762 > "Plan to be spontaneous tomorrow." || These opinions are all my own faultcvs server: ChangeLog is a new entry, no comparison available > cvs server: ChangeLog-gdbtk was removed, no comparison available > Index: README.GDBTK > =================================================================== > RCS file: /cvs/src/src/gdb/gdbtk/README.GDBTK,v > retrieving revision 1.1.1.1 > diff -u -5 -p -r1.1.1.1 README.GDBTK > --- README.GDBTK 2000/02/07 00:19:42 1.1.1.1 > +++ README.GDBTK 2000/04/17 20:05:43 > @@ -396,8 +396,5 @@ m68k-hp-hpux9.00: > . > . > . > > > -/* Local variables: */ > -/* change-log-default-name: "ChangeLog-gdbtk" */ > -/* End: */ > cvs server: generic/ChangeLog is a new entry, no comparison available > cvs server: generic/ChangeLog-gdbtk was removed, no comparison available > Index: generic/gdbtk-cmds.c > =================================================================== > RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-cmds.c,v > retrieving revision 1.6 > diff -u -5 -p -r1.6 gdbtk-cmds.c > --- generic/gdbtk-cmds.c 2000/04/03 21:29:00 1.6 > +++ generic/gdbtk-cmds.c 2000/04/17 20:05:45 > @@ -4698,10 +4698,6 @@ setup_architecture_data () > { > /* don't trust REGISTER_BYTES to be zero. */ > old_regs = xmalloc (REGISTER_BYTES + 1); > memset (old_regs, 0, REGISTER_BYTES + 1); > } > - > > -/* Local variables: */ > -/* change-log-default-name: "ChangeLog-gdbtk" */ > -/* End: */ > Index: generic/gdbtk-hooks.c > =================================================================== > RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-hooks.c,v > retrieving revision 1.3 > diff -u -5 -p -r1.3 gdbtk-hooks.c > --- generic/gdbtk-hooks.c 2000/04/03 21:29:00 1.3 > +++ generic/gdbtk-hooks.c 2000/04/17 20:05:45 > @@ -905,8 +905,6 @@ gdbtk_detach () > if (Tcl_Eval (gdbtk_interp, "gdbtk_detached") != TCL_OK) > { > report_error (); > } > } > -/* Local variables: */ > -/* change-log-default-name: "ChangeLog-gdbtk" */ > -/* End: */ > + > Index: generic/gdbtk-variable.c > =================================================================== > RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-variable.c,v > retrieving revision 1.1.1.1 > diff -u -5 -p -r1.1.1.1 gdbtk-variable.c > --- generic/gdbtk-variable.c 2000/02/07 00:19:42 1.1.1.1 > +++ generic/gdbtk-variable.c 2000/04/17 20:05:46 > @@ -2409,9 +2409,6 @@ java_value_of_variable (var, obj) > gdb_variable *var; > Tcl_Obj **obj; > { > return cplus_value_of_variable (var, obj); > } > - > -/* Local variables: */ > -/* change-log-default-name: "ChangeLog-gdbtk" */ > -/* End: */ > + > Index: generic/gdbtk-varobj.c > =================================================================== > RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-varobj.c,v > retrieving revision 1.2 > diff -u -5 -p -r1.2 gdbtk-varobj.c > --- generic/gdbtk-varobj.c 2000/03/13 21:51:45 1.2 > +++ generic/gdbtk-varobj.c 2000/04/17 20:05:46 > @@ -627,9 +627,6 @@ uninstall_variable (interp, varname) > Tcl_Interp *interp; > char *varname; > { > Tcl_DeleteCommand (interp, varname); > } > - > -/* Local variables: */ > -/* change-log-default-name: "ChangeLog-gdbtk" */ > -/* End: */ > + > Index: generic/gdbtk-wrapper.c > =================================================================== > RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-wrapper.c,v > retrieving revision 1.2 > diff -u -5 -p -r1.2 gdbtk-wrapper.c > --- generic/gdbtk-wrapper.c 2000/02/24 03:11:47 1.2 > +++ generic/gdbtk-wrapper.c 2000/04/17 20:05:46 > @@ -826,11 +826,6 @@ wrap_get_current_frame (char *opaque_arg > struct gdb_wrapper_arguments **args = (struct gdb_wrapper_arguments **) opaque_arg; > > (*args)->result = (char *) get_current_frame (); > return 1; > } > - > > - > -/* Local variables: */ > -/* change-log-default-name: "ChangeLog-gdbtk" */ > -/* End: */ > Index: generic/gdbtk-wrapper.h > =================================================================== > RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-wrapper.h,v > retrieving revision 1.2 > diff -u -5 -p -r1.2 gdbtk-wrapper.h > --- generic/gdbtk-wrapper.h 2000/02/24 03:11:47 1.2 > +++ generic/gdbtk-wrapper.h 2000/04/17 20:05:46 > @@ -73,9 +73,6 @@ extern gdb_result GDB_get_next_frame PAR > extern gdb_result GDB_find_relative_frame PARAMS ((struct frame_info *fi, > int *start, > struct frame_info **result)); > extern gdb_result GDB_get_current_frame PARAMS ((struct frame_info **result)); > #endif /* GDBTK_WRAPPER_H */ > - > -/* Local variables: */ > -/* change-log-default-name: "ChangeLog-gdbtk" */ > -/* End: */ > + > Index: generic/gdbtk.c > =================================================================== > RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk.c,v > retrieving revision 1.2 > diff -u -5 -p -r1.2 gdbtk.c > --- generic/gdbtk.c 2000/04/14 08:04:46 1.2 > +++ generic/gdbtk.c 2000/04/17 20:05:46 > @@ -528,11 +528,12 @@ gdbtk_find_main"; > > /* fputs_unfiltered_hook = NULL; *//* Force errors to stdout/stderr */ > > fputs_unfiltered_hook = gdbtk_fputs; > > - /* set gdb_stdtarg for now until gdbtk is changed to use struct ui_out. */ > + /* FIXME: set gdb_stdtarg for now until gdbtk is changed to use > + struct ui_out. */ > > gdb_stdtarg = gdb_stdout; > > if (Tcl_GlobalEval (gdbtk_interp, (char *) script) != TCL_OK) > { > @@ -653,9 +654,6 @@ tk_command (cmd, from_tty) > > printf_unfiltered ("%s\n", result); > > do_cleanups (old_chain); > } > - > -/* Local variables: */ > -/* change-log-default-name: "ChangeLog-gdbtk" */ > -/* End: */ > + > Index: generic/gdbtk.h > =================================================================== > RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk.h,v > retrieving revision 1.2 > diff -u -5 -p -r1.2 gdbtk.h > --- generic/gdbtk.h 2000/04/03 21:29:00 1.2 > +++ generic/gdbtk.h 2000/04/17 20:05:46 > @@ -178,9 +178,5 @@ extern void > > /* gdbtk_add_hooks - add all the hooks to gdb. This will get called > by the startup code to fill in the hooks needed by core gdb. */ > extern void gdbtk_add_hooks (void); > > - > -/* Local variables: */ > -/* change-log-default-name: "ChangeLog-gdbtk" */ > -/* End: */ >From ac131313@cygnus.com Tue Apr 18 00:50:00 2000 From: Andrew Cagney To: GDB Patches Subject: sim/d10v, fix SIGILL behavour Date: Tue, 18 Apr 2000 00:50:00 -0000 Message-id: <38FC138D.850FE2E1@cygnus.com> X-SW-Source: 2000-04/msg00338.html Content-length: 2497 FYI, I've committed the attatched. For the curious, it allows the user to step through a reserved instruction exception when using the simulator. Andrew Tue Apr 18 16:26:41 2000 Andrew Cagney * interp.c (sim_resume): Deliver SIGILL. (lookup_hash): Do not print SIGILL message. Tue Apr 18 16:32:07 2000 Andrew Cagney * t-rie-xx.s (test_rie_xx): New test. * Makefile.in (TESTS): Update. Index: d10v/interp.c =================================================================== RCS file: /cvs/cvsfiles/devo/sim/d10v/interp.c,v retrieving revision 1.51.4.13 diff -p -r1.51.4.13 interp.c *** interp.c 2000/02/23 07:27:42 1.51.4.13 --- interp.c 2000/04/18 07:21:24 *************** lookup_hash (ins, size) *** 99,106 **** { if (h->next == NULL) { - (*d10v_callback->printf_filtered) - (d10v_callback, "ERROR: Illegal instruction %x at PC %x\n", ins, PC); State.exception = SIGILL; State.pc_changed = 1; /* Don't increment the PC. */ return NULL; --- 99,104 ---- *************** sim_resume (sd, step, siggnal) *** 977,982 **** --- 975,987 ---- SET_BPSW (PSW); SET_HW_PSW ((PSW & (PSW_F0_BIT | PSW_F1_BIT | PSW_C_BIT))); JMP (AE_VECTOR_START); + SLOT_FLUSH (); + break; + case SIGILL: + SET_BPC (PC); + SET_BPSW (PSW); + SET_HW_PSW ((PSW & (PSW_F0_BIT | PSW_F1_BIT | PSW_C_BIT))); + JMP (RIE_VECTOR_START); SLOT_FLUSH (); break; default: Index: testsuite/d10v-elf/Makefile.in =================================================================== RCS file: /cvs/cvsfiles/devo/sim/testsuite/d10v-elf/Makefile.in,v retrieving revision 1.16.2.2 diff -p -r1.16.2.2 Makefile.in *** Makefile.in 2000/02/23 07:30:13 1.16.2.2 --- Makefile.in 2000/04/18 07:21:27 *************** TESTS = \ *** 82,87 **** --- 82,88 ---- t-ae-st2w-im.ok \ t-ae-st2w-ip.ok \ t-ae-st2w-is.ok \ + t-rie-xx.ok \ # AS_FOR_TARGET = `\ Index: testsuite/d10v-elf/t-rie-xx.s =================================================================== RCS file: t-rie-xx.s diff -N t-rie-xx.s *** /dev/null Tue May 5 13:32:27 1998 --- t-rie-xx.s Tue Apr 18 00:21:27 2000 *************** *** 0 **** --- 1,12 ---- + .include "t-macros.i" + + start + + PSW_BITS = 0 + point_dmap_at_imem + check_interrupt (VEC_RIE&DMAP_MASK)+DMAP_BASE PSW_BITS test_rie_xx + + test_rie_xx: + .short 0xe120, 0x0000 ;; Example of RIE code + nop + exit47 >From ac131313@cygnus.com Tue Apr 18 01:02:00 2000 From: Andrew Cagney To: GDB Patches Subject: [PATCH/5] Don't delete gdb/testsuite/gdb.mi/testcmds Date: Tue, 18 Apr 2000 01:02:00 -0000 Message-id: <38FC165E.DE02E720@cygnus.com> X-SW-Source: 2000-04/msg00339.html Content-length: 1110 FYI, I've committed the attatched. I suspect the test that went with testcmds never made it onto sourceware? Perhaphs something to add to the trunk. Andrew Tue Apr 18 15:36:07 2000 Andrew Cagney * Makefile.in (clean mostlyclean): Do not delete $(MISCELLANEOUS). Index: testsuite/gdb.mi/Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/Makefile.in,v retrieving revision 1.2 diff -p -r1.2 Makefile.in *** Makefile.in 2000/03/14 05:02:03 1.2 --- Makefile.in 2000/04/18 07:03:09 *************** all: *** 11,17 **** #### host, target, and site specific Makefile frags come in here. clean mostlyclean: ! -rm -f *.ci *.o $(OBJS) $(PROGS) $(MISCELLANEOUS) *~ core distclean maintainer-clean realclean: clean -rm -f Makefile config.status config.log --- 11,17 ---- #### host, target, and site specific Makefile frags come in here. clean mostlyclean: ! -rm -f *.ci *.o $(OBJS) $(PROGS) *~ core distclean maintainer-clean realclean: clean -rm -f Makefile config.status config.log >From ac131313@cygnus.com Tue Apr 18 01:06:00 2000 From: Andrew Cagney To: GDB Patches Subject: [PATCH/5] Add cleanups to gdb/tui/Makefile.in Date: Tue, 18 Apr 2000 01:06:00 -0000 Message-id: <38FC1754.6A7A1BF5@cygnus.com> X-SW-Source: 2000-04/msg00340.html Content-length: 879 FYI, I've committed the attatched to both the trunk and the branch. Thanks to Eli for finding this. Andrew Tue Apr 18 15:32:15 2000 Andrew Cagney * Makefile.in (distclean, maintainer-clean, realclean, mostlyclean): New targets. Index: tui/Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/tui/Makefile.in,v retrieving revision 1.1.1.1 diff -p -r1.1.1.1 Makefile.in *** Makefile.in 1999/04/16 01:34:12 1.1.1.1 --- Makefile.in 2000/04/18 07:02:57 *************** tuiInit.c: $(SOURCES) *** 164,168 **** @echo '}' >>init.c-tmp @mv init.c-tmp tuiInit.c ! clean: ! rm -f *.o *.a --- 164,171 ---- @echo '}' >>init.c-tmp @mv init.c-tmp tuiInit.c ! clean mostlyclean: ! -rm -f *.o *.a ! ! distclean maintainer-clean realclean: clean ! -rm -f Makefile config.log config.cache >From ac131313@cygnus.com Tue Apr 18 01:13:00 2000 From: Andrew Cagney To: Eli Zaretskii Cc: gdb-patches@sourceware.cygnus.com, Ian Lance Taylor Subject: Re: Problems with snapshot 20000412 Date: Tue, 18 Apr 2000 01:13:00 -0000 Message-id: <38FC18BA.61DB4A58@cygnus.com> References: <200004160807.EAA10378@indy.delorie.com> X-SW-Source: 2000-04/msg00341.html Content-length: 1064 Eli Zaretskii wrote: > > I have few problems with the 20000412 snapshot: > > 1) It includes several changes in bfd/doc/Makefile.in which look like > this: > > .texi.dvi: > - TEXINPUTS=$(top_srcdir)/../texinfo:$$TEXINPUTS \ > + TEXINPUTS=$(top_srcdir)/../texinfo/texinfo.tex:$$TEXINPUTS \ > MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) $< > > This change is *wrong*. The TEXINPUTS variable should point to a list > of directories, not a list of files. > > Is it a bug in Automake? I've not yet looked at this. (Ian, FYI, this also appears in the trunk) > 2) The diffs include files that AFAIK shouldn't be there: > dejagnu/example/calc/config.log, dejagnu/example/calc/config.status, > gdb/tui/Makefile, intl/config.status. I think these files are also > in md5.sum, which also seems wrong. FYI, I've so far fixed gdb/tui/Makefile (and another gdb/* bug). I'm still testing my dejagnu fix and have not yet checked the intl/* problem but suspect it is straightforward. Hopefully tomorrow. Andrew >From eliz@delorie.com Tue Apr 18 02:02:00 2000 From: Eli Zaretskii To: dima@Chg.RU Cc: davidw@gordian.com, gdb-patches@sourceware.cygnus.com Subject: Re: Include GDB/MI docs in GDB manual Date: Tue, 18 Apr 2000 02:02:00 -0000 Message-id: <200004180901.FAA13035@indy.delorie.com> References: <200004171555.TAA63783@netserv1.chg.ru> X-SW-Source: 2000-04/msg00342.html Content-length: 1274 Date: Mon, 17 Apr 2000 19:55:58 +0400 (MSD) From: Dmitry Sivachenko > I think it is bad idea to make a 'garbage heap' from the GDB manual, > mainly intended for regular GDB users, not 'GDB hackers'. I tend to the opposite ;-) I think that, ideally, the documentation should include everything in a single place. If properly indexed, such a document, however large, is a handy tool for finding any issue your are after, in a fast and efficient way. In contrast, cross-references between different manuals are usually rare, and the facilities for searching multiple documents are abysmally more primitive (and mostly unknown and unused) than what you have for searching a single Info document. Here's a simple demonstration: the GDB manual does not have a single reference to the GDB Internals manual. How do we expect a user who reads gdb.info to know that more docs about GDB is available elsewhere? Btw, the fact that "make install" in the GDB distro doesn't install the Info docs, unlike any other GNU project I've seen, actually makes it more probable that gdbint.info will not be installed anywhere along INFOPATH. So even advanced features like "info --apropos" (how many people around here even know about the --apropos switch?) might not help. >From eliz@delorie.com Tue Apr 18 02:04:00 2000 From: Eli Zaretskii To: dima@Chg.RU Cc: shebs@apple.com, gdb-patches@sourceware.cygnus.com Subject: Re: Index in gdb.texinfo Date: Tue, 18 Apr 2000 02:04:00 -0000 Message-id: <200004180903.FAA13044@indy.delorie.com> References: <200004162015.AAA39758@netserv1.chg.ru> <38FB54DC.9A7D3E8C@apple.com> <200004171823.WAA66644@netserv1.chg.ru> X-SW-Source: 2000-04/msg00343.html Content-length: 1564 Date: Mon, 17 Apr 2000 22:23:12 +0400 (MSD) From: Dmitry Sivachenko > > We have 'complete (@key{TAB})' in Readline chapter. > > I thought we should markup RET in a similar manner. > > Then how about including the command name, or a virtual command > name like "repeat (@key{RET})"? > > Sounds good for me. Based on discussions with Stan by private mail, I intend to change all of the commands in the way Stan suggested above. So RET will get the same treatment. I just need the thumbs-up from Stan to make this and other changes we talked about, to get this done. Most of the changes are already ready on my disk. > In the translated version of manual it is better to have translated > part of Index separated from untranslated (command, functions, etc.) This is an issue that no GNU manual currently handles correctly. The main problem is the sorting order, AFAIK, but a plethora of other issues pop up as well. You can easily separate the indices if you comment away the @syncodeindex directives at the beginning of gdb.texinfo. Sorting the entries will also effectively separate translated and untranslated entries. But by and large, this issue was not attacked by Texinfo yet. You could say that non-ASCII support in Texinfo is nothing more than a kludgey hack, unfortunately. I don't think we should expect GDB to solve this ;-) However, I do suggest to take these issues up with bug-texinfo mailing list. I think those who work on Texinfo should at least be aware of the problem, if not start working on solutions. >From law@cygnus.com Tue Apr 18 11:00:00 2000 From: Jeffrey A Law To: Jim Blandy Cc: gdb-patches@sourceware.cygnus.com Subject: Re: RFA: distinguish between pointers and addresses Date: Tue, 18 Apr 2000 11:00:00 -0000 Message-id: <2629.956053147@upchuck> References: X-SW-Source: 2000-04/msg00344.html Content-length: 406 In message < np66tklb97.fsf@zwingli.cygnus.com >you write: > > I've committed this patch, with everyone's approval but Jeff Law. The > hppa-tdep.c changes are cosmetic, so I think it'll be okay. FYI -- I'm on the road right now. I trust your judgement on this stuff to DTRT. Thanks for taking care of it. Sorry everyone, I should have put a .vacation auto-responder on my mail address. jeff >From jimb@zwingli.cygnus.com Tue Apr 18 11:46:00 2000 From: Jim Blandy To: "Philippe De Muyter" Cc: gdb-patches@sourceware.cygnus.com (gdb-patches@sourceware.cygnus.com) Subject: Re: RFA free(NULL) in bcache.c Date: Tue, 18 Apr 2000 11:46:00 -0000 Message-id: References: <200004120905.LAA10853@mail.macqel.be> X-SW-Source: 2000-04/msg00345.html Content-length: 863 Yes, please do. Thanks. > I recently have had a core dump there, and the other instance of > `free (bcache->bucket)' in bache.c is protected against `free (NULL)', so > I think this is safe. OK to commit ? > > Philippe De Muyter > > * bcache.c (free_bcache): Do not free NULL. > > Index: gdb/bcache.c > =================================================================== > RCS file: /cvs/src/src/gdb/bcache.c,v > retrieving revision 1.2 > diff -u -p -r1.2 bcache.c > --- bcache.c 2000/02/08 04:39:01 1.2 > +++ bcache.c 2000/04/12 08:52:26 > @@ -189,7 +189,8 @@ void > free_bcache (struct bcache *bcache) > { > obstack_free (&bcache->cache, 0); > - free (bcache->bucket); > + if (bcache->bucket) > + free (bcache->bucket); > > /* This isn't necessary, but at least the bcache is always in a > consistent state. */ > >From jimb@zwingli.cygnus.com Tue Apr 18 11:52:00 2000 From: Jim Blandy To: Andrew Cagney Cc: gdb-patches@sourceware.cygnus.com Subject: Re: RFA: gdbarch IEEE_FLOAT Date: Tue, 18 Apr 2000 11:52:00 -0000 Message-id: References: <200004110302.WAA13962@zwingli.cygnus.com> <38F41405.8F24928@cygnus.com> <38FA86D1.2E4CB93D@cygnus.com> X-SW-Source: 2000-04/msg00346.html Content-length: 679 > > > > + /* 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. >From jimb@zwingli.cygnus.com Tue Apr 18 11:56:00 2000 From: Jim Blandy To: Elena Zannoni Cc: Jim Blandy , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] (try #2) cleanup section_addr_info struct Date: Tue, 18 Apr 2000 11:56:00 -0000 Message-id: References: <14583.21953.458777.593608@kwikemart.cygnus.com> <14583.37982.780037.231156@kwikemart.cygnus.com> X-SW-Source: 2000-04/msg00347.html Content-length: 371 > > Approved, with one change: > > > > Could you rename the only remaining member of `struct > > section_addr_info' to `sections'? It's kind of odd to have a > > structure with only one member, named `other'. :) > > > > I was thinking of doing that in another commit, so that the cosmetic > and functional changes would be distinct. Okay, however you please. >From jimb@zwingli.cygnus.com Tue Apr 18 12:54:00 2000 From: Jim Blandy To: gdb-patches@sourceware.cygnus.com Subject: RFA: Document RETURN_VALUE_ON_STACK Date: Tue, 18 Apr 2000 12:54:00 -0000 Message-id: <200004181954.OAA08866@zwingli.cygnus.com> X-SW-Source: 2000-04/msg00348.html Content-length: 1108 Is this okay? Index: gdbint.texinfo =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/doc/gdbint.texinfo,v retrieving revision 1.151 diff -c -c -r1.151 gdbint.texinfo *** gdbint.texinfo 2000/04/16 14:54:43 1.151 --- gdbint.texinfo 2000/04/18 19:53:19 *************** *** 1875,1880 **** --- 1875,1888 ---- form. @xref{Target Architecture Definition, , Using Different Register and Memory Data Representations}. + @item RETURN_VALUE_ON_STACK(@var{type}) + Return non-zero if values of type TYPE are returned on the stack, using + the ``struct convention''. GDB assumes that structures, unions, arrays + passed by value (which never happens in C), and any other types this + predicate likes, might be returned in a struct-like fashion. See the + function @code{using_struct_return} in @file{values.c} to see how this + gets used together with @code{USE_STRUCT_CONVENTION}. + @item SOFTWARE_SINGLE_STEP_P Define this as 1 if the target does not have a hardware single-step mechanism. The macro @code{SOFTWARE_SINGLE_STEP} must also be defined. >From shebs@apple.com Tue Apr 18 13:22:00 2000 From: Stan Shebs To: Jim Blandy Cc: gdb-patches@sourceware.cygnus.com Subject: Re: RFA: Document RETURN_VALUE_ON_STACK Date: Tue, 18 Apr 2000 13:22:00 -0000 Message-id: <38FCC3DD.533C7037@apple.com> References: <200004181954.OAA08866@zwingli.cygnus.com> X-SW-Source: 2000-04/msg00349.html Content-length: 1428 Jim Blandy wrote: > > Is this okay? Your wording could be taken to mean that structures can't be passed by value in C - I would say "(note that arrays are passed by value in some languages, but not in C)" or something like that. Other than that it looks fine to me. Stan > Index: gdbint.texinfo > =================================================================== > RCS file: /cvs/cvsfiles/devo/gdb/doc/gdbint.texinfo,v > retrieving revision 1.151 > diff -c -c -r1.151 gdbint.texinfo > *** gdbint.texinfo 2000/04/16 14:54:43 1.151 > --- gdbint.texinfo 2000/04/18 19:53:19 > *************** > *** 1875,1880 **** > --- 1875,1888 ---- > form. > @xref{Target Architecture Definition, , Using Different Register and Memory Data Representations}. > > + @item RETURN_VALUE_ON_STACK(@var{type}) > + Return non-zero if values of type TYPE are returned on the stack, using > + the ``struct convention''. GDB assumes that structures, unions, arrays > + passed by value (which never happens in C), and any other types this > + predicate likes, might be returned in a struct-like fashion. See the > + function @code{using_struct_return} in @file{values.c} to see how this > + gets used together with @code{USE_STRUCT_CONVENTION}. > + > @item SOFTWARE_SINGLE_STEP_P > Define this as 1 if the target does not have a hardware single-step > mechanism. The macro @code{SOFTWARE_SINGLE_STEP} must also be defined. >From davidw@gordian.com Tue Apr 18 14:50:00 2000 From: David Whedon To: gdb-patches@sourceware.cygnus.com Subject: Re: [RFC] Change configure.in so -W arnings match reality Date: Tue, 18 Apr 2000 14:50:00 -0000 Message-id: X-SW-Source: 2000-04/msg00350.html Content-length: 2255 I'm building the gdb 5.0 branch on our sgi and it has a problem with the warning flags. This error, I believe, is caused by this patch. ( http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00276.html ) My problem would be fixed if -Wreturn-type is removed from gdb/configure.in (see the patch for more info) I think it is because I am using an old gcc (October '99) This error went away after I removed '-Wreturn-type' from the gdb/Makefile WARN_CFLAGS line. Here is the error: gmake[1]: Entering directory `/n/delphi2/irix_52/usr/local/src/gdb-build/68k/gdb' gcc -c -O2 -I. -I/usr/local/src/rib/gdb-5.0/src//gdb -I/usr/local/src/rib/gdb-5.0/src//gdb/config -DHAVE_CONFIG_H -I/usr/local/src/rib/gdb-5.0/src//gdb/../include/opcode -I/usr/local/src/rib/gdb-5.0/src//gdb/../readline/.. -I../bfd -I/usr/local/src/rib/gdb-5.0/src//gdb/../bfd -I/usr/local/src/rib/gdb-5.0/src//gdb/../include -I../intl -I/usr/local/src/rib/gdb-5.0/src//gdb/../intl -I/usr/local/src/rib/gdb-5.0/src//gdb/tui -DUSE_INCLUDED_REGEX -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith /usr/local/src/rib/gdb-5.0/src//gdb/main.c cc1: Invalid option `-Wreturn-type' gmake[1]: *** [main.o] Error 1 gmake[1]: Leaving directory `/n/delphi2/irix_52/usr/local/src/gdb-build/68k/gdb' gmake: *** [all-gdb] Error 2 Other info: # gcc -v Reading specs from /usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.95.2/specs gcc version 2.95.2 19991024 (release) # /usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.95.2/cc1 --help | grep "\-W" -W Enable extra warnings -Winline Warn when an inlined function cannot be inlined -Wuninitialized Warn about unitialized automatic variables -Wcast-align Warn about pointer casts which increase alignment -Waggregate-return Warn about returning structures, unions or arrays -Wswitch Warn about enumerated switches missing a specific ce -Wshadow Warn when one local variable shadows another snip . . . . snip I'll spare you the whole list, but -Wreturn-type isn't in there. I'm not sure what else it could be, and I figure others could be bitten by this too, unless my gcc install is somehow non-standard. -David