From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: msnyder@cygnus.com Cc: Eli Zaretskii , Daniel Berlin , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: add set/show debug, move gdb debugging flags into it Date: Wed, 15 Mar 2000 08:39:00 -0000 Message-ID: <38CFBC54.E7924448@redhat.com> References: <200003150919.EAA29966@indy.delorie.com> <200003151430.JAA01149@indy.delorie.com> <38CFAE9E.39D1C081@redhat.com> <38CFB57A.1900@cygnus.com> X-SW-Source: 2000-03/msg00275.html Message-ID: <20000315083900.inpIHoQtDCDJ6Sd-I_8HdwuAwAzOjTyiVc5tZOq26TM@z> Michael Snyder wrote: > > Fernando Nasser wrote: > > > The documentation problem may not be restricted to the debug command but > > also to other maintenance class commands. They have been considered to > > be restricted to wizards that read source code instead of manuals and so > > they have not been documented in the user's manual. > > I always consider it questionable whether maintenance commands > SHOULD be documented in the user's guide. If they should, > perhaps it should be in a separate section clearly identified > as being for the maintenance and debugging of the debugger. > I agree (I prefer the second option -- a separate section). That is why I said it was a policy issue. I am not sure who is responsible for the content index (organization) of the manual... -- 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 jimb@zwingli.cygnus.com Wed Mar 15 08:53:00 2000 From: Jim Blandy To: Andrew Cagney Cc: gdb-patches@sourceware.cygnus.com Subject: Re: RFA: gdbarch_free Date: Wed, 15 Mar 2000 08:53:00 -0000 Message-id: References: <200002282302.SAA13215@zwingli.cygnus.com> <38BB1A9A.61A680AA@cygnus.com> <38C223E1.43260416@cygnus.com> X-SW-Source: 2000-03/msg00276.html Content-length: 524 > > > >From memory, I figured that if an _initialize* function failed to create > > > a gdbarch the process was somewhat hosed and calling internal_error() > > > was probably the best thing to do. > > > This situation could arise if someone adds support for a new variant > > of my architecture, but hasn't updated GDB yet. > > So the real question is, is this an internal_error() and how should > it be handled? I can be convinced either way on this :-) No, it's okay, I'll just drop the memory. I withdraw the patch. >From dan@cgsoftware.com Wed Mar 15 09:33:00 2000 From: dan@cgsoftware.com (Daniel Berlin+mail.gdb) To: Eli Zaretskii Cc: Daniel Berlin , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: add set/show debug, move gdb debugging flags into it Date: Wed, 15 Mar 2000 09:33:00 -0000 Message-id: References: <200003150919.EAA29966@indy.delorie.com> <200003151430.JAA01149@indy.delorie.com> X-SW-Source: 2000-03/msg00277.html Content-length: 1146 Eli Zaretskii writes: > > Are you saying i should write docs for the commands? > > Yes. Or at least Someone(tm) should. Okey dokey. I'm perfectly willing to document them, but personally, i don't think they *should* be documented. Or at least, the documentation shouldn't go with documentation for any regular commands. > > I consider the lack of any documentation for the commands you replaced > to be part of the same bug that you were fixing. In general, with those debug commands, if you can't figure out what they do based on the one sentence docstring, you shouldn't be touching them. It's hard to say more about what "target debugging" is, except that it enables printing of target debug info. > > Even a simple one-liner that mentions the command's existence, with a > @cindex entry to make it easy to find, is infinitely better than no > documentation at all, because the latter doesn't leave the user any > reasonable way of finding out that the commands exist. They shouldn't find out they exist, unless specifically instructed by someone. IMHO. They are for debugging GDB, not debugging *with* GDB. --Dan >From dan@cgsoftware.com Wed Mar 15 09:42:00 2000 From: dan@cgsoftware.com (Daniel Berlin+mail.gdb) To: Fernando Nasser Cc: Eli Zaretskii , Daniel Berlin , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: add set/show debug, move gdb debugging flags into it Date: Wed, 15 Mar 2000 09:42:00 -0000 Message-id: <8zzk9llj.fsf@dan.resnet.rochester.edu> References: <200003150919.EAA29966@indy.delorie.com> <200003151430.JAA01149@indy.delorie.com> <38CFAE9E.39D1C081@redhat.com> X-SW-Source: 2000-03/msg00278.html Content-length: 1652 Fernando Nasser writes: > First I agree with Eli that these commands must be documented. I don't agree, but i'm perfectly willing to go with the consensus. > > However, I don't think it is a must in Daniel's patch. He is already > fixing a big problem that is the horrible naming/organization of this > commands. As soon as I can get the deprecating patch in I am willing to > check Daniel's patch so we get rid of those abnormalities. > > The documentation problem may not be restricted to the debug command but > also to other maintenance class commands. They have been considered to > be restricted to wizards that read source code instead of manuals and so > they have not been documented in the user's manual. > This is why i don't think they should be documented. Even if you knew what they did, the output wouldn't be useful unless you went digging through the source code, or were familiar with the source. > It is a question of policy and, most importantly, willing of people to > put some time into it (Someone(tm) will have to put some time to do > it.) Hey, i'm Someone(tm). > > Daniel could volunteer to write the debug ones, it would be nice, I just > don't want to conditionalize his patch on that. I'll happily write the documentation for the debug ones, i just have no idea what it should read like. I mean, what do you want me to say about, fer instance, targetdebug? All i can think of is "Controls printing of target_ops functions and their arguments, as they get called". > Eli could document some > other ones. I am not the maintainer of the manual but I guess it will > be welcome. >From jimb@zwingli.cygnus.com Wed Mar 15 10:18:00 2000 From: Jim Blandy To: Jim Blandy Cc: Andrew Cagney , gdb-patches@sourceware.cygnus.com Subject: Re: RFA: gdbarch_free Date: Wed, 15 Mar 2000 10:18:00 -0000 Message-id: References: <200002282302.SAA13215@zwingli.cygnus.com> <38BB1A9A.61A680AA@cygnus.com> <38C223E1.43260416@cygnus.com> X-SW-Source: 2000-03/msg00279.html Content-length: 1703 > > > > >From memory, I figured that if an _initialize* function failed to create > > > > a gdbarch the process was somewhat hosed and calling internal_error() > > > > was probably the best thing to do. > > > > > This situation could arise if someone adds support for a new variant > > > of my architecture, but hasn't updated GDB yet. > > > > So the real question is, is this an internal_error() and how should > > it be handled? I can be convinced either way on this :-) > > No, it's okay, I'll just drop the memory. I withdraw the patch. Well, actually... I don't think this is an internal error. It's simply a case where GDB has been given an executable that it doesn't recognize. That executable may have been produced by a completely different toolchain. GDB gets the architecture and the machine (a variant within an architecture, like 32-bit or 64-bit) from BFD. BFD gets the architecture from the ELF header's e_machine field (note the unfortunate conflict in terminology), and gets the machine by masking off some bits of the ELF header's e_flags field. Suppose e_flags uses a three-bit field to identify the machine variant, and uses 001 and 010 to identify two existing variants. In my foo_gdbarch_init function, I can recognize 001 and 010, but what should I do with other values? If I'm using a newer toolchain with an older GDB executable, this situation could certainly arise, and GDB should report it nicely. I guess I don't see the rationale for assuming that nobody will ever put anything in an executable file that some GDB *_gdbarch_init function won't recognize. GDB should print an error message. This isn't an internal error: the source of the data is external. >From jingham@cygnus.com Wed Mar 15 10:21:00 2000 From: James Ingham To: Andrew Cagney Cc: "Insight (GDB GUI)" , GDB Patches Subject: Re: RFC: More fixes to insights ln -s Date: Wed, 15 Mar 2000 10:21:00 -0000 Message-id: <14543.54628.527337.770021@leda.cygnus.com> References: <38CF37E7.AADF52CF@cygnus.com> X-SW-Source: 2000-03/msg00280.html Content-length: 2803 Andrew, I haven't really been paying that much attention to this configure stuff of late, sorry... But now that I think of it, I am pretty sure all these link machinations are wholly unnecessary. I munged the gdb startup code around so that gdb will find its library files from the build directory without using the link at all. Moreover, when you fail at making the link gdb will still work in GUI mode. So maybe we can just bag all this? However, it would be good to make sure that this is not some wierdness in my environment that makes it work. What about others? If you delete the gdbtcl link in your build directory, can you still run gdb in gui mode from the gdb build directory? If this is true for others as well, then we should just drop the extra complexity. Jim > Hello, > > The attatched patch makes the make target ``all-gdbtk'' which creates a > link more robust. Fernando noted that it issued a warning when it > didn't need to. It could also trip up if there was an invalid old link. > > Ok? > > AndrewWed Mar 15 17:32:48 2000 Andrew Cagney > > * Makefile.in (all-gdbtk): Check for an existing link/directory. > Re-format warning message. > > Index: Makefile.in > =================================================================== > RCS file: /cvs/src/src/gdb/Makefile.in,v > retrieving revision 1.12 > diff -p -r1.12 Makefile.in > *** Makefile.in 2000/03/04 07:11:38 1.12 > --- Makefile.in 2000/03/15 07:09:53 > *************** fork-child.o: fork-child.c gdb_wait.h $( > *** 1260,1273 **** > $(inferior_h) target.h terminal.h gdbthread.h gdb_string.h > > all-gdbtk: > ! if test "$(LN_S)" = "ln -s" -a ! -d gdbtcl/images ; then \ > ! echo linking ${srcdir}/gdbtk/library to gdbtcl ; \ > ! $(LN_S) ${srcdir}/gdbtk/library gdbtcl ; \ > ! else \ > ! echo Warning: Unable to link ${srcdir}/gdbtk/library to gdbtcl. ; \ > ! echo " " You will need to do a ; \ > ! echo " " make install before you are able to run the GUI. ; \ > ! fi > > clean-gdbtk: > rm -f gdbtcl > --- 1260,1278 ---- > $(inferior_h) target.h terminal.h gdbthread.h gdb_string.h > > all-gdbtk: > ! @if test ! -d gdbtcl/images ; then \ > ! if test "$(LN_S)" = "ln -s" ; then \ > ! echo linking ${srcdir}/gdbtk/library to gdbtcl ; \ > ! rm -f gdbtcl ; \ > ! test ! -r gdbtcl || exit 1 ; \ > ! $(LN_S) ${srcdir}/gdbtk/library gdbtcl ; \ > ! else \ > ! echo "Warning:" ; \ > ! echo "Unable to link ${srcdir}/gdbtk/library to gdbtcl." ; \ > ! echo "You will need to do a \`make install' before you are" ; \ > ! echo "able to run the GUI." ; \ > ! fi ; \ > ! else true ; fi > > clean-gdbtk: > rm -f gdbtcl >From msnyder@cygnus.com Wed Mar 15 11:15:00 2000 From: Michael Snyder To: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Linux/i386 testresults & gdb_proc_service.h patch Date: Wed, 15 Mar 2000 11:15:00 -0000 Message-id: <38CFE0A4.12BB@cygnus.com> References: <200002091522.e19FMU318441@delius.kettenis.local> <38AA3DF5.6BAAC6D4@cygnus.com> X-SW-Source: 2000-03/msg00281.html Content-length: 615 Andrew Cagney wrote: > > This patch is ok with me. (Michael is on holidays) > > Andrew > > Mark Kettenis wrote: > > > 2000-02-09 Mark Kettenis > > > > * configure.in: Check for lwpid_t, psaddr_t, prgregset_t and > > fpgregset_t in .c > > * config.in: Add HAVE_LWPID_T, HAVE_PSADDR_T, HAVE_PRGREGSET_T, > > HAVE_PRFPREGSET_T. > > * gdb_proc_service.h: Only provide typedefs for lwpid_t, psaddr_t, > > prgregset_t and prfpregset_t if they are not already present. I'm back. This is good stuff. Thanks! >From dima@Chg.RU Wed Mar 15 11:32:00 2000 From: Dmitry Sivachenko To: gdb-patches@sourceware.cygnus.com Subject: typo in gdb.texinfo Date: Wed, 15 Mar 2000 11:32:00 -0000 Message-id: <200003151932.WAA39200@netserv1.chg.ru> X-SW-Source: 2000-03/msg00282.html Content-length: 681 There is no value for GDBINIT! Consider this fix: --dima --- gdb.texinfo.orig Wed Mar 15 22:31:16 2000 +++ gdb.texinfo Wed Mar 15 22:31:32 2000 @@ -10611,7 +10611,7 @@ @cindex floating point, MIPS remote If your target board does not support the MIPS floating point coprocessor, you should use the command @samp{set mipsfpu none} (if you -need this, you may wish to put the command in your @value{GDBINIT} +need this, you may wish to put the command in your @file{.gdbinit} file). This tells @value{GDBN} how to find the return value of functions which return floating point values. It also allows @value{GDBN} to avoid saving the floating point registers when calling >From msnyder@cygnus.com Wed Mar 15 11:37:00 2000 From: Michael Snyder To: Dmitry Sivachenko Cc: gdb-patches@sourceware.cygnus.com Subject: Re: typo in gdb.texinfo Date: Wed, 15 Mar 2000 11:37:00 -0000 Message-id: <38CFE64A.2BBB@cygnus.com> References: <200003151932.WAA39200@netserv1.chg.ru> X-SW-Source: 2000-03/msg00283.html Content-length: 954 Dmitry Sivachenko wrote: > > There is no value for GDBINIT! > Consider this fix: > > --dima > > --- gdb.texinfo.orig Wed Mar 15 22:31:16 2000 > +++ gdb.texinfo Wed Mar 15 22:31:32 2000 > @@ -10611,7 +10611,7 @@ > @cindex floating point, MIPS remote > If your target board does not support the MIPS floating point > coprocessor, you should use the command @samp{set mipsfpu none} (if you > -need this, you may wish to put the command in your @value{GDBINIT} > +need this, you may wish to put the command in your @file{.gdbinit} > file). This tells @value{GDBN} how to find the return value of > functions which return floating point values. It also allows > @value{GDBN} to avoid saving the floating point registers when calling I think the purpose of having GDBINIT be a variable is because it has a different filename on windows/CYGWIN. Isn't it called "gdb.ini" or something? If the variable truly isn't defined, it probably should be. >From ezannoni@cygnus.com Wed Mar 15 11:41:00 2000 From: Elena Zannoni To: Eli Zaretskii Cc: ezannoni@cygnus.com, ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: GDB-5 2000-03-03 Date: Wed, 15 Mar 2000 11:41:00 -0000 Message-id: <14543.59234.407028.669194@kwikemart.cygnus.com> References: <38BFBD74.79263683@cygnus.com> <200003040702.CAA08162@indy.delorie.com> <38C0E240.FC02154E@cygnus.com> <14531.54961.880860.662139@kwikemart.cygnus.com> <200003151417.JAA01137@indy.delorie.com> X-SW-Source: 2000-03/msg00284.html Content-length: 19022 Eli Zaretskii writes: > > > Andrew Cagney writes: > > > Eli Zaretskii wrote: > > > > > > > But there's a similar issue with Readline. The current version in the > > > > GDB CVS tree has bugs in the DJGPP-specific code, one of which simply > > > > prevents GDB from linking. I see that most of these problems are > > > > solved in the current beta version of Readline, but will you be > > > > synchronizing the GDB tree with that version before release? If not, > > > > I don't see any solution but a local patch. Please advise. > > > > > > Consider yourself the maintainer of the DJGPP specific readline stuff > > > (like mmalloc). (I'll add a note to MAINTAINERS.) > > > > > > The main thing is to make certain that the true readline sources have > > > the fix as well. I wasn't planning on importing readline (I'll add a > > > note stateing that this is something that won't make it). > > > > > > Andrew > > > > Eli, yes, please check in you fix to readline, I have no time this > > week to do another import. > > I just committed the changes below. > > (It seems the readline directory doesn't have a ChangeLog file, 'cause > CVS won't check it out for me. Am I missing something?) > There is ChangeLog.Cygnus file. You can use that for the time being. The readline package doesn't include a ChangeLog. I wonder though if this makes any sense anymore, I mean, the name 'Cygnus'. Elena > --- readline/support/shobj-conf.~ Tue Aug 3 02:08:42 1999 > +++ readline/support/shobj-conf Sat Feb 26 15:07:52 2000 > @@ -305,6 +305,12 @@ > > SHLIB_LIBVERSION='$(SHLIB_LIBSUFF).$(SHLIB_MAJOR)' > ;; > + > +msdosdjgpp*) > + SHOBJ_STATUS=unsupported > + SHLIB_STATUS=unsupported > + ;; > + > # > # Rely on correct gcc configuration for everything else > # > --- readline/bind.c~ Tue Aug 3 02:08:36 1999 > +++ readline/bind.c Wed Feb 23 16:05:52 2000 > @@ -62,6 +62,10 @@ extern int errno; > extern char *strchr (), *strrchr (); > #endif /* !strchr && !__STDC__ */ > > +#ifndef O_BINARY > +# define O_BINARY 0 > +#endif > + > extern int _rl_horizontal_scroll_mode; > extern int _rl_mark_modified_lines; > extern int _rl_bell_preference; > @@ -646,7 +650,7 @@ _rl_read_file (filename, sizep) > char *buffer; > int i, file; > > - if ((stat (filename, &finfo) < 0) || (file = open (filename, O_RDONLY, 0666)) < 0) > + if ((stat (filename, &finfo) < 0) || (file = open (filename, O_RDONLY | O_BINARY, 0666)) < 0) > return ((char *)NULL); > > file_size = (size_t)finfo.st_size; > @@ -667,7 +671,7 @@ _rl_read_file (filename, sizep) > i = read (file, buffer, file_size); > close (file); > > -#if 0 > +#if 1 > if (i < file_size) > #else > if (i < 0) > @@ -678,6 +682,30 @@ _rl_read_file (filename, sizep) > } > > buffer[file_size] = '\0'; > + > +#if O_BINARY > + { > + /* Systems which distinguish between text and binary files need > + to strip the CR characters before each Newline, otherwise the > + parsing functions won't work. */ > + char *s, *d; > + size_t removed = 0; > + > + for (s = buffer, d = buffer; s < buffer + file_size; s++) > + { > + if (removed) > + *d = *s; > + if (*s != '\r' || s[1] != '\n') > + d++; > + else > + removed++; > + } > + > + file_size -= removed; > + buffer[file_size] = '\0'; > + } > +#endif > + > if (sizep) > *sizep = file_size; > return (buffer); > @@ -699,6 +728,7 @@ rl_re_read_init_file (count, ignore) > 1. the filename used for the previous call > 2. the value of the shell variable `INPUTRC' > 3. ~/.inputrc > + 4. (for __MSDOS__ only) ~/_inputrc > If the file existed and could be opened and read, 0 is returned, > otherwise errno is returned. */ > int > @@ -718,6 +748,20 @@ rl_read_init_file (filename) > if (*filename == 0) > filename = DEFAULT_INPUTRC; > > +#ifdef __MSDOS__ > + { > + /* DOS doesn't allow leading dots in file names. If the original > + name fails (it could work if we are on Windows), fall back to > + ~/_inputrc. */ > + int retval = _rl_read_init_file (filename, 0); > + > + if (retval == 0) > + return retval; > + else if (strcmp (filename, "~/.inputrc") == 0) > + filename = "~/_inputrc"; > + } > +#endif > + > return (_rl_read_init_file (filename, 0)); > } > > --- readline/complete.c~ Tue Aug 3 02:08:36 1999 > +++ readline/complete.c Wed Feb 23 18:02:32 2000 > @@ -1407,9 +1410,9 @@ username_completion_function (text, stat > char *text; > int state; > { > -#if defined (__GO32__) || defined (__WIN32__) || defined (__OPENNT) > +#if defined (__WIN32__) || defined (__OPENNT) > return (char *)NULL; > -#else /* !__GO32__ */ > +#else /* !__WIN32__ && !__OPENNT */ > static char *username = (char *)NULL; > static struct passwd *entry; > static int namelen, first_char, first_char_loc; > @@ -1499,6 +1502,14 @@ filename_completion_function (text, stat > strcpy (filename, ++temp); > *temp = '\0'; > } > +#if defined (__WIN32__) || defined (__OPENNT) || defined (__MSDOS__) > + /* Handle the drive-relative names "d:foo/bar". */ > + else if (dirname[1] == ':') > + { > + strcpy (filename, dirname + 2); > + dirname[2] = '\0'; > + } > +#endif > else > { > dirname[0] = '.'; > --- readline/display.c~ Tue Aug 3 02:08:36 1999 > +++ readline/display.c Wed Feb 23 16:13:52 2000 > @@ -1126,8 +1126,10 @@ _rl_move_vert (to) > { > int row, col; > > + i = fflush (rl_outstream); /* make sure the cursor pos is current! */ > ScreenGetCursor (&row, &col); > ScreenSetCursor ((row + to - _rl_last_v_pos), col); > + delta = i; > } > #else /* !__GO32__ */ > > @@ -1377,7 +1379,10 @@ space_to_eol (count) > void > _rl_clear_screen () > { > -#if !defined (__GO32__) > +#if defined (__GO32__) > + ScreenClear (); /* FIXME: only works in text modes */ > + ScreenSetCursor (0, 0); /* term_clrpag is "cl" which homes the cursor */ > +#else > if (term_clrpag) > tputs (term_clrpag, 1, _rl_output_character_function); > else > @@ -1392,6 +1397,7 @@ insert_some_chars (string, count) > int count; > { > #if defined (__GO32__) > +#ifndef __DJGPP__ > int row, col, width; > char *row_start; > > @@ -1400,7 +1406,7 @@ insert_some_chars (string, count) > row_start = ScreenPrimary + (row * width); > > memcpy (row_start + col + count, row_start + col, width - col - count); > - > +#endif /* !__DJGPP__ */ > /* Place the text on the screen. */ > _rl_output_some_chars (string, count); > #else /* !_GO32 */ > @@ -1445,6 +1451,7 @@ static void > delete_chars (count) > int count; > { > +#if !defined (__DJGPP__) > #if defined (__GO32__) > int row, col, width; > char *row_start; > @@ -1473,6 +1480,7 @@ delete_chars (count) > tputs (term_dc, 1, _rl_output_character_function); > } > #endif /* !__GO32__ */ > +#endif /* !__DJGPP__ */ > } > > void > --- readline/histfile.c~ Tue Aug 3 02:08:38 1999 > +++ readline/histfile.c Wed Feb 23 18:11:46 2000 > @@ -140,6 +140,16 @@ read_history_range (filename, from, to) > input = history_filename (filename); > file = open (input, O_RDONLY|O_BINARY, 0666); > > + > +#ifdef __MSDOS__ > + /* MSDOS doesn't allow leading dots in file names. Try again > + with the dot replaced by an underscore. */ > + if (file < 0 && !filename) > + { > + input[strlen (input) - 8] = '_'; > + file = open (input, O_RDONLY|O_BINARY, 0666); > + } > +#endif > if ((file < 0) || (fstat (file, &finfo) == -1)) > goto error_and_exit; > > @@ -233,6 +243,16 @@ history_truncate_file (fname, lines) > filename = history_filename (fname); > file = open (filename, O_RDONLY|O_BINARY, 0666); > > +#ifdef __MSDOS__ > + /* MSDOS doesn't allow leading dots in file names. Try again > + with the dot replaced by an underscore. */ > + if (file < 0 && !fname) > + { > + filename[strlen (filename) - 8] = '_'; > + file = open (filename, O_RDONLY|O_BINARY, 0666); > + } > +#endif > + > if (file == -1 || fstat (file, &finfo) == -1) > goto truncate_exit; > > @@ -314,8 +334,23 @@ history_do_write (filename, nelements, o > > if ((file = open (output, mode, 0600)) == -1) > { > +#ifdef __MSDOS__ > + /* MSDOS doesn't allow leading dots in file names. If this is > + the default file name, try again with the dot replaced by an > + underscore. */ > + if (!filename) > + { > + output[strlen (output) - 8] = '_'; > + if ((file = open (output, mode, 0600)) == -1) > + { > + FREE (output); > + return (errno); > + } > + } > +#else > FREE (output); > return (errno); > +#endif > } > > if (nelements > history_length) > --- readline/input.c~ Tue Aug 3 02:08:38 1999 > +++ readline/input.c Wed Feb 23 16:25:20 2000 > @@ -96,7 +96,7 @@ extern Keymap _rl_keymap; > > extern int _rl_convert_meta_chars_to_ascii; > > -#if defined (__GO32__) > +#if defined (__GO32__) && !defined (HAVE_SELECT) > # include > #endif /* __GO32__ */ > > @@ -176,7 +176,7 @@ rl_unget_char (key) > static void > rl_gather_tyi () > { > -#if defined (__GO32__) > +#if defined (__GO32__) && !defined (HAVE_SELECT) > char input; > > if (isatty (0) && kbhit () && ibuffer_space ()) > @@ -397,7 +397,7 @@ rl_getc (stream) > int result, flags; > unsigned char c; > > -#if defined (__GO32__) > +#if defined (__GO32__) && !defined (HAVE_TERMIOS_H) > if (isatty (0)) > return (getkey () & 0x7F); > #endif /* __GO32__ */ > @@ -448,7 +448,7 @@ rl_getc (stream) > } > #endif /* _POSIX_VERSION && EAGAIN && O_NONBLOCK */ > > -#if !defined (__GO32__) > +#if !defined (__GO32__) || defined (HAVE_TERMIOS_H) > /* If the error that we received was SIGINT, then try again, > this is simply an interrupted system call to read (). > Otherwise, some error ocurred, also signifying EOF. */ > --- readline/readline.c~ Tue Aug 3 02:08:38 1999 > +++ readline/readline.c Wed Feb 23 17:58:46 2000 > @@ -163,14 +163,16 @@ static void readline_initialize_everythi > static void start_using_history (); > static void bind_arrow_keys (); > > -#if !defined (__GO32__) > +#if !defined (__GO32__) || defined (HAVE_TERMIOS_H) > static void readline_default_bindings (); > #endif /* !__GO32__ */ > > #if defined (__GO32__) > # include > # include > -# undef HANDLE_SIGNALS > +# if !defined (__DJGPP__) > +# undef HANDLE_SIGNALS > +# endif /* !__DJGPP__ */ > #endif /* __GO32__ */ > > extern char *xmalloc (), *xrealloc (); > @@ -745,10 +747,10 @@ readline_initialize_everything () > /* Initialize the terminal interface. */ > _rl_init_terminal_io ((char *)NULL); > > -#if !defined (__GO32__) > +#if !defined (__GO32__) || defined (HAVE_TERMIOS_H) > /* Bind tty characters to readline functions. */ > readline_default_bindings (); > -#endif /* !__GO32__ */ > +#endif /* !__GO32__ || HAVE_TERMIOS_H */ > > /* Initialize the function names. */ > rl_initialize_funmap (); > @@ -1272,7 +1279,7 @@ rl_refresh_line (ignore1, ignore2) > _rl_move_vert (curr_line); > _rl_move_cursor_relative (0, the_line); /* XXX is this right */ > > -#if defined (__GO32__) > +#if defined (__GO32__) && !defined (__DJGPP__) > { > int row, col, width, row_start; > > @@ -1281,9 +1288,9 @@ rl_refresh_line (ignore1, ignore2) > row_start = ScreenPrimary + (row * width); > memset (row_start + col, 0, (width - col) * 2); > } > -#else /* !__GO32__ */ > +#else /* !__GO32__ || __DJGPP__ */ > _rl_clear_to_eol (0); /* arg of 0 means to not use spaces */ > -#endif /* !__GO32__ */ > +#endif /* !__GO32__ || __DJGPP__ */ > > rl_forced_update_display (); > rl_display_fixed = 1; > --- readline/rltty.c~ Mon Aug 16 22:17:56 1999 > +++ readline/rltty.c Wed Feb 23 15:56:42 2000 > @@ -57,7 +57,9 @@ extern void _rl_control_keypad (); > > #if defined (__GO32__) > # include > -# undef HANDLE_SIGNALS > +# if !defined (__DJGPP__) > +# undef HANDLE_SIGNALS > +# endif /* !__DJGPP__ */ > #endif /* __GO32__ */ > > /* Indirect functions to allow apps control over terminal management. */ > @@ -260,7 +262,7 @@ prepare_terminal_settings (meta_flag, ot > int meta_flag; > TIOTYPE otio, *tiop; > { > -#if !defined (__GO32__) > +#if !defined (__GO32__) || defined (HAVE_TERMIOS_H) > readline_echoing_p = (otio.sgttyb.sg_flags & ECHO); > > /* Copy the original settings to the structure we're going to use for > @@ -326,7 +328,7 @@ prepare_terminal_settings (meta_flag, ot > tiop->ltchars.t_dsuspc = -1; /* C-y */ > tiop->ltchars.t_lnextc = -1; /* C-v */ > #endif /* TIOCGLTC */ > -#endif /* !__GO32__ */ > +#endif /* !__GO32__ || HAVE_TERMIOS_H */ > } > > #else /* !defined (NEW_TTY_DRIVER) */ > @@ -524,7 +526,7 @@ void > rl_prep_terminal (meta_flag) > int meta_flag; > { > -#if !defined (__GO32__) > +#if !defined (__GO32__) || defined (HAVE_TERMIOS_H) > int tty; > TIOTYPE tio; > > @@ -559,14 +561,14 @@ rl_prep_terminal (meta_flag) > terminal_prepped = 1; > > release_sigint (); > -#endif /* !__GO32__ */ > +#endif /* !__GO32__ || HAVE_TERMIOS_H */ > } > > /* Restore the terminal's normal settings and modes. */ > void > rl_deprep_terminal () > { > -#if !defined (__GO32__) > +#if !defined (__GO32__) || defined (HAVE_TERMIOS_H) > int tty; > > if (!terminal_prepped) > @@ -591,7 +593,7 @@ rl_deprep_terminal () > terminal_prepped = 0; > > release_sigint (); > -#endif /* !__GO32__ */ > +#endif /* !__GO32__ || HAVE_TERMIOS_H */ > } > > /* **************************************************************** */ > --- readline/signals.c~ Tue Aug 3 02:08:38 1999 > +++ readline/signals.c Wed Feb 23 18:04:20 2000 > @@ -40,9 +40,9 @@ > # include > #endif /* GWINSZ_IN_SYS_IOCTL */ > > -#if defined (__GO32__) > +#if defined (__GO32__) && !defined(__DJGPP__) > # undef HANDLE_SIGNALS > -#endif /* __GO32__ */ > +#endif /* __GO32__ && !__DJGPP__ */ > > #if defined (HANDLE_SIGNALS) > /* Some standard library routines. */ > @@ -93,7 +93,9 @@ int rl_catch_sigwinch = 1; > #endif > > static int signals_set_flag; > +#ifdef SIGWINCH > static int sigwinch_set_flag; > +#endif > > /* **************************************************************** */ > /* */ > --- readline/terminal.c~ Tue Aug 3 02:08:38 1999 > +++ readline/terminal.c Wed Feb 23 18:07:12 2000 > @@ -57,6 +57,10 @@ > # include > #endif /* GWINSZ_IN_SYS_IOCTL && !TIOCGWINSZ */ > > +#if defined (__GO32__) > +# include > +#endif > + > #include "rltty.h" > #include "tcap.h" > > @@ -77,19 +81,24 @@ extern void _rl_bind_if_unbound (); > extern void set_lines_and_columns (); > extern char *get_env_value (); > > +/* Functions imported from display.c */ > +extern void _rl_redisplay_after_sigwinch (); > + > /* **************************************************************** */ > /* */ > /* Terminal and Termcap */ > /* */ > /* **************************************************************** */ > > +#ifndef __DJGPP__ > static char *term_buffer = (char *)NULL; > static char *term_string_buffer = (char *)NULL; > > -static int tcap_initialized; > - > /* Non-zero means this terminal can't really do anything. */ > static int dumb_term; > +#endif > + > +static int tcap_initialized; > > #if !defined (__linux__) > # if defined (__EMX__) || defined (NEED_EXTERN_PC) > @@ -186,7 +195,11 @@ _rl_get_screen_size (tty, ignore_env) > if (ignore_env == 0 && (ss = get_env_value ("COLUMNS"))) > screenwidth = atoi (ss); > > -#if !defined(__DJGPP__) > +#if defined(__DJGPP__) > + tty = tty; > + if (screenwidth <= 0) > + screenwidth = ScreenCols (); > +#else > if (screenwidth <= 0 && term_string_buffer) > screenwidth = tgetnum ("co"); > #endif > @@ -199,7 +212,10 @@ _rl_get_screen_size (tty, ignore_env) > if (ignore_env == 0 && (ss = get_env_value ("LINES"))) > screenheight = atoi (ss); > > -#if !defined(__DJGPP__) > +#if defined(__DJGPP__) > + if (screenheight <= 0) > + screenheight = ScreenRows (); > +#else > if (screenheight <= 0 && term_string_buffer) > screenheight = tgetnum ("li"); > #endif > @@ -291,7 +307,9 @@ static void > get_term_capabilities (bp) > char **bp; > { > -#if !defined(__DJGPP__) > +#if defined(__DJGPP__) > + bp = bp; > +#else > register int i; > > for (i = 0; i < NUM_TC_STRINGS; i++) > @@ -305,9 +323,10 @@ _rl_init_terminal_io (terminal_name) > char *terminal_name; > { > #if defined (__GO32__) > - screenwidth = ScreenCols (); > - screenheight = ScreenRows (); > - screenchars = screenwidth * screenheight; > + terminal_name = terminal_name; > + screenwidth = screenheight = 0; > + _rl_get_screen_size (rl_instream ? fileno (rl_instream) : 0, 0); > + > term_cr = "\r"; > term_im = term_ei = term_ic = term_IC = (char *)NULL; > term_up = term_dc = term_DC = visible_bell = (char *)NULL; > @@ -323,7 +342,7 @@ _rl_init_terminal_io (terminal_name) > term_forward_char = (char *)NULL; > #endif /* HACK_TERMCAP_MOTION */ > terminal_can_insert = _rl_term_autowrap = 0; > - return; > + return 0; > #else /* !__GO32__ */ > > char *term, *buffer; > @@ -510,28 +529,28 @@ ding () > { > if (readline_echoing_p) > { > -#if !defined (__GO32__) > switch (_rl_bell_preference) > { > case NO_BELL: > default: > break; > case VISIBLE_BELL: > +#if defined (__GO32__) > + ScreenVisualBell (); > + break; > +#else > if (visible_bell) > { > tputs (visible_bell, 1, _rl_output_character_function); > break; > } > +#endif > /* FALLTHROUGH */ > case AUDIBLE_BELL: > fprintf (stderr, "\007"); > fflush (stderr); > break; > } > -#else /* __GO32__ */ > - fprintf (stderr, "\007"); > - fflush (stderr); > -#endif /* __GO32__ */ > return (0); > } > return (-1); > @@ -556,7 +575,9 @@ void > _rl_control_keypad (on) > int on; > { > -#if !defined(__DJGPP__) > +#if defined(__DJGPP__) > + on = on; > +#else > if (on && term_ks) > tputs (term_ks, 1, _rl_output_character_function); > else if (!on && term_ke) >From ezannoni@cygnus.com Wed Mar 15 11:43:00 2000 From: Elena Zannoni To: Eli Zaretskii Cc: ezannoni@cygnus.com, shebs@apple.com, gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] GDB command-line switches and annotations docs Date: Wed, 15 Mar 2000 11:43:00 -0000 Message-id: <14543.59354.570747.545184@kwikemart.cygnus.com> References: <14537.5048.99180.910863@kwikemart.cygnus.com> <200003101809.NAA22092@indy.delorie.com> <14537.18119.116000.442262@kwikemart.cygnus.com> <200003120754.CAA24393@indy.delorie.com> <14539.49127.700844.807495@kwikemart.cygnus.com> <200003151414.JAA01131@indy.delorie.com> X-SW-Source: 2000-03/msg00285.html Content-length: 2610 Eli Zaretskii writes: > > > > If it would help, I could add a note telling that the event loop is > > > still not fully asynchronous, with a FIXME comment that the note > > > should be removed when the target side is done. Okay? > > > > Perfect, thanks! > > I attach below the changes which address the above, and also what Stan > said about moving the Annotations chapter before the appendices. > These changes are to be applied _on top_ of those I sent in the > previous message. > > Is it okay to commit this and the previous patch? > Ok with me for contents, but I am not the docs maintainer. Elena > --- gdb/doc/gdb.t~1 Fri Mar 10 16:39:30 2000 > +++ gdb/doc/gdb.texi Tue Mar 14 22:34:26 2000 > @@ -146,6 +146,7 @@ > * Controlling GDB:: Controlling @value{GDBN} > * Sequences:: Canned sequences of commands > * Emacs:: Using @value{GDBN} under @sc{gnu} Emacs > +* Annotations:: @value{GDBN}'s annotations interface. > > * GDB Bugs:: Reporting bugs in @value{GDBN} > * Formatting Documentation:: How to format and print @value{GDBN} documentation > @@ -153,7 +154,6 @@ > * Command Line Editing:: Command Line Editing > * Using History Interactively:: Using History Interactively > * Installing GDB:: Installing GDB > -* Annotations:: @value{GDBN}'s annotations interface. > * Index:: Index > @end menu > > @@ -945,6 +945,11 @@ > MS-DOS/MS-Windows supports this mode of operation, but the event loop is > suspended when the debuggee runs.}, so you don't need to wait for > control to return to @value{GDBN} before you type the next command. > +(@emph{Note:} as of version 5.0, the target side of the asynchronous > +operation is not yet in place, so @samp{-async} does not work fully > +yet.) > +@c FIXME: when the target side of the event loop is done, the above NOTE > +@c should be removed. > > When the standard input is connected to a terminal device, @value{GDBN} > uses the asynchronous event loop by default, unless disabled by the > @@ -11970,6 +11975,8 @@ > each value is printed in its own window. > @end ignore > > +@include annotate.texi > + > @node GDB Bugs > @chapter Reporting Bugs in @value{GDBN} > @cindex bugs in @value{GDBN} > @@ -12592,8 +12599,6 @@ > > There are many other options available as well, but they are generally > needed for special purposes only. > - > -@include annotate.texi > > @node Index > @unnumbered Index >From msnyder@cygnus.com Wed Mar 15 11:45:00 2000 From: Michael Snyder To: gdb-patches@sourceware.cygnus.com Subject: Re: RFA: symfile.c: Fix for GDB crash when rereading symbols Date: Wed, 15 Mar 2000 11:45:00 -0000 Message-id: <38CFE802.E14@cygnus.com> References: <200003141046.LAA08835@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-03/msg00286.html Content-length: 342 Peter.Schauer wrote: > > symfile.c:reread_symbols does not clear the new msymbol hash tables in the > objfile, causing stale pointers and a GDB crash during the reread.exp > test on Solaris. > > Here is a fix: > > * symfile.c (reread_symbols): Clear msymbol hash table. I've checked it in. Thanks again. Michael >From shebs@apple.com Wed Mar 15 11:55:00 2000 From: Stan Shebs To: Dmitry Sivachenko Cc: gdb-patches@sourceware.cygnus.com Subject: Re: typo in gdb.texinfo Date: Wed, 15 Mar 2000 11:55:00 -0000 Message-id: <38CFEAA9.E74A4A9F@apple.com> References: <200003151932.WAA39200@netserv1.chg.ru> X-SW-Source: 2000-03/msg00287.html Content-length: 447 Dmitry Sivachenko wrote: > > There is no value for GDBINIT! > Consider this fix: Good catch! This was supposed to come from the configuration file, but that's being phased out, I must have missed the GDBINIT ref. I'll figure out what to say here and check something in; it shouldn't be @code{.gdbinit} literally, because a) it's not correct for Unix, and b) it's possible to have a config- specific name, such as .vxgdbinit for VxWorks. Stan >From shebs@apple.com Wed Mar 15 12:13:00 2000 From: Stan Shebs To: msnyder@cygnus.com Cc: Fernando Nasser , Eli Zaretskii , Daniel Berlin , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: add set/show debug, move gdb debugging flags into it Date: Wed, 15 Mar 2000 12:13:00 -0000 Message-id: <38CFEEE2.3AD118BD@apple.com> References: <200003150919.EAA29966@indy.delorie.com> <200003151430.JAA01149@indy.delorie.com> <38CFAE9E.39D1C081@redhat.com> <38CFB57A.1900@cygnus.com> X-SW-Source: 2000-03/msg00288.html Content-length: 1138 Michael Snyder wrote: > > Fernando Nasser wrote: > > > The documentation problem may not be restricted to the debug command but > > also to other maintenance class commands. They have been considered to > > be restricted to wizards that read source code instead of manuals and so > > they have not been documented in the user's manual. > > I always consider it questionable whether maintenance commands > SHOULD be documented in the user's guide. If they should, > perhaps it should be in a separate section clearly identified > as being for the maintenance and debugging of the debugger. I've been in favor of including them, just because users sometimes have need of those commands. remotedebug is perhaps the best-known example; while nominally for maintenance on the standard protocol, it's become a staple for embedded developers, since bugs in the application can trash the stub, and remotedebug will help you see what is happening. You're right that maint commands should generally be documented in their own section, so they're only found by the truly desperate users... :-) It's on my list, but at a low priority. Stan >From shebs@apple.com Wed Mar 15 12:18:00 2000 From: Stan Shebs To: Eli Zaretskii Cc: Daniel Berlin , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: add set/show debug, move gdb debugging flags into it Date: Wed, 15 Mar 2000 12:18:00 -0000 Message-id: <38CFF02C.B39564B7@apple.com> References: <200003150919.EAA29966@indy.delorie.com> <200003151430.JAA01149@indy.delorie.com> X-SW-Source: 2000-03/msg00289.html Content-length: 1054 Eli Zaretskii wrote: > > > Are you saying i should write docs for the commands? > > Yes. Or at least Someone(tm) should. > > I consider the lack of any documentation for the commands you replaced > to be part of the same bug that you were fixing. Agree completely. > Even a simple one-liner that mentions the command's existence, with a > @cindex entry to make it easy to find, is infinitely better than no > documentation at all, because the latter doesn't leave the user any > reasonable way of finding out that the commands exist. Yes. While in theory GDB's online help will eventually find you the documentation for a command, its organization means that you have to do a bunch of thumbing around to find something (and it was a *real* pain before things got alphabetized!). Online also doesn't work if the command is configuration-specific and not in your configuration - you would be led to the conclusion that the command didn't exist, and could only find out otherwise by doing a mass search through the sources. Sad, very sad... Stan >From shebs@apple.com Wed Mar 15 12:20:00 2000 From: Stan Shebs To: Eli Zaretskii Cc: ezannoni@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] GDB command-line switches and annotations docs Date: Wed, 15 Mar 2000 12:20:00 -0000 Message-id: <38CFF074.B275A986@apple.com> References: <14537.5048.99180.910863@kwikemart.cygnus.com> <200003101809.NAA22092@indy.delorie.com> <14537.18119.116000.442262@kwikemart.cygnus.com> <200003120754.CAA24393@indy.delorie.com> <14539.49127.700844.807495@kwikemart.cygnus.com> <200003151414.JAA01131@indy.delorie.com> X-SW-Source: 2000-03/msg00290.html Content-length: 560 Eli Zaretskii wrote: > > > > If it would help, I could add a note telling that the event loop is > > > still not fully asynchronous, with a FIXME comment that the note > > > should be removed when the target side is done. Okay? > > > > Perfect, thanks! > > I attach below the changes which address the above, and also what Stan > said about moving the Annotations chapter before the appendices. > These changes are to be applied _on top_ of those I sent in the > previous message. > > Is it okay to commit this and the previous patch? Go for it! Stan >From kingdon@redhat.com Wed Mar 15 13:15:00 2000 From: Jim Kingdon To: gdb-patches@sourceware.cygnus.com Subject: Re: RFD: infrun.c: No bpstat_stop_status call after proceed over break ? Date: Wed, 15 Mar 2000 13:15:00 -0000 Message-id: References: <200003130948.KAA07547@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-03/msg00291.html Content-length: 1740 > I am currently trying to fix a GDB bug with missing watchpoint triggers > after proceeding over a breakpoint on x86 targets. > > Here is an example, using gdb.c++/annota2: Yeah, I ran into the same bug (the testsuite hits it on x86 Linux). My fix was similar to what you suggest (identical, unless I'm missing something). I don't remember it as creating testsuite regressions but I'm not sure I checked - it was a while ago that I looked into this. Index: infrun.c =================================================================== RCS file: /cvs/gdb/gdb/gdb/infrun.c,v retrieving revision 1.1.1.27 diff -u -r1.1.1.27 infrun.c --- infrun.c 2000/02/05 07:29:43 1.1.1.27 +++ infrun.c 2000/02/07 13:22:02 @@ -2076,6 +2076,18 @@ return; } +#if 0 + /* We might not want to think about breakpoints, but what + about hardware watchpoints? We yanked out the hardware + (debug register or whatever) when we stepped over the breakpoint, + so we need to check manually the watchpoint condition (mildly + painful because it could get expensive, but I don't see how + using the hardware could work without lots of spaghetti trying + to keep track of what is inserted and what isn't (and how they + interact)). + + TODO: Need to think more about this, test it, &c. Right now it + is kind of an idea more so than a well-thought-out solution. */ /* Don't even think about breakpoints if just proceeded over a breakpoint. @@ -2087,6 +2099,7 @@ && through_sigtramp_breakpoint == NULL) bpstat_clear (&stop_bpstat); else +#endif /* 0 */ { /* See if there is a breakpoint at the current PC. */ stop_bpstat = bpstat_stop_status