* [PATCH]: add set/show debug, move gdb debugging flags into it
@ 2000-03-13 9:04 Daniel Berlin
2000-04-01 0:00 ` Fernando Nasser
[not found] ` <200003150919.EAA29966@indy.delorie.com>
0 siblings, 2 replies; 4+ messages in thread
From: Daniel Berlin @ 2000-03-13 9:04 UTC (permalink / raw)
To: gdb-patches
Attached is a patch to add "set debug" and "show debug", and move the gdb
debugging stuff (targetdebug,expressiondebug,etc) into those lists.
I renamed targetdebug,expressiondebug,etc (all the debug settings i
moved), to remove the "debug" from their name, so you do "set debug target
1" rather than "set debug targetdebug 1".
The new command lists are named setdebuglist/showdebuglist, and are in
command.c.
I put set_debug and show_debug into command.c, for lack of a better place.
The point of all this is to make it much easier to see what debugging
flags you can set for GDB, and what they were set to. It also declutters
the set list.
I also enabled monitordebug, since it said int he comment it was waiting
for "set debug".
I have no idea who needs to approve this, since it touches a bunch of
stuff, but is only related to one domain so to speak.
I'm working on a changelog entry, i wanted to get comments first.
Example of what you get with the patch installed:
(gdb) help set debug
Generic command for setting gdb debugging flags
List of set debug subcommands:
set debug arch -- Set architecture debugging
set debug event -- Set event debugging
set debug expression -- Set expression debugging
set debug remote -- Set debugging of remote protocol
set debug serial -- Set serial debugging
set debug target -- Set target debugging
set debug varobj -- Set varobj debugging
Type "help set debug" followed by set debug subcommand name for full
documentation.
Command name abbreviations are allowed if unambiguous.
(gdb)
(gdb) help show debug
Generic command for showing gdb debugging flags
List of show debug subcommands:
show debug arch -- Show architecture debugging
show debug event -- Show event debugging
show debug expression -- Show expression debugging
show debug remote -- Show debugging of remote protocol
show debug serial -- Show serial debugging
show debug target -- Show target debugging
show debug varobj -- Show varobj debugging
Type "help show debug" followed by show debug subcommand name for full
documenta
tion.
Command name abbreviations are allowed if unambiguous.
(gdb)
(gdb) show debug
arch: Architecture debugging is 0.
event: Event debugging is 0.
expression: Expression debugging is 0.
remote: Debugging of remote protocol is 0.
serial: Serial debugging is 0.
target: Target debugging is 0.
varobj: Varobj debugging is 0.
(gdb) set debug
"set debug" must be followed by the name of a print subcommand.
List of set debug subcommands:
set debug arch -- Set architecture debugging
set debug event -- Set event debugging
set debug expression -- Set expression debugging
set debug remote -- Set debugging of remote protocol
set debug serial -- Set serial debugging
set debug target -- Set target debugging
set debug varobj -- Set varobj debugging
Type "help set debug" followed by set debug subcommand name for full
documentati
on.
Command name abbreviations are allowed if unambiguous.
(gdb)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH]: add set/show debug, move gdb debugging flags into it
2000-04-01 0:00 ` Fernando Nasser
@ 2000-03-15 8:39 ` Fernando Nasser
0 siblings, 0 replies; 4+ messages in thread
From: Fernando Nasser @ 2000-03-15 8:39 UTC (permalink / raw)
To: msnyder; +Cc: Eli Zaretskii, Daniel Berlin, gdb-patches
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 <jimb@zwingli.cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: gdbarch_free
Date: Wed, 15 Mar 2000 08:53:00 -0000
Message-id: <npk8j49nv0.fsf@zwingli.cygnus.com>
References: <200002282302.SAA13215@zwingli.cygnus.com> <38BB1A9A.61A680AA@cygnus.com> <npg0ualjj3.fsf@zwingli.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 <eliz@is.elta.co.il>
Cc: Daniel Berlin <dan@cgsoftware.com>, 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: <d7ow9m0h.fsf@dan.resnet.rochester.edu>
References: <Pine.LNX.4.10.10003130852170.6968-200000@localhost.localdomain> <200003150919.EAA29966@indy.delorie.com> <r9dctixc.fsf@dan.resnet.rochester.edu> <200003151430.JAA01149@indy.delorie.com>
X-SW-Source: 2000-03/msg00277.html
Content-length: 1146
Eli Zaretskii <eliz@delorie.com> 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 <fnasser@redhat.com>
Cc: Eli Zaretskii <eliz@is.elta.co.il>, Daniel Berlin <dan@cgsoftware.com>, 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: <Pine.LNX.4.10.10003130852170.6968-200000@localhost.localdomain> <200003150919.EAA29966@indy.delorie.com> <r9dctixc.fsf@dan.resnet.rochester.edu> <200003151430.JAA01149@indy.delorie.com> <38CFAE9E.39D1C081@redhat.com>
X-SW-Source: 2000-03/msg00278.html
Content-length: 1652
Fernando Nasser <fnasser@redhat.com> 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 <jimb@zwingli.cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: gdbarch_free
Date: Wed, 15 Mar 2000 10:18:00 -0000
Message-id: <nphfe89jwc.fsf@zwingli.cygnus.com>
References: <200002282302.SAA13215@zwingli.cygnus.com> <38BB1A9A.61A680AA@cygnus.com> <npg0ualjj3.fsf@zwingli.cygnus.com> <38C223E1.43260416@cygnus.com> <npk8j49nv0.fsf@zwingli.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 <jingham@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: "Insight (GDB GUI)" <insight@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
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 <cagney@b1.cygnus.com>
>
> * 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 <msnyder@cygnus.com>
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 <kettenis@gnu.org>
> >
> > * configure.in: Check for lwpid_t, psaddr_t, prgregset_t and
> > fpgregset_t in <sys/procfs.h>.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 <dima@Chg.RU>
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 <msnyder@cygnus.com>
To: Dmitry Sivachenko <dima@Chg.RU>
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 <ezannoni@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
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 <pc.h>
> #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 <go32.h>
> # include <pc.h>
> -# 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 <pc.h>
> -# 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 */
> }
> \f
> /* **************************************************************** */
> --- 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 <sys/ioctl.h>
> #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 <sys/ioctl.h>
> #endif /* GWINSZ_IN_SYS_IOCTL && !TIOCGWINSZ */
>
> +#if defined (__GO32__)
> +# include <pc.h>
> +#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 <ezannoni@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
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 <msnyder@cygnus.com>
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 <shebs@apple.com>
To: Dmitry Sivachenko <dima@Chg.RU>
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 <shebs@apple.com>
To: msnyder@cygnus.com
Cc: Fernando Nasser <fnasser@redhat.com>, Eli Zaretskii <eliz@is.elta.co.il>, Daniel Berlin <dan@cgsoftware.com>, 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: <Pine.LNX.4.10.10003130852170.6968-200000@localhost.localdomain> <200003150919.EAA29966@indy.delorie.com> <r9dctixc.fsf@dan.resnet.rochester.edu> <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 <shebs@apple.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Daniel Berlin <dan@cgsoftware.com>, 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: <Pine.LNX.4.10.10003130852170.6968-200000@localhost.localdomain> <200003150919.EAA29966@indy.delorie.com> <r9dctixc.fsf@dan.resnet.rochester.edu> <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 <shebs@apple.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
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 <kingdon@redhat.com>
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: <bem9cx7kb.fsf@rtl.cygnus.com>
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH]: add set/show debug, move gdb debugging flags into it
[not found] ` <38CFB57A.1900@cygnus.com>
@ 2000-04-01 0:00 ` Fernando Nasser
2000-03-15 8:39 ` Fernando Nasser
0 siblings, 1 reply; 4+ messages in thread
From: Fernando Nasser @ 2000-04-01 0:00 UTC (permalink / raw)
To: msnyder; +Cc: Eli Zaretskii, Daniel Berlin, gdb-patches
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 ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: tromey@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch: make "!" a command unconditionally
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BB5D9F.1A9BF1B3@cygnus.com>
References: <87itz9cabi.fsf@cygnus.com>
X-SW-Source: 2000-q1/msg00413.html
Content-length: 1214
Tom Tromey wrote:
>
> I'd like "!" to be an unconditional alias for "shell".
> Here is a patch.
>
> 2000-02-28 Tom Tromey <tromey@cygnus.com>
>
> * command.c (_initialize_command): Make "!" alias
> unconditionally.
>
> Tom
>
> Index: command.c
> ===================================================================
> RCS file: /cvs/cvsfiles/devo/gdb/command.c,v
> retrieving revision 1.65
> diff -u -r1.65 command.c
> --- command.c 2000/02/09 08:53:11 1.65
> +++ command.c 2000/02/28 20:57:08
> @@ -1678,8 +1678,7 @@
> "Execute the rest of the line as a shell command. \n\
> With no arguments, run an inferior shell.");
>
> - if (xdb_commands)
> - add_com_alias ("!", "shell", class_support, 0);
> + add_com_alias ("!", "shell", class_support, 0);
>
> add_com ("make", class_support, make_command,
> "Run the ``make'' program using the rest of the line as arguments.");
From memory this has been suggested before. The problem pointed out
last time was that you need to specify:
``!'' <space> <command>
I think there also may have been a debate over ``!'' as a shell escape
vs ``!'' for history.
(personally it didn't worry me). Fernando?
Andrew
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: John David Anglin <dave@hiauly1.hia.nrc.ca>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Initialization of hpux_threads
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D2CB7D.24B6@cygnus.com>
References: <200003162153.QAA08326@hiauly1.hia.nrc.ca>
X-SW-Source: 2000-q1/msg00763.html
Content-length: 752
John David Anglin wrote:
>
> Thu Mar 16 16:49:27 EST 2000 John David Anglin <dave@hiauly1.hia.nrc.ca>
>
> * configure.in: Don't call _initialize_hpux_thread twice.
> * configure: Regenerated.
>
> --- configure.in.orig Mon Mar 6 18:30:12 2000
> +++ configure.in Thu Mar 16 14:22:26 2000
> @@ -330,7 +330,6 @@
> AC_DEFINE(HAVE_HPUX_THREAD_SUPPORT)
> CONFIG_OBS="${CONFIG_OJS} hpux-thread.o"
> CONFIG_SRCS="${CONFIG_SRCS} hpux-thread.c"
> - CONFIG_INITS="${CONFIG_INITS} hpux-thread.c"
> else
> AC_MSG_RESULT(no (suppressed because you are not using GCC))
> fi
If someone from HP will approve this, I will check it in...
Michael Snyder
From dima@Chg.RU Sat Apr 01 00:00:00 2000
From: Dmitry Sivachenko <dima@Chg.RU>
To: eliz@delorie.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: patch for gdb.texinfo
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002071343.QAA75257@netserv1.chg.ru>
References: <200001310726.CAA18306@indy.delorie.com>
X-SW-Source: 2000-q1/msg00082.html
Content-length: 658
> > This sounds like 'I will not use C++ templates, because gcc 2.7 handles them
> > ugly and many users have that version installed'.
>
> And what's wrong with that, exactly? Is it bad to respect our users
> and not force them to upgrade just because we are excited with the hot
> new features?
>
> For many people and organizations, GDB is a tool, not a goal in
> itself. They want to install it and forget about the fact they
> installed a new version. The last thing they want is to have an
> avalanche of additional installations that come as a ``package deal''
> with GDB.
It is very unlikely for these people to remake gdb.dvi from gdb.texinfo...
From fnasser@cygnus.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Patch to arm-tdep.c -- Register flavors
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AB0041.9F6A3411@cygnus.com>
X-SW-Source: 2000-q1/msg00202.html
Content-length: 12502
OK, I have got ridden of the ifdef's and renamed ps to cpsr.
I left the default flavor as the ISA one for now. The .gdbinit will
accomodate other preferences.
I will wait for Nick's header file to include the function definitions
before I remove them.
Please see the attached patch (which I am checking in in a few minutes).
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
Index: arm-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/arm-tdep.c,v
retrieving revision 1.1.1.13
diff -c -p -r1.1.1.13 arm-tdep.c
*** arm-tdep.c 2000/02/05 07:29:40 1.1.1.13
--- arm-tdep.c 2000/02/16 19:42:11
***************
*** 30,85 ****
extern void _initialize_arm_tdep (void);
! /*
! The following macros are actually wrong. Neither arm nor thumb can
! or should set the lsb on addr.
! The thumb addresses are mod 2, so (addr & 2) would be a good
heuristic
! to use when checking for thumb (see arm_pc_is_thumb() below).
! Unfortunately, something else depends on these (incorrect) macros,
so
! fixing them actually breaks gdb. I didn't have time to
investigate. Z.R.
! */
! /* Thumb function addresses are odd (bit 0 is set). Here are some
! macros to test, set, or clear bit 0 of addresses. */
! #define IS_THUMB_ADDR(addr) ((addr) & 1)
! #define MAKE_THUMB_ADDR(addr) ((addr) | 1)
! #define UNMAKE_THUMB_ADDR(addr) ((addr) & ~1)
! /* Default register names as specified by APCS. */
! static char * atpcs_register_names[] =
! {"a1", "a2", "a3", "a4", /* 0 1 2 3 */
! "v1", "v2", "v3", "v4", /* 4 5 6 7 */
! "v5", "v6", "v7", "v8", /* 8 9 10 11 */
! "IP", "SP", "LR", "PC", /* 12 13 14 15 */
! "f0", "f1", "f2", "f3", /* 16 17 18 19 */
! "f4", "f5", "f6", "f7", /* 20 21 22 23 */
! "FPS", "PS" }; /* 24 25 */
! /* Alternate set of registers names used by GCC. */
! static char * additional_register_names[] =
{"r0", "r1", "r2", "r3", /* 0 1 2 3 */
"r4", "r5", "r6", "r7", /* 4 5 6 7 */
"r8", "r9", "r10", "r11", /* 8 9 10 11 */
"r12", "sp", "lr", "pc", /* 12 13 14 15 */
"f0", "f1", "f2", "f3", /* 16 17 18 19 */
"f4", "f5", "f6", "f7", /* 20 21 22 23 */
! "fps", "ps" }; /* 24 25 */
! /* This is the variable that is set with "set disassembly-flavor".
! By default use the APCS registers names. */
! char ** arm_register_names = atpcs_register_names;
!
! /* Valid register name flavours. */
! static char apcs_flavor[] = "apcs";
! static char r_prefix_flavor[] = "r-prefix";
! static char * valid_flavors[] =
! {
! apcs_flavor,
! r_prefix_flavor,
! NULL
! };
! /* Disassembly flavor to use. */
! static char *disassembly_flavor = apcs_flavor;
/* This is used to keep the bfd arch_info in sync with the disassembly
flavor. */
--- 30,70 ----
extern void _initialize_arm_tdep (void);
! /* From opcodes/arm-dis.c */
!
! extern int get_arm_regname_num_options (void);
!
! extern int set_arm_regname_option (int option);
! extern int get_arm_regnames (int option, const char **setname,
! const char **setdescription,
! const char ***regnames);
! /* Number of different reg name sets (options). */
! static int num_flavor_options;
!
! /* We have more registers than the disassembler as gdb can print the
value
! of special registers as well.
! The general register names are overwritten by whatever is being
used by
! the disassembler at the moment. We also adjust the case of cpsr and
fps. */
!
! /* Initial value: Register names used in ARM's ISA documentation. */
! static char * arm_register_name_strings[] =
{"r0", "r1", "r2", "r3", /* 0 1 2 3 */
"r4", "r5", "r6", "r7", /* 4 5 6 7 */
"r8", "r9", "r10", "r11", /* 8 9 10 11 */
"r12", "sp", "lr", "pc", /* 12 13 14 15 */
"f0", "f1", "f2", "f3", /* 16 17 18 19 */
"f4", "f5", "f6", "f7", /* 20 21 22 23 */
! "fps", "cpsr" }; /* 24 25 */
! char **arm_register_names = arm_register_name_strings;
! /* Valid register name flavors. */
! static char **valid_flavors;
! /* Disassembly flavor to use. Default to "std" register names. */
! static char *disassembly_flavor;
! static int current_option; /* Index to that option in the opcodes
table. */
/* This is used to keep the bfd arch_info in sync with the disassembly
flavor. */
*************** struct frame_extra_info
*** 103,108 ****
--- 88,99 ----
int framereg;
};
+ /* Addresses for calling Thumb functions have the bit 0 set.
+ Here are some macros to test, set, or clear bit 0 of addresses. */
+ #define IS_THUMB_ADDR(addr) ((addr) & 1)
+ #define MAKE_THUMB_ADDR(addr) ((addr) | 1)
+ #define UNMAKE_THUMB_ADDR(addr) ((addr) & ~1)
+
#define SWAP_TARGET_AND_HOST(buffer,len)
\
do
\
{
\
*************** arm_float_info (void)
*** 1388,1439 ****
print_fpu_flags (status);
}
- /* If the disassembly mode is APCS, we have to also switch the
- bfd mach_type. This function is run in the set disassembly_flavor
- command, and does that. */
-
- static void
- set_disassembly_flavor_sfunc (char *args, int from_tty,
- struct cmd_list_element *c)
- {
- set_disassembly_flavor ();
- }
-
- static void
- set_disassembly_flavor (void)
- {
- if (disassembly_flavor == apcs_flavor)
- {
- parse_arm_disassembler_option ("reg-names-atpcs");
- arm_register_names = atpcs_register_names;
- }
- else if (disassembly_flavor == r_prefix_flavor)
- {
- parse_arm_disassembler_option ("reg-names-std");
- arm_register_names = additional_register_names;
- }
- }
-
- /* arm_othernames implements the "othernames" command. This is kind
- of hacky, and I prefer the set-show disassembly-flavor which is
- also used for the x86 gdb. I will keep this around, however, in
- case anyone is actually using it. */
-
- static void
- arm_othernames (char *names, int n)
- {
- if (disassembly_flavor == r_prefix_flavor)
- {
- disassembly_flavor = apcs_flavor;
- set_disassembly_flavor ();
- }
- else
- {
- disassembly_flavor = r_prefix_flavor;
- set_disassembly_flavor ();
- }
- }
-
#if 0
/* FIXME: The generated assembler works but sucks. Instead of using
r0, r1 it pushes them on the stack, then loads them into r3, r4 and
--- 1379,1384 ----
*************** arm_skip_stub (CORE_ADDR pc)
*** 2033,2061 ****
return 0; /* not a stub */
}
void
_initialize_arm_tdep (void)
{
struct cmd_list_element *new_cmd;
tm_print_insn = gdb_print_insn_arm;
! /* Sync the opcode insn printer with our register viewer: */
! parse_arm_disassembler_option ("reg-names-atpcs");
! /* Add the deprecated "othernames" command */
! add_com ("othernames", class_obscure, arm_othernames,
! "Switch to the other set of register names.");
/* Add the disassembly-flavor command */
-
new_cmd = add_set_enum_cmd ("disassembly-flavor", no_class,
valid_flavors,
(char *) &disassembly_flavor,
! "Set the disassembly flavor, \
! the valid values are \"apcs\" and \"r-prefix\", \
! and the default value is \"apcs\".",
&setlist);
new_cmd->function.sfunc = set_disassembly_flavor_sfunc;
add_show_from_set (new_cmd, &showlist);
--- 1978,2098 ----
return 0; /* not a stub */
}
+ /* If the user changes the register disassembly flavor used for info
register
+ and other commands, we have to also switch the flavor used in
opcodes
+ for disassembly output.
+ This function is run in the set disassembly_flavor command, and
does that. */
+
+ static void
+ set_disassembly_flavor_sfunc (char *args, int from_tty,
+ struct cmd_list_element *c)
+ {
+ set_disassembly_flavor ();
+ }
+
+ static void
+ set_disassembly_flavor (void)
+ {
+ const char *setname, *setdesc, **regnames;
+ int numregs, j;
+
+ /* Find the flavor that the user wants in the opcodes table. */
+ int current = 0;
+ numregs = get_arm_regnames (current, &setname, &setdesc, ®names);
+ while ((disassembly_flavor != setname)
+ && (current < num_flavor_options))
+ get_arm_regnames (++current, &setname, &setdesc, ®names);
+ current_option = current;
+
+ /* Fill our copy. */
+ for (j = 0; j < numregs; j++)
+ arm_register_names[j] = (char *) regnames[j];
+
+ /* Adjust case. */
+ if (isupper (*regnames[PC_REGNUM]))
+ {
+ arm_register_names[FPS_REGNUM] = "FPS";
+ arm_register_names[PS_REGNUM] = "CPSR";
+ }
+ else
+ {
+ arm_register_names[FPS_REGNUM] = "fps";
+ arm_register_names[PS_REGNUM] = "cpsr";
+ }
+
+ /* Synchronize the disassembler. */
+ set_arm_regname_option (current);
+ }
+
+ /* arm_othernames implements the "othernames" command. This is kind
+ of hacky, and I prefer the set-show disassembly-flavor which is
+ also used for the x86 gdb. I will keep this around, however, in
+ case anyone is actually using it. */
+
+ static void
+ arm_othernames (char *names, int n)
+ {
+ /* Circle through the various flavors. */
+ current_option = (current_option + 1) % num_flavor_options;
+
+ disassembly_flavor = valid_flavors[current_option];
+ set_disassembly_flavor ();
+ }
+
void
_initialize_arm_tdep (void)
{
+ struct ui_file *stb;
+ long length;
struct cmd_list_element *new_cmd;
+ const char *setname, *setdesc, **regnames;
+ int numregs, i, j;
+ static char *helptext;
tm_print_insn = gdb_print_insn_arm;
! /* Get the number of possible sets of register names defined in
opcodes. */
! num_flavor_options = get_arm_regname_num_options ();
! /* Sync the opcode insn printer with our register viewer: */
! parse_arm_disassembler_option ("reg-names-std");
! /* Begin creating the help text. */
! stb = mem_fileopen ();
! fprintf_unfiltered (stb, "Set the disassembly flavor.\n\
! The valid values are:\n");
!
! /* Initialize the array that will be passed to add_set_enum_cmd().
*/
! valid_flavors = xmalloc ((num_flavor_options + 1) * sizeof (char
*));
! for (i = 0; i < num_flavor_options; i++)
! {
! numregs = get_arm_regnames (i, &setname, &setdesc, ®names);
! valid_flavors[i] = (char *) setname;
! fprintf_unfiltered (stb, "%s - %s\n", setname,
! setdesc);
! /* Copy the default names (if found) and synchronize
disassembler. */
! if (!strcmp (setname, "std"))
! {
! disassembly_flavor = (char *) setname;
! current_option = i;
! for (j = 0; j < numregs; j++)
! arm_register_names[j] = (char *) regnames[j];
! set_arm_regname_option (i);
! }
! }
! /* Mark the end of valid options. */
! valid_flavors[num_flavor_options] = NULL;
!
! /* Finish the creation of the help text. */
! fprintf_unfiltered (stb, "The default is \"std\".");
! helptext = ui_file_xstrdup (stb, &length);
! ui_file_delete (stb);
/* Add the disassembly-flavor command */
new_cmd = add_set_enum_cmd ("disassembly-flavor", no_class,
valid_flavors,
(char *) &disassembly_flavor,
! helptext,
&setlist);
new_cmd->function.sfunc = set_disassembly_flavor_sfunc;
add_show_from_set (new_cmd, &showlist);
*************** and the default value is \"apcs\".",
*** 2066,2071 ****
--- 2103,2112 ----
"Set usage of ARM 32-bit mode.\n",
&setlist),
&showlist);
+ /* Add the deprecated "othernames" command */
+
+ add_com ("othernames", class_obscure, arm_othernames,
+ "Switch to the next set of register names.");
}
/* Test whether the coff symbol specific value corresponds to a Thumb
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: Prologue cache fix
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BB65F6.44D991A2@cygnus.com>
References: <38B4073E.281C4CE0@redhat.com>
X-SW-Source: 2000-q1/msg00414.html
Content-length: 1434
Fernando Nasser wrote:
>
> This patch fixes a problem that happens when gdb reconnects to a
> target. Targets that have a prologue cache must invalidate its contents
> or they can assume wrong things based on stale data.
I'm wondering when exactly this prologue_cache provides real benefit?
If the prologue_cache is purged at the same time as the frame obstack
then the two have the same lifetime. If that is the case then I think
that the prologue analysis might as well be left in the frame object in
``struct frame_extra_info''.
The only other possibility I can think of is is something like an
inferior function call where GDB comes back to that exact same address.
For a recursive call, the register info would be wrong.
So anyone enlighten me as to when exactly this thing kicks in? :-)
> 2000-02-23 Fernando Nasser <fnasser@totem.to.cygnus.com>
>
> * gdbint.texinfo: Add entry for target dependent macro
> FLUSH_PROLOGUE_CACHE.
> *** blockframe.c 1999/12/22 21:45:03 1.1.1.11
> --- blockframe.c 2000/02/23 00:17:15
> *************** flush_cached_frames ()
> *** 269,274 ****
> --- 269,277 ----
>
> current_frame = NULL; /* Invalidate cache */
> select_frame (NULL, -1);
> + #ifdef FLUSH_PROLOGUE_CACHE
> + FLUSH_PROLOGUE_CACHE ();
> + #endif
> annotate_frames_invalid ();
> }
>
As an asside, this won't work well with multi-arch.
enjoy,
Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [RFC] Notes on QUIT and STREQ et.al.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38CCC819.1071F28E@cygnus.com>
X-SW-Source: 2000-q1/msg00667.html
Content-length: 1709
The attatched spells out the long term prospects of both STREQ et.al.
and QUIT.
Look OK to everyone?
Andrew
Mon Mar 13 21:21:41 2000 Andrew Cagney <cagney@b1.cygnus.com>
* defs.h (STREQ): Note that the STR* macros do not need to be
used.
(QUIT): Note that this can probably be replaced by a function.
Index: defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.11
diff -p -r1.11 defs.h
*** defs.h 2000/03/13 07:30:00 1.11
--- defs.h 2000/03/13 10:24:00
*************** extern int core_addr_greaterthan (CORE_A
*** 120,125 ****
--- 120,130 ----
/* Gdb does *lots* of string compares. Use macros to speed them up by
avoiding function calls if the first characters are not the same. */
+ /* NOTE: cagney/2000-03-13: There is no reason for using these macros
+ in new code (which is just short of marking them as deprecated).
+ While old code can continue to refer to them, new code is better
+ off using the more familar strcmp(). */
+
#define STRCMP(a,b) (*(a) == *(b) ? strcmp ((a), (b)) : (int)*(a) - (int)*(b))
#define STREQ(a,b) (*(a) == *(b) ? !strcmp ((a), (b)) : 0)
#define STREQN(a,b,c) (*(a) == *(b) ? !strncmp ((a), (b), (c)) : 0)
*************** extern int immediate_quit;
*** 152,157 ****
--- 157,167 ----
extern int sevenbit_strings;
extern void quit (void);
+
+ /* FIXME: cagney/2000-03-13: It has been suggested that the peformance
+ benefits of having a ``QUIT'' macro rather than a function are
+ marginal. Before QUIT can be replaced by a function, a profile
+ confirming this, would be needed. */
#ifdef QUIT
/* do twice to force compiler warning */
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: dlclose()
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <b7lfzhkj6.fsf@rtl.cygnus.com>
References: <200002161953.OAA07411@devserv.devel.redhat.com> <200002200521.AAA29598@devserv.devel.redhat.com> <88nurn$e4d$1@cronkite.cygnus.com>
X-SW-Source: 2000-q1/msg00253.html
Content-length: 1193
> Am I mistaken in the observation that people rarely post test suite
> results when they submit patches?
Well, solib.exp only runs on HPUX and if there are other shared
library tests, I didn't see them.
I'd probably argue that the distributed testing resulting from getting
patches checked in is more effective QA than getting obsessed with
testsuites but that isn't really the point in the sense that I'd like
to see both. On the testsuite side, I'm looking into the weird.exp
failures - what I've seen so far as that it has nothing to do with
relocations (at least not on my Red Hat Linux 6.1 system), that it has
nothing to do with how the stabs are laid out (they are correct), but
it has to do with C++ code which applies the baseclass offset twice,
thus pointing the wrong place. The two places in question are:
cp-valprint.c:572
if (target_read_memory (address + boffset, base_valaddr,
TYPE_LENGTH (baseclass)) != 0)
cp-valprint.c:599
cp_print_value_fields (baseclass, real_type, base_valaddr, offset + boffset, address,
stream, format, recurse, pretty,
(struct type **) obstack_base (&dont_print_vb_obstack),
0);
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: green@redhat.com
Cc: jimb@cygnus.com, tromey@cygnus.com
Subject: Re: Patch: handle N_MAIN stab
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bsny4jbs3.fsf@rtl.cygnus.com>
References: <200003051039.CAA04980@hoser.cygnus.com>
X-SW-Source: 2000-q1/msg00533.html
Content-length: 1060
> Gdb currently ignores N_MAIN. The following patch is an attempt to
> make it understand N_MAIN.
I looked over that patch and the basic concept looks fine. N_MAIN is
already documented in doc/stabs.texinfo.
The patch does leak memory every time symbols are reloaded, though (a
bad thing in and of itself and also a hassle is using memory leak
detecting programs). And probably has subtler bugs if one has a
symbol file with N_MAIN and then replaces it with a symbol file with
"main" and without N_MAIN. I'm not sure exactly what rule to follow
but probably something like:
* N_MAIN takes precedence over "main" no matter what objfile it is in
* If there is more than one N_MAIN, choose the one in the
symfile_objfile
* If there is more than one N_MAIN within a given objfile, complain()
and choose arbitrarily.
I have no particularly strong objection if the maintainer (JimB, looks
like) wants to relegate the above to FIXME comments or something, but
I guess if you want my advice, it should be fairly easy to fix at
least the memory leak now.
From taylor@cygnus.com Sat Apr 01 00:00:00 2000
From: David Taylor <taylor@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: utils.c changes for converting to/from DOUBLEST
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001242202.RAA27801@texas.cygnus.com>
X-SW-Source: 2000-q1/msg00031.html
Content-length: 40
Sorry for the delay. This is approved.
From john@feith.com Sat Apr 01 00:00:00 2000
From: John Wehle <john@feith.com>
To: eliz@delorie.com
Cc: jimb@zwingli.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: GDB 4.17 Patch for stack aligned i386 code
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003242200.RAA13376@jwlab.FEITH.COM>
X-SW-Source: 2000-q1/msg01001.html
Content-length: 3601
> Is it possible to tell a bit more about the problem, and how is it
> solved?
It's desirable to omit the frame pointer when compiling leaf functions
when targeting the x86 processor as this provides another hard register
(%ebp) which can be used by the register allocators. Using
-momit-leaf-frame-pointer instructs GCC to compile code in this manner.
Unfortunately GDB has a rather strong belief that %ebp always points to
the frame and is unable to locate function arguments or local variables
when the frame pointer is omitted. The changes allow GDB to locate the
frame based on the value in %esp.
> Perhaps even a short test case, before and after the change?
An example is backtracing through sigtramps on Solaris (the Solaris library
contains functions which don't use %ebp as the frame pointer). For example
... the backtrace from gdb.base/a1-selftest.exp (without my patch) shows:
#0 0x80068745 in _libc_sigprocmask ()
#1 0x80098763 in sigprocmask ()
#2 0x8107cb3 in rl_signal_handler (sig=134509072) at signals.c:156
#3 0x800685b1 in _sigacthandler ()
#4 <signal handler called>
#5 0x800682b8 in _libc_read ()
#6 0x8101ef9 in rl_getc (stream=0x800a9ad4) at readline.c:3123
#7 0x80ffa5b in rl_read_key () at readline.c:578
The correct backtrace is:
#0 0x80068745 in _libc_sigprocmask ()
#1 0x80098763 in sigprocmask ()
#2 0x8107fe7 in rl_signal_handler (sig=134509096) at signals.c:156
#3 0x800685b1 in _sigacthandler ()
#4 <signal handler called>
#5 0x800682b8 in _libc_read ()
#6 0x80098b33 in read ()
#7 0x810222d in rl_getc (stream=0x81639a0) at readline.c:3123
#8 0x80ffd8f in rl_read_key () at readline.c:578
> Also, do the original problems affect Solaris alone, or are they
> common to all gcc/x86-based architectures?
They're common to all gcc/x86-based architectures.
> It's quite difficult to judge a large patch for two different problems
> without having a more-or-less clear notion of the issues involved.
Actually they're slight variations of same problem which is how to locate
the frame. The GDB patch in question supports locating the frame for x86
code:
1) In a leaf function where the frame pointer has been omitted. GCC
currently supports generating this if -momit-leaf-frame-pointer is
specified. It's desirable to make this the default once debugging
support is in place.
2) In a function where the frame pointer has been omitted and the stack
pointer is unchanging. For example:
int global;
void
unchanging_sp(int a, int b)
{
global = a + b;
print_global();
}
I have a patch for GCC to support omitting the frame pointer in this
case which has been delayed pending debugger support. It's desirable
to also have this as part of the default x86 code generation strategy.
3) In a function where "andl" has been used to align the frame. I have
an experimental patch for GCC to support aligning the frame in this
fashion in order to improve x86 floating point performance.
The original GDB work was done in November 1998 and January 1999. I'd be
happy to dust things off on my side in order to get these changes installed
if you're interested in working with me. BTW, the necessary paperwork
is already on file.
-- John
-------------------------------------------------------------------------
| Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com |
| John Wehle | Fax: 1-215-540-5495 | |
-------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH]: add set/show debug, move gdb debugging flags into it
2000-03-13 9:04 [PATCH]: add set/show debug, move gdb debugging flags into it Daniel Berlin
@ 2000-04-01 0:00 ` Fernando Nasser
[not found] ` <200003150919.EAA29966@indy.delorie.com>
1 sibling, 0 replies; 4+ messages in thread
From: Fernando Nasser @ 2000-04-01 0:00 UTC (permalink / raw)
To: Daniel Berlin; +Cc: gdb-patches
Daniel,
Your patch is something we've been looking forward to. In the perspective of the CLI (which I am the maintainer) I am
eager to see it checked in. It touches other files though, so I would rather wait for Andrew to see them overnight (his
day).
However... your patch is removing the old command formats. I have not yet checked in David Whedon patch for
deprecating commands (I've been *real* busy these days) so we can't use it yet.
This leaves us with two choices: we wait a week or so and use David deprecating thing, or just leave the old commands
alive for now. In either case you would have to adjust your patch, I hope you don't mind.
Thank you very much for doing this. This "set xyxsdert$#@%$debug" commands were really weird.
Best regards,
Fernando
Daniel Berlin wrote:
>
> Attached is a patch to add "set debug" and "show debug", and move the gdb
> debugging stuff (targetdebug,expressiondebug,etc) into those lists.
>
> I renamed targetdebug,expressiondebug,etc (all the debug settings i
> moved), to remove the "debug" from their name, so you do "set debug target
> 1" rather than "set debug targetdebug 1".
>
> The new command lists are named setdebuglist/showdebuglist, and are in
> command.c.
> I put set_debug and show_debug into command.c, for lack of a better place.
> The point of all this is to make it much easier to see what debugging
> flags you can set for GDB, and what they were set to. It also declutters
> the set list.
> I also enabled monitordebug, since it said int he comment it was waiting
> for "set debug".
>
> I have no idea who needs to approve this, since it touches a bunch of
> stuff, but is only related to one domain so to speak.
>
> I'm working on a changelog entry, i wanted to get comments first.
>
> Example of what you get with the patch installed:
> (gdb) help set debug
> Generic command for setting gdb debugging flags
> List of set debug subcommands:
> set debug arch -- Set architecture debugging
> set debug event -- Set event debugging
> set debug expression -- Set expression debugging
> set debug remote -- Set debugging of remote protocol
> set debug serial -- Set serial debugging
> set debug target -- Set target debugging
> set debug varobj -- Set varobj debugging
> Type "help set debug" followed by set debug subcommand name for full
> documentation.
> Command name abbreviations are allowed if unambiguous.
> (gdb)
>
> (gdb) help show debug
> Generic command for showing gdb debugging flags
> List of show debug subcommands:
> show debug arch -- Show architecture debugging
> show debug event -- Show event debugging
> show debug expression -- Show expression debugging
> show debug remote -- Show debugging of remote protocol
> show debug serial -- Show serial debugging
> show debug target -- Show target debugging
> show debug varobj -- Show varobj debugging
> Type "help show debug" followed by show debug subcommand name for full
> documenta
> tion.
> Command name abbreviations are allowed if unambiguous.
> (gdb)
> (gdb) show debug
> arch: Architecture debugging is 0.
> event: Event debugging is 0.
> expression: Expression debugging is 0.
> remote: Debugging of remote protocol is 0.
> serial: Serial debugging is 0.
> target: Target debugging is 0.
> varobj: Varobj debugging is 0.
> (gdb) set debug
> "set debug" must be followed by the name of a print subcommand.
> List of set debug subcommands:
> set debug arch -- Set architecture debugging
> set debug event -- Set event debugging
> set debug expression -- Set expression debugging
> set debug remote -- Set debugging of remote protocol
> set debug serial -- Set serial debugging
> set debug target -- Set target debugging
> set debug varobj -- Set varobj debugging
> Type "help set debug" followed by set debug subcommand name for full
> documentati
> on.
> Command name abbreviations are allowed if unambiguous.
> (gdb)
>
> ------------------------------------------------------------------------------------------------------------------------
> Name: setdebug.diff
> setdebug.diff Type: Plain Text (TEXT/PLAIN)
> Encoding: BASE64
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFC] Notes on QUIT and STREQ et.al.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38CD7F9E.206D9351@cygnus.com>
References: <200003131412.PAA16094@landau.wins.uva.nl> <b4saaq07p.fsf@rtl.cygnus.com>
X-SW-Source: 2000-q1/msg00678.html
Content-length: 938
Jim Kingdon wrote:
> > I'm not sure if we want STREQ to go. I think that `STREQ (a, b)' is
> > both easier to read and easier to type than `strcmp (a, b) == 0'.
>
> Well, perhaps it is because I have gotten used to the strcmp == 0
> idiom, but I find it to be pretty annoying to have to look up a macro
> like this (sure, it _probably_ is defined in the obvious way, but you
> don't know that for sure when digging into a new program). Granted
> strcmp == 0 is hard to understand until/unless you know the standard C
> library well enough for it to be second nature.
Well I personally prefer the forms:
strcmp() == 0 (read: strcmp () equal)
and strcmp() != 0 (read: strcmp () not-equal)
over ``strcmp()'' and ``!strcmp()'' as they offer a queue to the
programer but even then that style isn't a requirement.
Like you, the one I don't trust is STREQ(). I'm never 100% certain what
that macro is doing behind my back :-)
Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Please ``withdraw'' patches
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BB29FF.2467FCE@cygnus.com>
X-SW-Source: 2000-q1/msg00410.html
Content-length: 449
Hello,
I've just spent an hour going over a patch (yes I'm working through a
long backlog) only to then find a later submission by the same author
supersedes the earlier posting.
If people withdraw or re-submit patches, could they please to a follow
up to the original posting making it clear that that submission was
withdrawn.
enjoy,
Andrew
(Hopefully a patch tracking system will help with this problem (although
it may not eliminate it))
From fnasser@cygnus.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: glen mccready <gkm@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFA] gdb/command.c, gdb/command.h: "help all"
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DBB714.67024F64@cygnus.com>
References: <200003241731.JAA12735@cygint.cygnus.com> <8bg9c0$3rt$1@cronkite.cygnus.com>
X-SW-Source: 2000-q1/msg00991.html
Content-length: 1267
glen mccready wrote:
>
> I will get better at this, I'm sure. :-/
>
That is fine. There are lots of common practices that are not written anywhere, so you post and we tell you. After a
short while you'll know them all and will be your turn to tell others...
> In article < 200003241731.JAA12735@cygint.cygnus.com >,
> glen mccready <gkm@cygnus.com> wrote:
> [...]
> >Fri Mar 24 12:10:38 2000 glen mccready <gkm@pobox.com>
> >
> > * commands.c (help_all): Add functionality to display a complete
> > listing of available commands.
>
> Fri Mar 24 12:10:38 2000 glen mccready <gkm@pobox.com>
>
> * command.c, command.h (help_all): Add functionality to display
> a complete listing of available commands.
Better yet:
Fri Mar 24 12:10:38 2000 glen mccready <gkm@pobox.com>
* command.c (help_all): New function. Add functionality
to display a complete listing of available commands.
* command.h: Add declaration for the above.
If nobody objects by the end of the afternoon, please check it in.
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From fnasser@cygnus.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: gdb-patches@sourceware.cygnus.com, James Ingham <jingham@cygnus.com>
Subject: RFC: Patch to make "set remotebaud" and "-b" work for RDI targets
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <3873D9FC.EF374435@cygnus.com>
X-SW-Source: 2000-q1/msg00012.html
Content-length: 1412
The baud specified on the target command itself takes precedence, but if
it has not been specified and gdb was invoked with a "-b" argument or
the user (or Insight) have issued a "set remotebaud" command, that
valued is tried (comapared against the list of valid values kept by the
rdi code).
--
Fernando Nasser
Cygnus Solutions - Toronto Office E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
Index: rdi-share/serdrv.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/rdi-share/serdrv.c,v
retrieving revision 1.4
diff -c -r1.4 serdrv.c
*** serdrv.c 1999/01/28 03:50:16 1.4
--- serdrv.c 2000/01/05 23:45:25
***************
*** 32,37 ****
--- 32,39 ----
#include "params.h"
#include "logging.h"
+ extern int baud_rate; /* From gdb/top.c */
+
#ifdef COMPILING_ON_WINDOWS
# undef ERROR
# undef IGNORE
***************
*** 228,233 ****
--- 230,241 ----
else
printf( "could not understand baud rate %s\n", arg );
#endif
+ }
+ else if (baud_rate > 0)
+ {
+ /* If the user specified a baud rate on the command line "-b" or
via
+ the "set remotebaud" command then try to use that one */
+ process_baud_rate( baud_rate );
}
#ifdef COMPILING_ON_WINDOWS
From jlarmour@redhat.co.uk Sat Apr 01 00:00:00 2000
From: Jonathan Larmour <jlarmour@redhat.co.uk>
To: fnasser@redhat.com, gdb-patches@sourceware.cygnus.com
Subject: Re: thumb_skip_prologue too adventurous
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D40052.AF731E81@redhat.co.uk>
References: <38D3FFC8.32082A85@redhat.co.uk>
X-SW-Source: 2000-q1/msg00770.html
Content-length: 1896
Jonathan Larmour wrote:
> 2000-03-18 Jonathan Larmour <jlarmour@redhat.co.uk>
>
> * arm-tdep.c (thumb_skip_prologue): Take function end addr argument
> so that we can stop searching for the prologue past the function end
> (arm_skip_prologue): Call thumb_skip_prologue with function end addr
Doh! Patch attached.
Jifl
Index: arm-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/arm-tdep.c,v
retrieving revision 1.4
diff -u -5 -p -r1.4 arm-tdep.c
--- arm-tdep.c 2000/02/29 07:23:02 1.4
+++ arm-tdep.c 2000/03/18 22:16:21
@@ -326,20 +326,20 @@ arm_frameless_function_invocation (struc
When we have found at least one of each class we are done with the prolog.
Note that the "sub sp, #NN" before the push does not count.
*/
static CORE_ADDR
-thumb_skip_prologue (CORE_ADDR pc)
+thumb_skip_prologue (CORE_ADDR pc, CORE_ADDR func_end)
{
CORE_ADDR current_pc;
int findmask = 0; /* findmask:
bit 0 - push { rlist }
bit 1 - mov r7, sp OR add r7, sp, #imm (setting of r7)
bit 2 - sub sp, #simm OR add sp, #simm (adjusting of sp)
*/
- for (current_pc = pc; current_pc < pc + 40; current_pc += 2)
+ for (current_pc = pc; current_pc + 2 < func_end && current_pc < pc + 40; current_pc += 2)
{
unsigned short insn = read_memory_unsigned_integer (current_pc, 2);
if ((insn & 0xfe00) == 0xb400) /* push { rlist } */
{
@@ -397,11 +397,11 @@ arm_skip_prologue (CORE_ADDR pc)
return sal.end;
}
/* Check if this is Thumb code. */
if (arm_pc_is_thumb (pc))
- return thumb_skip_prologue (pc);
+ return thumb_skip_prologue (pc, func_end);
/* Can't find the prologue end in the symbol table, try it the hard way
by disassembling the instructions. */
skip_pc = pc;
inst = read_memory_integer (skip_pc, 4);
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Comment out longest_raw_hex_string
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bsny6ls1u.fsf@rtl.cygnus.com>
References: <38C0973D.DA06DA51@cygnus.com>
X-SW-Source: 2000-q1/msg00508.html
Content-length: 452
> The attatched comments out the function longest_raw_hex_string(). It
> can be deleted in a month or so (although everyone things it isn't
> used).
Not that it's a big deal, but in case you want my advice, I'd just
delete longest_raw_hex_string now. If there really is some reason to
resurrect it, it is in CVS. <cynical, but based on experience>To
think that the #if 0 code would go away as soon as a month is, er,
optimistic </cynical>.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [MAINT] Minor admin tweeks
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BE0A0E.ED3A565B@cygnus.com>
References: <38BC6514.DC70948@cygnus.com> <b900153hd.fsf@rtl.cygnus.com>
X-SW-Source: 2000-q1/msg00457.html
Content-length: 769
Jim Kingdon wrote:
>
> * MAINTAINERS: Document people with paperwork pending.
>
> Sorry, I'm a bit confused by this one. Did you mean "+" rather than
> "*" for the people you added the symbol to ("*" means that they don't
> have an account, according to the key)?
>
> Philippe De Muyter seems to have the right listing in copyright.html
> (1996-06-12). As does JT Conklin (1998-12-21).
The ChangeLog entry (poorly worded) in combination with the file changes
have thrown a few people.
As you note, the footnotes are:
* Indicates folks we need to get
Kerberos/ssh accounts ready so they
can write in the source tree
+ Indicates folks that have been caught up in a paper trail.
I was refering to the ``account request form'' paperwork.
Andrew
From jason@cygnus.com Sat Apr 01 00:00:00 2000
From: Jason Merrill <jason@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: dwarf2 class handling patch
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <u9ln5uhh9t.fsf@yorick.cygnus.com>
References: <199911240949.BAA18700@yorick.cygnus.com>
X-SW-Source: 2000-q1/msg00015.html
Content-length: 2206
Ping? Without this patch, gdb gets things wrong with the current gcc.
>>>>> Jason Merrill <jason@cygnus.com> writes:
> The dwarf2 spec says that an incomplete type will have AT_declaration set.
> Some changes I'm making to gcc will produce class DIEs with children that
> should still be considered incomplete.
> 1999-11-24 Jason Merrill <jason@casey.cygnus.com>
> * dwarf2read.c (die_is_declaration): New fn.
> (read_structure_scope): Use it.
> Index: dwarf2read.c
> ===================================================================
> RCS file: /cvs/cvsfiles/devo/gdb/dwarf2read.c,v
> retrieving revision 2.33
> diff -c -p -r2.33 dwarf2read.c
> *** dwarf2read.c 1999/10/11 21:17:22 2.33
> --- dwarf2read.c 1999/11/24 09:38:16
> *************** static void set_cu_language PARAMS ((uns
> *** 621,626 ****
> --- 621,628 ----
> static struct attribute *dwarf_attr PARAMS ((struct die_info *,
> unsigned int));
> + static int die_is_declaration PARAMS ((struct die_info *));
> +
> static void dwarf_decode_lines PARAMS ((unsigned int, char *, bfd *));
> static void dwarf2_start_subfile PARAMS ((char *, char *));
> *************** read_structure_scope (die, objfile)
> *** 2202,2208 ****
> type within the structure itself. */
> die->type = type;
> ! if (die->has_children)
> {
> struct field_info fi;
> struct die_info *child_die;
> --- 2204,2210 ----
> type within the structure itself. */
> die->type = type;
> ! if (die->has_children && ! die_is_declaration (die))
> {
> struct field_info fi;
> struct die_info *child_die;
> *************** dwarf_attr (die, name)
> *** 3700,3705 ****
> --- 3702,3715 ----
> return NULL;
> }
> + static int
> + die_is_declaration (die)
> + struct die_info *die;
> + {
> + return (dwarf_attr (die, DW_AT_declaration)
> + && ! dwarf_attr (die, DW_AT_specification));
> + }
> +
> /* Decode the line number information for the compilation unit whose
> line number info is at OFFSET in the .debug_line section.
> The compilation directory of the file is passed in COMP_DIR. */
From davidw@gordian.com Sat Apr 01 00:00:00 2000
From: David Whedon <davidw@gordian.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: Deprecating commands; Was: RFC: patch for ...
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.BSF.3.96.1000216105317.23431r-100000@ares.gordian.com>
X-SW-Source: 2000-q1/msg00196.html
Content-length: 1887
Andrew, Fernando,
I'm happy to volunteer. I've given it a start and I think I know where to
go with it. I'll probably have something by the weekend.
David
Andrew Cagney wrote:
>
> For what its worth,
>
> Something buried on my to-do / wish list is to extend GDB's command
> mechanism so that the user is advised that a command is deprecated the
> first time they use it:
>
> (gdb) othernames xyz
> warning: Command `othernames' is deprecated, use `set
architecture
> abc'.
> (gdb) othernames zzz
> (gdb)
>
> Doing that opens up the possibility of moving GDB's CLI (command line
> interface) forward. One release would have a poorly chosen command
> deprecated. A follow on release could see it (ya!) removed.
>
> I don't think it is reasonable to simply drop a command (no matter what
> the results of a gdb@sourceware straw poll) without some sort of warning
> to the general public.
>
I agree with Andrew. He proposed the "deprecated" mechanism some time
ago and it went on our TODO list. Although I am the maintainer of the
command line interpreter and I agree with this feature, it was not done
because of the major work that we had to do for getting (part of) libgdb
out (and people were claiming for it).
If someone has the time to contribute with a patch we would appreciate.
If not, as soon as possible we will include this "deprecated" state so
we can have a graceful phasing out of "bad" commands.
Talking about "bad" commands, what can be worse that the "set"
overloading? It should only work for gdb control switches. The "set
var" should be name "assign". But who dares to change this after 15+
years...
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2000-04-01 0:00 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-03-13 9:04 [PATCH]: add set/show debug, move gdb debugging flags into it Daniel Berlin
2000-04-01 0:00 ` Fernando Nasser
[not found] ` <200003150919.EAA29966@indy.delorie.com>
[not found] ` <r9dctixc.fsf@dan.resnet.rochester.edu>
[not found] ` <200003151430.JAA01149@indy.delorie.com>
[not found] ` <38CFAE9E.39D1C081@redhat.com>
[not found] ` <38CFB57A.1900@cygnus.com>
2000-04-01 0:00 ` Fernando Nasser
2000-03-15 8:39 ` Fernando Nasser
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox