* Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
[not found] ` <38D7E6BC.79543EBA@worldnet.fr>
@ 2000-03-27 12:23 ` Jim Blandy
[not found] ` <38E06721.6D3A08CD@cygnus.com>
[not found] ` <npem8w42bg.fsf@zwingli.cygnus.com>
1 sibling, 1 reply; 6+ messages in thread
From: Jim Blandy @ 2000-03-27 12:23 UTC (permalink / raw)
To: Stephane Carrez; +Cc: Andrew Cagney, gdb-patches
Hmm.
The only actual use of address_significant_size is in
dwarf2read.c:read_address. That function extracts an address from the
Dwarf 2 data, using the address size given in the Dwarf 2 compilation
unit header. Then, it masks off any bits beyond the size given by
address_significant_size.
According to the comment for address_significant_size, this is
necessary for handling Dwarf 2 data with 64-bit addresses carried in
ELF32 files --- code for a 64-bit processor, linked to run in a 32-bit
address space.
But I don't understand why we're masking those bits off at all.
Suppose we do have 64-bit addresses in the debug info --- shouldn't
all 64 bits be correct? Why should GDB mask them off and make them
zero --- why doesn't GCC or GAS just emit the address correctly in the
first place?
In the absence of further explanation, it looks to me like this code
is an incorrect attempt to compensate for a bug elsewhere in the
toolchain, and address_significant_size should be removed altogether.
Or maybe I'm misunderstanding things. Andrew, as the committer of
this change, can you comment?
Mon Dec 15 11:38:52 1997 Andrew Cagney <cagney@b1.cygnus.com>
* dwarf2read.c: From change proposed by Gavin Koch.
(address_significant_size): New static variable.
(dwarf2_build_psymtabs_hard): Check consistency between
`address_size' and `address_significant_size'.
(read_address): MASK out all but the significant bits, as
determined by `address_significant_size', of any addresses.
(elf-bfd.h): Include.
(dwarf2_build_psymtabs_hard): Set `address_significant_size'
according to the arch_size of the elf object file.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
[not found] ` <38D68C56.856CB00C@worldnet.fr>
@ 2000-04-01 0:00 ` Andrew Cagney
[not found] ` <38D7E6BC.79543EBA@worldnet.fr>
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cagney @ 2000-04-01 0:00 UTC (permalink / raw)
To: Stephane Carrez; +Cc: gdb-patches
Stephane Carrez wrote:
>
> Hi Andrew,
>
> Andrew Cagney wrote:
> >
> > Stephane Carrez wrote:
> > >
> > > Hi!
> > >
> > > One part of the patch for dwarf2 correction with 16-bit target has
> > > been lost. If you are still not convinced by the fix, have a look
> > > at gas/dwarf2dbg.c in out_set_addr() where we obtain the address
> > > size in a good way.
> > >
> > > Can you integrate it?
> >
> > FYI,
> >
> > My reading of the thread from when this patch was last posted is that it
> > wasn't clear that this was a bug and the change was the correct thing to
> > do.
> >
> For me, it's a bug. The address size specified in dwarf2 is 16 and
> because we use arch_size which corresponds to the ELF32/ELF64 size,
> gdb stops reading with an error (dwarf2read.c:983):
>
> if (address_size < address_significant_size)
> {
> error ("Dwarf Error: bad address size (%ld) in compilation unit header (offset 0x%lx +
> 11).",
> (long) cu_header.addr_size,
> (long) (beg_of_comp_unit - dwarf_info_buffer));
>
As far as I know, the dwarf2 and elf information are both ment to be
self contained. There shouldn't be any need to refer to some arbitrary
bfd table to determine what is going on. If the info says that an
address is 16 bits for a given section then it sounds like GDB should
just believe it.
As JimK suggested:
> Or to put it another way, specifically what went wrong on the 68HC11
> if you didn't change dwarf2read.c? If it was just the "Dwarf Error:
> bad address size" error, what happens if you just comment out that
> check?
Rather than diging values out of archures I think the possibility of:
cu_header.address_size < elf-header.address_size
should be documented as being just as legetimate (sarcasm :-) as:
cu_header.address_size > elf-header.address_size
and the check either replaced or removed.
Andrew
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] Another utils.c patch
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000319174817.ZM17637@ocotillo.lan>
References: <1000319072047.ZM14883@ocotillo.lan> <kevinb@cygnus.com>
X-SW-Source: 2000-q1/msg00786.html
Content-length: 2222
On Mar 19, 12:20am, Kevin Buettner wrote:
> Subject: [PATCH RFA] Another utils.c patch
> This fixes another bug uncovered by running the testsuite for the
> IA-64... may I check this one in?
>
> * utils.c (floatformat_from_doublest): Make sure space that we're
> writing the float to is completely initialized to zeroes, even
> when the number of bits in the float is not evenly divisible
> by FLOATFORMAT_CHAR_BIT.
>
> Index: utils.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/utils.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 utils.c
> --- utils.c 2000/03/04 02:23:06 1.4
> +++ utils.c 2000/03/19 07:12:00
> @@ -2722,7 +2722,8 @@ floatformat_from_doublest (fmt, from, to
> unsigned char *uto = (unsigned char *) to;
>
> memcpy (&dfrom, from, sizeof (dfrom));
> - memset (uto, 0, fmt->totalsize / FLOATFORMAT_CHAR_BIT);
> + memset (uto, 0, fmt->totalsize / FLOATFORMAT_CHAR_BIT
> + + ((fmt->totalsize % FLOATFORMAT_CHAR_BIT) == 0 ? 0 : 1));
> if (dfrom == 0)
> return; /* Result is zero */
> if (dfrom != dfrom) /* Result is NaN */
>
>-- End of excerpt from Kevin Buettner
I withdraw the patch above in favor of the one below. (The patch above
is not as concise as the one below. But they should both produce the
same results.)
* utils.c (floatformat_from_doublest): Make sure space that we're
writing the float to is completely initialized to zeroes, even
when the number of bits in the float is not evenly divisible
by FLOATFORMAT_CHAR_BIT.
Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.4
diff -u -p -r1.4 utils.c
--- utils.c 2000/03/04 02:23:06 1.4
+++ utils.c 2000/03/19 17:36:49
@@ -2722,7 +2722,8 @@ floatformat_from_doublest (fmt, from, to
unsigned char *uto = (unsigned char *) to;
memcpy (&dfrom, from, sizeof (dfrom));
- memset (uto, 0, fmt->totalsize / FLOATFORMAT_CHAR_BIT);
+ memset (uto, 0, (fmt->totalsize + FLOATFORMAT_CHAR_BIT - 1)
+ / FLOATFORMAT_CHAR_BIT);
if (dfrom == 0)
return; /* Result is zero */
if (dfrom != dfrom) /* Result is NaN */
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
[not found] ` <npem8w42bg.fsf@zwingli.cygnus.com>
@ 2000-04-01 0:00 ` Fernando Nasser
0 siblings, 0 replies; 6+ messages in thread
From: Fernando Nasser @ 2000-04-01 0:00 UTC (permalink / raw)
To: Jim Blandy; +Cc: Stephane Carrez, Andrew Cagney, gdb-patches
Jim Blandy wrote:
>
> I've reached the same conclusion on a project I'm doing right now. I
> think this test is bogus.
>
It seems that we have a consensus.
Jim, will you do the honors and get Stephane patch in (thus removing the offending test)?
--
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 dan@cgsoftware.com Sat Apr 01 00:00:00 2000
From: dan@cgsoftware.com (Daniel Berlin)
To: gdb-patches@sourceware.cygnus.com
Subject: [RFA] Demangled minsym hash table broken
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <pusd46y7.fsf@dan.resnet.rochester.edu>
X-SW-Source: 2000-q1/msg01115.html
Content-length: 839
I was trying to debug a bug report, and in the process, noticed that
the demangled minsym hash table is broken (I noticed because we
weren't finding a symbol we should have been able to find).
Since add_minsym_to_hashtable only uses minsym_hash, and the code
adding to the demangled minsym hashtable is using that function, the
symbols never get the right hash value, because they need to use
minsym_hash_iw.
The lookups properly use that function.
My fix is to add an extra parameter to add_minsym_to_hashtable so we
can tell the function whether we are adding a mangled or demangled
symbol, and thus, it can pick the right bucket.
Also, i made it set the proper next as well (we need to set
sym->demangled_hash_next if it's a demangled symbol).
So up until now, the demangled symbol table was never working, as i
had suspected.
--Dan
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Document the ThreadInfo remote protocol queries
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D85C2F.FF89881D@cygnus.com>
References: <200003202316.PAA07888@cleaver.cygnus.com> <38D6FCE2.EBD9830F@cygnus.com> <38D7C38C.6CB0@cygnus.com>
X-SW-Source: 2000-q1/msg00896.html
Content-length: 2117
Michael Snyder wrote:
> > An additional note on these versions of thread queries. While
> > significantly better than the ``qL'' packet these commands still have
> > problems. I'll add notes expanding on this. Briefly, however:
> >
> > o Per the query packet spec, they should be
> > prefixed with a UCASE letter if they
> > are to be official GDB packets.
> >
> > o The ``sThread..'' command assumes
> > that the GDB protocol is reliable
> > which it is not. GDB can re-issue
> > a ``sThread'' request and this can
> > lead to GDB and the target falling
> > out of sync.
>
> How about if the 'sThread' request were to be suffixed with
> the last thread ID received?
I was thinking of deprecating fThreadInfo and sThreadInfo and having gdb
try:
qThreadInfo
qThreadInfo,<sentinal>
Where sentinal could be <last-thread-id> index (counting from zero) for
next threads, or anything else.
Given ``sThreadInfo'' is in the field, we can't change it.
> > with regard to ``qfThreadExtraInfo''. As far as I know its not been
> > deployed in the field. Is there any reason to not name it correctly
> > from the start (``qThreadExtraInfo'')?
>
> Only that it conflicts with the tracepoint messages,
> which all begin with qT (see tracepoint.c).
I don't think that is a problem. The protocol requires:
@tab @code{q}@var{query}
@tab
Request info about @var{query}. In general @value{GDBN} @var{query}'s
have a leading upper case letter. Custom vendor queries should use a
company prefix (in lower case) ex: @samp{qfsf.var}. @var{query} may
optionally be followed by a @samp{,} or @samp{;} separated list. Stubs
must ensure that they match the full @var{query} name.
The last sentence is ment to ensure that the target's query handling
code matches using something like:
strcmp (packet, "qThreadInfo")
instead of
packet[0] == 'q' && packet[1] == 'T' && packet[7] == 'I'
Should ``C'' also be suceeded by something like ``qThread''? Is ``C''
still used?
Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: list which remote protocol commands are required
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D6F87E.9EE3E726@cygnus.com>
References: <5md7opufwl.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00844.html
Content-length: 543
"J.T. Conklin" wrote:
>
> I submit the enclosed patch for approval. The existing documentation
> labled some remote protocol commands as optional, while in fact most
> commands are. This patch removes the "optional" tag from the table
> of commands, and explicitly lists the required commands.
It's fine from my end. Stan?
As an asside (again, Hi Stan :-). There was once put forward a proposal
to move the protocol definition (an internal interface that the embedded
user needs to know about) into its own chapter. Thoughts?
Andrew
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Andrew Hobson <ahobson@eng.mindspring.net>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: PATCH for alphaev56-dec-osf5.0: MERGEPID undefined
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A2DA3F.649E@cygnus.com>
References: <kjvh3yxd4l.fsf@gamma.eng.mindspring.net>
X-SW-Source: 2000-q1/msg00112.html
Content-length: 1484
Yes, this is good. Can someone who's working today check it
in? Andrew? JimB?
Thanks,
Michael
Andrew Hobson wrote:
>
> I checked out gdb 5.0 from CVS today and found a minor compilation
> issue. In procfs.c, I find:
>
> /* Provide default composite pid manipulation macros for systems that
> don't have threads. */
>
> #ifndef PIDGET
> #define PIDGET(PID) (PID)
> #define TIDGET(PID) (PID)
> #define MERGEPID(PID, TID) (PID)
> #endif
>
> ... but in defs.h I find:
>
> /* On some systems, PIDGET is defined to extract the inferior pid from
> an internal pid that has the thread id and pid in seperate bit
> fields. If not defined, then just use the entire internal pid as
> the actual pid. */
>
> #ifndef PIDGET
> #define PIDGET(PID) (PID)
> #define TIDGET(PID) 0
> #endif
>
> That leaves MERGEPID undefined. I'm not positive of the correct fix,
> but the following patch solves the problem for me.
>
> Drew
>
> Index: defs.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/defs.h,v
> retrieving revision 1.1.1.31
> diff -u -p -r1.1.1.31 defs.h
> --- defs.h 2000/02/05 07:29:41 1.1.1.31
> +++ defs.h 2000/02/09 20:52:56
> @@ -1218,6 +1218,7 @@ extern int use_windows;
> #ifndef PIDGET
> #define PIDGET(PID) (PID)
> #define TIDGET(PID) 0
> +#define MERGEPID(PID, TID) (PID)
> #endif
>
> /* If under Cygwin, provide backwards compatibility with older
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: [MAINT] J.T. NetBSD maintainer
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DE9D40.D6CD27B4@cygnus.com>
X-SW-Source: 2000-q1/msg01039.html
Content-length: 100
FYI,
I've put J.T. down as the NetBSD maintainer.
NetBSD J.T. Conklin jtc@redback.com
Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: BINUTILS Patches <binutils@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [PATCH-DEJAGNU] Force DMAP2 register when running d10v tests
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38ABC120.2BF81A6F@cygnus.com>
X-SW-Source: 2000-q1/msg00219.html
Content-length: 924
Hello,
I don't see anyone objecting to the test. I'm just what the commit
policy for this part of the repository is.
enjoy,
Andrew
Thu Feb 17 20:24:21 2000 Andrew Cagney <cagney@b1.cygnus.com>
* baseboards/d10v.exp (gdb_init_command): Force register DMAP2 to
0x2000 so that the d10v VM matches the simulator.
Index: baseboards/d10v.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/dejagnu/baseboards/d10v.exp,v
retrieving revision 1.12
diff -p -r1.12 d10v.exp
*** d10v.exp 1999/09/15 20:49:56 1.12
--- d10v.exp 2000/02/17 09:30:06
*************** set_board_info gcc,no_label_values 1
*** 54,56 ****
--- 54,60 ----
# sizeof int != sizeof long.
set_board_info gdb,short_int 1
+
+ # Some d10v:ts3 boards are in ts2-board compatibility mode after a reset.
+ # Force it into d10v:ts3 internal mode
+ set_board_info gdb_init_command "set \$dmap2 = 0x2000"
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Shared library fixes for GNU/Linux/PPC port
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000225030334.ZM15636@ocotillo.lan>
References: <1000225014927.ZM15386@ocotillo.lan> <38B5E8EB.22A8C2A0@cygnus.com> <ac131313@cygnus.com>
X-SW-Source: 2000-q1/msg00364.html
Content-length: 2757
On Feb 25, 1:28pm, Andrew Cagney wrote:
> > The differences between ppc_linux_memory_remove_breakpoint () and
> > memory_remove_breakpoint () are minor. All that the former does
> > that the latter does not is check to make sure that the breakpoint
> > location actually contains a breakpoint (trap instruction) prior
> > to attempting to write back the old contents. If it does contain
> > a trap instruction, we allow the old contents to be written back.
> > Otherwise, we silently do nothing.
> >
> > It seems to me that we ought to be using this version in
> > mem-break.c for all other targets (using the mem-break.c
> > facilities) too. The only downside that more traffic is generated
> > for remote targets since we'll have an extra fetch of a memory
> > word each time a breakpoint is removed.
>
> Rather than make this the default behavour (and introduce extra remote
> traffic) would it be better to provide this behavour as a new type of
> breakpoint? The shlib stuff could then insert a checking breakpoint.
I'll have to study it some more. It sounds like a good idea, but I
think we'll have to complicate the breakpoint machinery somewhat to
insert these special breakpoints. (For this particular platform, we'd
insert the special breakpoint when the address in question is in a
PLT.)
> I'd also be curious to know if this shlib mechanism is standard for
> SVR4/PPC or just Linux.
From my reading of the SVR4/PPC ABI, it looks like it's standard. The
following text is especially relevant:
For the PowerPC, the procedure linkage table (the .plt section) is
^^
not initialized in the executable or shared object file. Instead,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the link editor simply reserves space for it and the dynamic
linker initializes it and manages it according to its own,
possibly implementation-dependent needs, subject to the following
constraints:
1. The first 18 words (72 bytes) of the procedure linkage table
are reserved for use by the dynamic linker. There shall be no
branches from the executable or shared object into these first
18 words.
2. If the executable or shared object requires N procedure
linkage table entries, the link editor shall reserve 3*N words
(12*N bytes) following the 18 reserved words. The first 2*N of
these words are the procedure linkage table entries themselves.
The static linker directs calls to bytes (72 + (i-1)*8), for i
between 1 and N inclusive. The remaining N words (4*N bytes)
are reserved for use by the dynamic linker.
Kevin
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>, Jimmy Guo <guo@cup.hp.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: 2nd try: (patch) hpjyg03: (buildsym|language).[ch]
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B0ABEF.8EDEAA53@cygnus.com>
References: <Pine.LNX.4.10.9911011130300.30664-100000@hpcll168.cup.hp.com> <npso2pkf00.fsf@zwingli.cygnus.com> <npg0uqp30k.fsf@zwingli.cygnus.com> <38B0A4A0.D9109A9E@cygnus.com>
X-SW-Source: 2000-q1/msg00265.html
Content-length: 1693
Andrew Cagney wrote:
>
> Unfortunatly, there is no prototype for longest_local_hex_string()
> visible in buildsym.c. I've ended up commiting the following.
Oops!
"language.h" depends on "expression.h". I've also checked in the
attatched.
sorry,
Andrew
? 2diffs
? diffs
? old_wait.h
? %redact.run
? netscape.core
? new-gdbarch
? new-gdbarch.h
? new-gdbarch.c
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.50
diff -p -r1.50 ChangeLog
*** ChangeLog 2000/02/21 02:51:07 1.50
--- ChangeLog 2000/02/21 03:01:59
***************
*** 1,6 ****
Mon Feb 21 12:50:57 2000 Andrew Cagney <cagney@b1.cygnus.com>
! * buildsym.c: Include "language.h" for
longest_local_hex_string_custom.
Mon Feb 21 11:17:18 2000 Andrew Cagney <cagney@b1.cygnus.com>
--- 1,6 ----
Mon Feb 21 12:50:57 2000 Andrew Cagney <cagney@b1.cygnus.com>
! * buildsym.c: Include "language.h" and "expression.h" for
longest_local_hex_string_custom.
Mon Feb 21 11:17:18 2000 Andrew Cagney <cagney@b1.cygnus.com>
Index: buildsym.c
===================================================================
RCS file: /cvs/src/src/gdb/buildsym.c,v
retrieving revision 1.3
diff -p -r1.3 buildsym.c
*** buildsym.c 2000/02/21 02:51:07 1.3
--- buildsym.c 2000/02/21 03:02:02
***************
*** 34,39 ****
--- 34,40 ----
#include "gdbtypes.h"
#include "complaints.h"
#include "gdb_string.h"
+ #include "expression.h" /* For "enum exp_opcode" used by... */
#include "language.h" /* For "longest_local_hex_string_custom" */
/* Ask buildsym.h to define the vars it normally declares `extern'. */
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: "Philippe De Muyter" <phdm@macqel.be>
Cc: gdb-patches@sourceware.cygnus.com (gdb-patches@sourceware.cygnus.com), dan@cgsoftware.com
Subject: Re: regerror link error
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5m8zz8vviv.fsf@jtc.redbacknetworks.com>
References: <200003242151.WAA07612@mail.macqel.be>
X-SW-Source: 2000-q1/msg01006.html
Content-length: 619
>>>>> "Philippe" == Philippe De Muyter <phdm@macqel.be> writes:
Philippe> makes the compilation of gdb fail on my system (m68k-motorola-sysv) :
Philippe> [...]
Philippe> Actually, I have found a __regerror, but no regerror. How
Philippe> can we fix that ?
I think the __regerror() function in gnu-regex.c needs to be renamed
regerror(). All the other functions in that file are defined without
leading double-underscores with a weak_alias() which I assume maps the
two forms together in glibc. It certainly looks like the underscores
aren't supposed to be there.
--jtc
--
J.T. Conklin
RedBack Networks
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb-patches@sourceware.cygnus.com
Subject: [MAINT] Mail address correction
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003010050.e210opc00296@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00435.html
Content-length: 1126
I noticed that the mail address listed in the MAINTAINERS file wasn't
correct (it was missing one character). I changed it to my @gnu.org
address since that's likely to be correct as long as my involvement
with the GNU project continues, whereas my university address might
become invalid if I ever manage to finish my Ph.D. :-).
Mark
2000-03-01 Mark Kettenis <kettenis@gnu.org>
* MAINTAINERS: Correct my own mail address.
Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.15
diff -u -p -r1.15 MAINTAINERS
--- MAINTAINERS 2000/03/01 00:28:35 1.15
+++ MAINTAINERS 2000/03/01 00:42:15
@@ -57,7 +57,7 @@ MS Windows (N.T., CE, '00) host & native
Chris Faylor cgf@cygnus.com
GNU/Linux x86 native Jim Blandy jimb@cygnus.com
GNU/Linux PPC native Kevin Buettner kevinb@cygnus.com
-hurd native Mark Kettenis kettenis@wins.va.nl
+hurd native Mark Kettenis kettenis@gnu.org
macos host & native Stan Shebs shebs@apple.com
hpux, hp pa native Jeff Law law@cygnus.com
UnixWare Threads Nick Duffek nsd@cygnus.com
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] Fix `next'-ing out of a signal handler on Linux/i386
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003082237.e28Mbre06925@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00603.html
Content-length: 2157
FYI,
I committed the attached patch. It is now possible to use the `next'
command to step out of a signal handler. Using `step' however is
still broken. Making that work will probably require some changes to
`infrun.c'. But I'm not sure exactly on how to fix it, and even if I
find out, I'm not sure whether I should touch that file before the 5.0
release.
Mark
2000-03-08 Mark Kettenis <kettenis@gnu.org>
* i386-tdep.c (i386_linux_saved_pc_after_call): New function.
* config/i386/tm-linux.h (SAVED_PC_AFTER_CALL): Define to call
i386_linux_saved_pc_after_call.
Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.5
diff -u -p -r1.5 i386-tdep.c
--- i386-tdep.c 2000/03/04 23:37:33 1.5
+++ i386-tdep.c 2000/03/08 22:32:34
@@ -1024,6 +1024,17 @@ i386_linux_sigtramp_saved_sp (struct fra
return read_memory_integer (addr + LINUX_SIGCONTEXT_SP_OFFSET, 4);
}
+/* Immediately after a function call, return the saved pc. */
+
+CORE_ADDR
+i386_linux_saved_pc_after_call (struct frame_info *frame)
+{
+ if (frame->signal_handler_caller)
+ return i386_linux_sigtramp_saved_pc (frame);
+
+ return read_memory_integer (read_register (SP_REGNUM), 4);
+}
+
#endif /* I386_LINUX_SIGTRAMP */
#ifdef STATIC_TRANSFORM_NAME
Index: config/i386/tm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-linux.h,v
retrieving revision 1.2
diff -u -p -r1.2 tm-linux.h
--- config/i386/tm-linux.h 2000/03/04 23:37:33 1.2
+++ config/i386/tm-linux.h 2000/03/08 22:32:34
@@ -154,6 +154,10 @@ extern CORE_ADDR i386_linux_sigtramp_sav
extern CORE_ADDR i386_linux_sigtramp_saved_sp (struct frame_info *);
+#undef SAVED_PC_AFTER_CALL
+#define SAVED_PC_AFTER_CALL(frame) i386_linux_saved_pc_after_call (frame)
+extern CORE_ADDR i386_linux_saved_pc_after_call (struct frame_info *);
+
/* When we call a function in a shared library, and the PLT sends us
into the dynamic linker to find the function's real address, we
need to skip over the dynamic linker call. This function decides
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Linux sigtramp detection code moved to its proper place
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003201529.KAA10589@indy.delorie.com>
References: <200003201214.e2KCEYK00493@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00816.html
Content-length: 414
> What would you suggest for a non-buggy Tar program to do, exactly?
>
> Simply overwrite the files, possibly asking confirmation from the
> user. This shouldn't be a problem, since the DJGPP native port
> doesn't need i386-linux-nat.c nor i386-linux-tdep.c.
The users don't know whether these files are or aren't needed. So
they might overwrite the wrong files, and mess up the build beyond
any recognition.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Don't trim addresses in Dwarf debug info
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E2B5C6.3451444B@cygnus.com>
References: <200003281624.LAA23161@zwingli.cygnus.com> <38E12BD6.E6E357A4@cygnus.com> <npvh251yvu.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg01120.html
Content-length: 996
Jim Blandy wrote:
>
> > > I've committed this:
> > >
> > > 2000-03-27 Jim Blandy <jimb@redhat.com>
> > >
> > > * dwarf2read.c: Revert Andrew Cagney's change of Dec 15, 1997.
> > > Don't include "bfd-elf.h".
> > > (address_significant_size): Delete variable.
> > > (dwarf2_build_psymtabs_hard): Don't set it, or check for
> > > consistency between it and the Dwarf 2 compilation unit header
> > > address size.
> > > (read_address): Don't mask off bits above
> > > address_significant_size.
> > > * Makefile.in (dwarf2read.o): Don't depend on $(elf_bfd_h).
> > > (elf_bfd_h): Remove variable; it's no longer used.
> >
> > Jim, have you confirmed this doesn't cause any regressions?
>
> It fixes problems for me, and it fixes the problems Stephane Carrez
> reported. It might possibly cause regressions on 64-bit hosts, but
> here's why I committed it anyway:
What specific problems was it causing you?
Andrew
From grante@visi.com Sat Apr 01 00:00:00 2000
From: Grant Edwards <grante@visi.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch for RDI target code to allow user-specified devices
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000221142049.A31223@visi.com>
References: <20000221141155.A31206@visi.com>
X-SW-Source: 2000-q1/msg00285.html
Content-length: 577
> The attached patch against 4.18 sources modifies the RDI target
> unix comm code to allow users to specify any device they please
> to be used for serial and/or parallel communication with the
> target.
NB: The patch was generated from 4.18 sources that already
contained some other RDI patches. This patch is independant
of the others, so it can be applied to clean 4.18 sources,
but you'll see a notice about one of the hunks being offset.
Not that you want to use the RDI target without those other
patches...
--
Grant Edwards
grante@visi.com
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: [PATCH] MI - post comment
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B0EF83.A7F80182@cygnus.com>
X-SW-Source: 2000-q1/msg00275.html
Content-length: 137
Just FYI,
This still won't appear for a day or so. I'll give people a day or so
to chew on it first :-)
nice day for it...
Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Fix for target.c:do_target_signal_to_host()
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AB1EAD.90CE4860@cygnus.com>
References: <200002142116.e1ELGrL06391@delius.kettenis.local> <38A90F10.E61AF586@cygnus.com> <200002161532.e1GFWaf03903@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00206.html
Content-length: 564
Mark Kettenis wrote:
> While adding the comments I noticed that the function will return 32
> for TARGET_SIGNAL_REALTIME_32 even if it doesn't exist, and that (with
> my patch) for the other RT signals the upper bound was checked, but
> not the lower bound. Not likely to be very problematic, but this is
> not right according to the comment at the top of the function.
>
> I also moved the TARGET_SIGNAL_REALTIME_32 case within the
> default: where the other RT signals are handled. I think this
> makes it easier to understand the code.
Yes. Ok.
Andrew
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb-patches@sourceware.cygnus.com
Cc: jtc@redback.com
Subject: [PATCH] Restructuring i386-tdep.c:i386_extract_return_value()
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003220949.e2M9nl001746@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00899.html
Content-length: 6153
Hi,
I checked in the attached patch. This is one of the patches I
discussed two weeks ago, which makes i386_extract_return_value() do
the right thing for most of the supported i386 targets. Some targets
(for example those that use tm-i386v.h) still redefine
EXTRACT_RETURN_VALUE, so they don't take advantage of this
improvement. I'll deal with that later.
Mark
2000-03-22 Mark Kettenis <kettenis@gnu.org>
* config/i386/tm-i386aix.h (I386_AIX_TARGET): Remove.
* config/i386/tm-linux.h (LOW_RETURN_REGNUM, HIGH_RETURN_REGNUM):
Remove
* i386-tdep.c (LOW_RETURN_REGNUM, HIGH_RETURN_REGNUM): New defines.
(i386_extract_return_value): Rewritten. Correctly support all
floating-point types and large integer types on targets that use
the standard i386 GDB register layout and return floating-point
values in the FPU.
Index: config/i386/tm-i386aix.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-i386aix.h,v
retrieving revision 1.2
diff -u -p -r1.2 tm-i386aix.h
--- config/i386/tm-i386aix.h 2000/03/02 15:44:27 1.2
+++ config/i386/tm-i386aix.h 2000/03/22 09:41:10
@@ -30,14 +30,6 @@
#define I386 1
#endif
-/* FIXME: kettenis/2000-03-02: This is used in
- i386-tdep.c:i386_extract_return_value(), and will be remove once
- I've fixed that. Meanwhile don't use it for any other purpose
- please! */
-#ifndef I386_AIX_TARGET
-#define I386_AIX_TARGET 1
-#endif
-
/* AIX/i386 has FPU support. However, the native configuration (which
is the only supported configuration) doesn't make the FPU control
registers available. Override the appropriate symbols such that
Index: config/i386/tm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-linux.h,v
retrieving revision 1.4
diff -u -p -r1.4 tm-linux.h
--- config/i386/tm-linux.h 2000/03/16 22:46:30 1.4
+++ config/i386/tm-linux.h 2000/03/22 09:41:10
@@ -30,9 +30,6 @@
#include "i386/tm-i386.h"
#include "tm-linux.h"
-#define LOW_RETURN_REGNUM 0 /* holds low four bytes of result */
-#define HIGH_RETURN_REGNUM 2 /* holds high four bytes of result */
-
/* This should probably move to tm-i386.h. */
#define TARGET_LONG_DOUBLE_BIT 80
Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.7
diff -u -p -r1.7 i386-tdep.c
--- i386-tdep.c 2000/03/16 22:46:26 1.7
+++ i386-tdep.c 2000/03/22 09:41:10
@@ -698,56 +698,66 @@ get_longjmp_target (pc)
#endif /* GET_LONGJMP_TARGET */
+/* These registers are used for returning integers (and on some
+ targets also for returning `struct' and `union' values when their
+ size and alignment match an integer type. */
+#define LOW_RETURN_REGNUM 0 /* %eax */
+#define HIGH_RETURN_REGNUM 2 /* %edx */
+
+/* Extract from an array REGBUF containing the (raw) register state, a
+ function return value of TYPE, and copy that, in virtual format,
+ into VALBUF. */
+
void
-i386_extract_return_value (type, regbuf, valbuf)
- struct type *type;
- char regbuf[REGISTER_BYTES];
- char *valbuf;
+i386_extract_return_value (struct type *type, char *regbuf, char *valbuf)
{
- /* On AIX, i386 GNU/Linux and DJGPP, floating point values are
- returned in floating point registers. */
- /* FIXME: cagney/2000-02-29: This function needs to be rewritten
- using multi-arch. Please don't keep adding to this #ifdef
- spaghetti. */
-#if defined(I386_AIX_TARGET) || defined(I386_GNULINUX_TARGET) || defined(I386_DJGPP_TARGET)
+ int len = TYPE_LENGTH (type);
+
if (TYPE_CODE_FLT == TYPE_CODE (type))
{
- double d;
- /* 387 %st(0), gcc uses this */
- floatformat_to_double (&floatformat_i387_ext,
-#if defined(FPDATA_REGNUM)
- ®buf[REGISTER_BYTE (FPDATA_REGNUM)],
-#else /* !FPDATA_REGNUM */
- ®buf[REGISTER_BYTE (FP0_REGNUM)],
-#endif /* FPDATA_REGNUM */
+ if (NUM_FREGS == 0)
+ {
+ warning ("Cannot find floating-point return value.");
+ memset (valbuf, 0, len);
+ }
- &d);
- store_floating (valbuf, TYPE_LENGTH (type), d);
+ /* Floating-point return values can be found in %st(0). */
+ if (len == TARGET_LONG_DOUBLE_BIT / TARGET_CHAR_BIT
+ && TARGET_LONG_DOUBLE_FORMAT == &floatformat_i387_ext)
+ {
+ /* Copy straight over, but take care of the padding. */
+ memcpy (valbuf, ®buf[REGISTER_BYTE (FP0_REGNUM)],
+ FPU_REG_RAW_SIZE);
+ memset (valbuf + FPU_REG_RAW_SIZE, 0, len - FPU_REG_RAW_SIZE);
+ }
+ else
+ {
+ /* Convert the extended floating-point number found in
+ %st(0) to the desired type. This is probably not exactly
+ how it would happen on the target itself, but it is the
+ best we can do. */
+ DOUBLEST val;
+ floatformat_to_doublest (&floatformat_i387_ext,
+ ®buf[REGISTER_BYTE (FP0_REGNUM)], &val);
+ store_floating (valbuf, TYPE_LENGTH (type), val);
+ }
}
else
-#endif /* I386_AIX_TARGET || I386_GNULINUX_TARGET || I386_DJGPP_TARGET */
{
-#if defined(LOW_RETURN_REGNUM)
- int len = TYPE_LENGTH (type);
int low_size = REGISTER_RAW_SIZE (LOW_RETURN_REGNUM);
int high_size = REGISTER_RAW_SIZE (HIGH_RETURN_REGNUM);
if (len <= low_size)
- memcpy (valbuf, regbuf + REGISTER_BYTE (LOW_RETURN_REGNUM), len);
+ memcpy (valbuf, ®buf[REGISTER_BYTE (LOW_RETURN_REGNUM)], len);
else if (len <= (low_size + high_size))
{
memcpy (valbuf,
- regbuf + REGISTER_BYTE (LOW_RETURN_REGNUM),
- low_size);
+ ®buf[REGISTER_BYTE (LOW_RETURN_REGNUM)], low_size);
memcpy (valbuf + low_size,
- regbuf + REGISTER_BYTE (HIGH_RETURN_REGNUM),
- len - low_size);
+ ®buf[REGISTER_BYTE (HIGH_RETURN_REGNUM)], len - low_size);
}
else
- error ("GDB bug: i386-tdep.c (i386_extract_return_value): Don't know how to find a return value %d bytes long", len);
-#else /* !LOW_RETURN_REGNUM */
- memcpy (valbuf, regbuf, TYPE_LENGTH (type));
-#endif /* LOW_RETURN_REGNUM */
+ internal_error ("Cannot extract return value of %d bytes long.", len);
}
}
From fnasser@cygnus.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: gdb-patches@sourceware.cygnus.com, jingham@cygnus.com
Subject: Re: Patch for arm_push_arguments
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38CEA1FF.CEA9553@cygnus.com>
References: <38CE9C8B.3EC5B7F1@netwinder.org>
X-SW-Source: 2000-q1/msg00695.html
Content-length: 712
Scott,
I have to try it on a few targets, so I need a few days. I will try to run all the tests this week though.
Thanks for doing this.
Fernando
Scott Bambrough wrote:
>
> Hi guys,
>
> * arm-tdep.c (arm_push_arguments): Correctly code for converting a
> float argument from host format to a target double when preparing the
> call frame for a function.
>
> This works for me. Can you try it out. If it works, let me know and I'll check
> it in.
>
> Scott
>
--
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 phdm@macqel.be Sat Apr 01 00:00:00 2000
From: "Philippe De Muyter" <phdm@macqel.be>
To: gdb-patches@sourceware.cygnus.com (gdb-patches@sourceware.cygnus.com), dan@cgsoftware.com
Subject: regerror link error
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003242151.WAA07612@mail.macqel.be>
X-SW-Source: 2000-q1/msg01000.html
Content-length: 845
The following patch :
2000-03-22 Daniel Berlin <dan@cgsoftware.com>
* command.c (apropos_cmd_helper): New function, meat of the
apropos command.
(apropos_command): New apropos command to search command
names/documentation for regular expressions.
(_initialize_command): Add the apropos command.
makes the compilation of gdb fail on my system (m68k-motorola-sysv) :
gcc -g -O2 -W -Wall -o gdb main.o libgdb.a ../bfd/libbfd.a ../readline
/libreadline.a ../opcodes/libopcodes.a ./../intl/libintl.a ../libiberty/libibert
y.a -lncurses -lm ../libiberty/libiberty.a
libgdb.a(command.o): In function `apropos_command':
command.c:481: undefined reference to `regerror'
collect2: ld returned 1 exit status
Actually, I have found a __regerror, but no regerror. How can we fix that ?
Philippe
From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: GDB-5 2000-03-03
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14527.59027.494800.595466@kwikemart.cygnus.com>
References: <38BFBD74.79263683@cygnus.com> <200003031556.e23FuCm00326@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00475.html
Content-length: 3428
Mark, sigh, that's my fault. I made some changes to the MI disassemble
interface and haven't had a chance to update the tests. I'll try to
get to that before Monday.
Elena
Mark Kettenis writes:
> Date: Sat, 04 Mar 2000 00:26:12 +1100
> From: Andrew Cagney <ac131313@cygnus.com>
>
> MI tests
>
> The MI testsuite falls over (lots of dejagnu errors) when the MI wasn't
> build.
>
> Even if I build MI, there are quite a few dejagnu errors:
>
> ERROR: Undefined command "-file-clear".
> UNRESOLVED: gdb.mi/mi-basics.exp: file-clear operation
>
> FAIL: gdb.mi/mi-console.exp: Hello message (timeout)
> ...
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble from pc assembly only
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble main assembly only
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble range assembly only
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble callee2 assembly only
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble callee2 assembly mixed
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble range assembly mixed
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble callee2 assembly mixed
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble bogus arguments
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble wrong num of args (3)
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble wrong num of args (2)
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble wrong num of args (1)
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble from pc two lines - assembly only
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble main 1 line - assembly only
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble main zero lines - assembly only
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble lines bigger than range - assembly only
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble lines less than range - assembly only
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble from pc two lines - assembly mixed
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble main 1 line - assembly mixed
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble main zero lines - assembly mixed
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble lines bigger than range - assembly mixed
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble lines less than range - assembly mixed
> ...
> FAIL: gdb.mi/mi-disassemble.exp: data-disassemble from pc assembly mixed
> ...
> FAIL: gdb.mi/mi-simplerun.exp: exec-finish (timeout)
> FAIL: gdb.mi/mi-simplerun.exp: continue to end (1)
> ...
> FAIL: gdb.mi/mi-stack.exp: stack args listing 0
> ...
> FAIL: gdb.mi/mi-stack.exp: stack args listing 1
> ...
> FAIL: gdb.mi/mi-stack.exp: stack info-depth
> ...
> FAIL: gdb.mi/mi-stack.exp: stack info-depth 99
> ...
> FAIL: gdb.mi/mi-var-child.exp: update all vars psnp->next->long_ptr (and 1.long_ptr) changed
> ...
> FAIL: gdb.mi/mi-var-cmd.exp: update all vars: changed FIXME
> ...
> FAIL: gdb.mi/mi-watch.exp: list of watchpoints
> ...
> FAIL: gdb.mi/mi-watch.exp: wp out of scope (2)
>
>
> Here's the summary for i586-pc-linux-gnu:
>
> === gdb Summary ===
>
> # of expected passes 6827
> # of unexpected failures 45
> # of expected failures 212
> # of unresolved testcases 1
> /mnt/hdb4/obj/src/gdb/testsuite/../../gdb/gdb version 20000204 -nx
>
> The majority of all those unexpected failures is because of the MI
> problems.
>
> Mark
From nsd@cygnus.com Sat Apr 01 00:00:00 2000
From: nsd@cygnus.com
To: john@feith.com
Cc: cgf@cygnus.com, eliz@delorie.com, gdb-patches@sourceware.cygnus.com, jimb@cygnus.com, msnyder@cygnus.com
Subject: Re: GDB 4.17 Patch for stack aligned i386 code
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003250054.AAA07709@nog.bosbc.com>
References: <200003250030.TAA14328@jwlab.FEITH.COM>
X-SW-Source: 2000-q1/msg01015.html
Content-length: 314
>I'm not sure what I still have laying around other than a very old patch
>for GCC. The idea is to handle a prologue which looks like:
Thanks, that makes it clear.
At the moment, I don't think my patch would handle that correctly. The
"tightening up" that I mentioned earlier might do the trick, though.
Nick
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Problem with gdb/objfiles.c and --with-mmalloc + fix
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bg0uepm83.fsf@rtl.cygnus.com>
References: <200002232157.WAA26169@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-q1/msg00382.html
Content-length: 325
> I have used --with-mmalloc with GDB configure for a long time to get sort of
> a poor man's purify. Unfortunately gdb/objfiles.c suffered some bitrot
> during the last year, here is a fix:
Looks like a straightforward bugfix to me.
Maintainer is JimB (if objfiles.c is part of "generic symtabs") or
Andrew/Stan (if not).
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: GDB 5 2000-03-29
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003312306.SAA07143@indy.delorie.com>
References: <38E17D2C.F7EB65B9@cygnus.com>
X-SW-Source: 2000-q1/msg01141.html
Content-length: 1747
> For the watchpoint patches, if at least some have been addressed, I'd
> like to put the rest off.
All of them are addressed now. See below.
> Watch point related patches (Eli Zaretskii, Michael Snyder, ???)
>
> Eli writes: This doesn't include the watchpoint-related patches I sent
> beginning with August or September, and mentioned them again three
> weeks ago. Here again are the pointers to the relevant messages:
>
> Hardware breakpoints and watchpoints: patches
> http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00173.html
>
> Re: Hardware breakpoints and watchpoints: patches
> http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00204.html
>
> Re: Hardware breakpoints and watchpoints: patches
> http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00200.html
>
> Hardware watchpoints for bitfields
> http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00201.html
Michael posted about a week ago several messages saying that my
patches were checked in. The relevant messages are:
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00873.html
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00840.html
So I'm quite happy with this (thanks, Michael!).
> +MI documentation in GDB user guide. (Andrew Cagney, Elena Zannoni,
> +Stan Shebs, anyone else?)
> +
> +> (Are there plans to make gdbmi.texi be part of the manual as well?)
If no one objects, I can submit changes to incorporate gdbmi.texi into
the manual.
> +[PATCH] GDB command-line switches and annotations docs
> + http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00639.html
I believe this is already checked in (I commited these patches two weeks
ago). See
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00739.html
From shebs@apple.com Sat Apr 01 00:00: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: Sat, 01 Apr 2000 00:00: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-q1/msg00729.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 jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: NetBSD/i386 core dump support
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5msnxhqmiq.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00957.html
Content-length: 2618
I submit the enclosed patch for approval.
This change enables core dump support on NetBSD/i386 and adds floating
point register support to fetch_core_registers().
2000-03-23 J.T. Conklin <jtc@redback.com>
* i386nbsd-nat.c (fetch_core_registers): Read fp registers.
(i386nbsd_core_fns, _initialize_i386nbsd_nat): Added.
Index: i386nbsd-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/i386nbsd-nat.c,v
retrieving revision 1.1
diff -c -3 -p -r1.1 i386nbsd-nat.c
*** i386nbsd-nat.c 2000/03/22 01:36:31 1.1
--- i386nbsd-nat.c 2000/03/23 23:35:03
*************** store_inferior_registers (regno)
*** 152,158 ****
struct md_core
{
struct reg intreg;
! struct fpreg freg;
};
void
--- 152,158 ----
struct md_core
{
struct reg intreg;
! struct env387 freg;
};
void
*************** fetch_core_registers (core_reg_sect, cor
*** 167,172 ****
/* integer registers */
memcpy (®isters[REGISTER_BYTE (0)], &core_reg->intreg,
sizeof (struct reg));
/* floating point registers */
! /* XXX */
}
--- 167,209 ----
/* integer registers */
memcpy (®isters[REGISTER_BYTE (0)], &core_reg->intreg,
sizeof (struct reg));
+
/* floating point registers */
! RF (FP0_REGNUM, core_reg->freg.regs[0]);
! RF (FP0_REGNUM + 1, core_reg->freg.regs[1]);
! RF (FP0_REGNUM + 2, core_reg->freg.regs[2]);
! RF (FP0_REGNUM + 3, core_reg->freg.regs[3]);
! RF (FP0_REGNUM + 4, core_reg->freg.regs[4]);
! RF (FP0_REGNUM + 5, core_reg->freg.regs[5]);
! RF (FP0_REGNUM + 6, core_reg->freg.regs[6]);
! RF (FP0_REGNUM + 7, core_reg->freg.regs[7]);
!
! RF (FCTRL_REGNUM, core_reg->freg.control);
! RF (FSTAT_REGNUM, core_reg->freg.status);
! RF (FTAG_REGNUM, core_reg->freg.tag);
! RF (FCS_REGNUM, core_reg->freg.code_seg);
! RF (FCOFF_REGNUM, core_reg->freg.eip);
! RF (FDS_REGNUM, core_reg->freg.operand_seg);
! RF (FDOFF_REGNUM, core_reg->freg.operand);
! RF (FOP_REGNUM, core_reg->freg.opcode);
!
! registers_fetched ();
! }
!
! /* Register that we are able to handle i386nbsd core file formats.
! FIXME: is this really bfd_target_unknown_flavour? */
!
! static struct core_fns i386nbsd_core_fns =
! {
! bfd_target_unknown_flavour, /* core_flavour */
! default_check_format, /* check_format */
! default_core_sniffer, /* core_sniffer */
! fetch_core_registers, /* core_read_registers */
! NULL /* next */
! };
!
! void
! _initialize_i386nbsd_nat ()
! {
! add_core_fns (&i386nbsd_core_fns);
}
--
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: GDB-5 2000-03-03
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C08FC8.CF5D627D@cygnus.com>
References: <38BFBD74.79263683@cygnus.com> <200003031714.e23HEC900400@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00495.html
Content-length: 1683
Mark Kettenis wrote:
> There are two issue's in the generic x86 code that I'd like to
> address:
I've added these to the ``Nice to have'' section.
> The current code doesn't run on Linux 2.x (remember the message you
> just sent to Tom):
>
> http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00294.html
Added.
> The FP control registers contain some really weird numbers since the
> reserved bits aren't masked of. Patch:
>
> http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00375.html
Added.
> Signal tramplines aren't recognized. Patch:
>
> http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00059.html
Added.
> Programs run under GDB have SIGCHLD masked. No patch yet.
Added to ``nice to have''. Can be worked around.
> This seems to happen on Solaris too.
Note added.
> This has been fixed:
Yes, I noticed that. That's why I moved it to old problems :-)
> The testsuite runs OK, but contains a very limited number of tests. I
> recently discovered that the thread_db code doesn't handle threads
> that exit. See the following URL for more info:
>
> http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00525.html
>
> I would consider this a pretty critical bug.
I've added it (I can't comment on the seriousness of the specific bug).
More serious is the lack of proper testing of the thread code. I'd
rather see effort put into improving the testsuite ready for 5.1 than
fixing bugs in 5.0.
> Of course there is the issue of "which alpha release of glibc 2.1.3?".
> Personally I (kingdon) am most worried about the one in Red Hat Linux
> 6.2beta.
>
> There is an official glibc 2.1.3 release now.
Thanks,
Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Stephane Carrez <Stephane.Carrez@worldnet.fr>
Cc: gdb-patches@sourceware.cygnus.com, Jim Blandy <jimb@cygnus.com>
Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BB5463.D6E5B75C@cygnus.com>
References: <38B2F3D3.54CF0AF0@worldnet.fr>
X-SW-Source: 2000-q1/msg00412.html
Content-length: 2194
Stephane Carrez wrote:
>
> Hi!
>
> The following patch fixes GDB dwarf-2 reader to support 16-bit address
> targets.
>
> In 'dwarf2_build_psymtabs_hard' there was a hack to guess the size of the
> target address. We were using the bfd 'elf_size_info::arch_size' member.
> This corresponds to the ELF file arch size, not the target address size.
> I suggest to use 'bfd_arch_bits_per_address' which really corresponds to
> what we need.
>
> Then, in 'read_address', we just have to read 2-bytes addresses.
>
> I've been using this fix for a while with the 68HC11 port.
>
> Can you integrate it?
>
> Thanks,
> Stephane
>
> 2000-02-22 Stephane Carrez <stcarrez@worldnet.fr>
>
> * dwarf2read.c (dwarf2_build_psymtabs_hard): Use
> bfd_arch_bits_per_address to get the size of addresses.
FYI,
I've applied this bit:
> (read_address): Read 16-bits addresses.
As for the change:
> - address_significant_size = get_elf_backend_data (abfd)->s->arch_size / 8;
> + address_significant_size = bfd_arch_bits_per_address (abfd) / 8;
I'm not so sure. Does bfd_arch_bits_per_address() return 16 while the
elf data arch_size indicate something else (elf32 vs elf16?)
I've attatched some references to when a similar problem was discussed
for a 64 bit target with 32 bit ELF binaries.
Jim?
Andrew
http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00267.html
http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00263.html
Tue Feb 29 15:14:56 2000 Andrew Cagney <cagney@b1.cygnus.com>
From 2000-02-22 Stephane Carrez <stcarrez@worldnet.fr>:
* dwarf2read.c (read_address): Read 16-bits addresses.
Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.2
diff -p -r1.2 dwarf2read.c
*** dwarf2read.c 2000/02/14 04:37:06 1.2
--- dwarf2read.c 2000/02/29 05:06:26
*************** read_address (abfd, buf)
*** 3487,3492 ****
--- 3487,3495 ----
switch (address_size)
{
+ case 2:
+ retval = bfd_get_16 (abfd, (bfd_byte *) buf);
+ break;
case 4:
retval = bfd_get_32 (abfd, (bfd_byte *) buf);
break;
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com, Jim Blandy <jimb@cygnus.com>
Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bput8j8vi.fsf@rtl.cygnus.com>
References: <38B2F3D3.54CF0AF0@worldnet.fr> <38BB5463.D6E5B75C@cygnus.com> <38C0D9D9.70987863@worldnet.fr> <38C225F3.9E236A55@cygnus.com>
X-SW-Source: 2000-q1/msg00539.html
Content-length: 1877
> When I say ``elf16'', I was thinking of an elf object file that has 16
> bit addresses. I'm not sure what other consequences such a move would
> have.
Strikes me as a bad idea. Or to put it another way, designing a
hypothetical elf16 format seems like something you'd do only if you
had pretty compelling reasons, not just to fix a GDB bug which can be
fixed in much simpler ways.
> Is there any reason why s->arch_size isn't 16 in your case?
Hmm, that's an interesting question. Some uses of arch_size in BFD
seem to decide alignment of pointers (in .got, .rela and other
sections in bfd/elflink.c) but others seem to be based on elf32
vs. elf64 (.stabsstr section in bfd/elf.c). GDB doesn't seem to use
arch_size beyond the one usage we are discussing. I didn't check
binutils. I think it is possible that bfd/elflink.c should be
referring to bfd_arch_bits_per_address.
The whole address_significant_size code in dwarf2read.c strikes me as
a rather ugly kludge to work around bugs elsewhere in the tool chain.
If someone is supplying a 32 bit pointer to GDB on a 16 bit target,
shouldn't the rest of the tool chain be responsible for making sure
the high bits are zero rather than expecting GDB to mask it off?
Granted there might be complications here, like there are cases on
MIPS where we treat an address as signed rather than unsigned, but I'm
also pretty clear on whether that is actually design or just a bug. I
could be wrong/persuadable, of course, and perhaps someone has a
better idea of all this (in which case I'd suggest commenting
arch_size at bfd/elf-bfd.h and/or expanding comments at
bfd_arch_bits_per_address in bfd/archures.c).
Or to put it another way, specifically what went wrong on the 68HC11
if you didn't change dwarf2read.c? If it was just the "Dwarf Error:
bad address size" error, what happens if you just comment out that
check?
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: nsd@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Patch: catch_errors() bug fixes and speedups
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B2FC43.DB202309@cygnus.com>
References: <200002112031.UAA02868@nog.bosbc.com> <200002222010.UAA05801@nog.bosbc.com> <14514.63567.180178.977613@kwikemart.cygnus.com>
X-SW-Source: 2000-q1/msg00308.html
Content-length: 279
Elena Zannoni wrote:
>
> Looks great. Thanks Nick, for taking the time to fix this.
> It can certainly go in, unless Andrew has some objections.
Not likely. catch_errors() always was a nasty piece of work. This
cleanup makes it cleaner, faster, simpler.....
nice,
Andrew
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Jim Kingdon <kingdon@redhat.com>
Cc: toddpw@windriver.com, kettenis@wins.uva.nl, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Another revised patch for dlclose
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000308103740.A3530@lucon.org>
References: <200003080849.AAA18417@alabama.wrs.com> <200003081441.JAA02876@devserv.devel.redhat.com>
X-SW-Source: 2000-q1/msg00599.html
Content-length: 4624
On Wed, Mar 08, 2000 at 09:41:00AM -0500, Jim Kingdon wrote:
>
> There are a few loose ends in freeing, but it is the tangled logic in
> find_solib that is tripping us up more than the freeing.
Here is a new patch. It seems to work with the testcase. Any
comments?
H.J.
----
2000-03-08 H.J. Lu <hjl@gnu.org>
Inspired by patches from Sam Lantinga (slouken@devolution.com):
* solib.c (solib_verify): New function. Unload the shared
object when it is deleted and dump symbols from the unloaded
shared object.
* solib.h (SOLIB_VERIFY): New. Defined as solib_verify.
* infrun.c (handle_inferior_event): Also call SOLIB_VERIFY ()
if it is defined when we hit the internal debug breakpoint for
shared libraries in the dynamic linker.
Index: solib.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/solib.c,v
retrieving revision 1.1.1.4
retrieving revision 1.7
diff -u -p -r1.1.1.4 -r1.7
--- solib.c 2000/03/07 18:42:17 1.1.1.4
+++ solib.c 2000/03/08 18:36:11 1.7
@@ -950,6 +950,84 @@ open_symbol_file_object (arg)
return 1;
}
#endif /* SVR4_SHARED_LIBS */
+
+/*
+
+GLOBAL FUNCTION
+
+ solib_verify -- check solib list consistency and dump symbols
+ from unloaded shared objects
+
+SYNOPSIS
+
+ void solib_verify (void)
+
+DESCRIPTION
+
+ This module is called whenever we hit a dynamic linker
+ breakpoint and allows us to check the consistency of our shared
+ object list and unload objects which are no longer valid in the
+ in the inferior. Without this, dynamic unlinking of objects
+ could crash us. This function should only be called when we
+ hit the internal debug breakpoint for shared libraries in the
+ dynamic linker.
+
+ */
+
+void
+solib_verify (void)
+{
+#ifdef SVR4_SHARED_LIBS
+ if (debug_base)
+ {
+ static int solib_unloading = 0;
+
+ read_memory (debug_base, (char *) &debug_copy,
+ sizeof (struct r_debug));
+ if (debug_copy.r_state == RT_DELETE)
+ solib_unloading = 1;
+ else if (solib_unloading && debug_copy.r_state == RT_CONSISTENT)
+ {
+ struct so_list *so = NULL, *next, *so_next, *saved;
+
+ /* Get the current list of loaded shared libraries. */
+ saved = so_list_head;
+ so_list_head = NULL;
+ while ((so = find_solib (so)) != NULL);
+ so = so_list_head;
+ so_list_head = saved;
+
+ /* We compare the current list against what we have. */
+ for (next = so_list_head; next; next = next->next)
+ {
+ for (so_next = so; so_next; so_next = so_next->next)
+ if (strcmp (so_next->so_name, next->so_name) == 0)
+ break;
+
+ if (!so_next)
+ {
+ /* We didn't find it in the current list. Unload it.
+ Since the dynamic linker can only unload one
+ shared library at a time, we stop here. Also
+ free_objfile () will call clear_solib (). It will
+ clear everything for us. */
+ free_objfile (next->objfile);
+ break;
+ }
+ }
+
+ /* Free the current list of loaded shared libraries. */
+ for (so_next = so; so_next; so_next = next)
+ {
+ next = so_next->next;
+ free (so_next);
+ }
+
+ solib_unloading = 0;
+ }
+ }
+#endif /* SVR4_SHARED_LIBS */
+}
/*
Index: solib.h
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/solib.h,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -p -r1.1.1.1 -r1.2
--- solib.h 1999/09/09 00:38:38 1.1.1.1
+++ solib.h 2000/03/07 21:55:11 1.2
@@ -37,6 +37,14 @@ clear_solib PARAMS ((void));
extern void
solib_add PARAMS ((char *, int, struct target_ops *));
+/* Called to check solib list consistency and dump symbols from
+ unloaded shared objects. */
+
+#define SOLIB_VERIFY() solib_verify ()
+
+extern void
+solib_verify PARAMS ((void));
+
/* Function to be called when the inferior starts up, to discover the names
of shared libraries that are dynamically linked, the base addresses to
which they are linked, and sufficient information to read in their symbols
Index: infrun.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/infrun.c,v
retrieving revision 1.1.1.6
retrieving revision 1.2
diff -u -p -r1.1.1.6 -r1.2
--- infrun.c 2000/03/07 18:42:13 1.1.1.6
+++ infrun.c 2000/03/07 21:55:11 1.2
@@ -2416,6 +2416,9 @@ handle_inferior_event (struct execution_
/* Switch terminal for any messages produced by
breakpoint_re_set. */
target_terminal_ours_for_output ();
+#ifdef SOLIB_VERIFY
+ SOLIB_VERIFY ();
+#endif
SOLIB_ADD (NULL, 0, NULL);
target_terminal_inferior ();
}
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jason Molenda <jsm@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch to change gdb's behavior for Makefile target 'diststuff'
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AA26ED.DAC914DC@cygnus.com>
References: <20000215200720.A20254@cygnus.com>
X-SW-Source: 2000-q1/msg00171.html
Content-length: 1603
Jason Molenda wrote:
Approved.
Andrew
> I am trying to steal the binutils snapshot script. That script does
> a 'make diststuff' at the top-level, which does all sorts of stuff.
> Diststuff in gdb does a 'all-doc' in the doc/ subdirectory and the
> Makefile there tries to run tex to generate some DVI files.
>
> I want gdb/Makefile.in to run 'diststuff' in the doc/ directory, and
> I want 'diststuff' in the doc/ directory to just generate the info
> files.
>
> This mirrors the binutils behavior.
>
> Jason
>
> Index: Makefile.in
> ===================================================================
> RCS file: /cvs/src/src/gdb/Makefile.in,v
> retrieving revision 1.3
> diff -u -p -r1.3 Makefile.in
> --- Makefile.in 2000/02/09 08:52:44 1.3
> +++ Makefile.in 2000/02/16 04:03:49
> @@ -872,7 +872,7 @@ do-maintainer-clean:
> subdir_do
>
> diststuff: $(DISTSTUFF)
> - cd doc; $(MAKE) $(MFLAGS) all-doc
> + cd doc; $(MAKE) $(MFLAGS) diststuff
>
> subdir_do: force
> @for i in $(DODIRS); do \
> Index: doc/Makefile.in
> ===================================================================
> RCS file: /cvs/src/src/gdb/doc/Makefile.in,v
> retrieving revision 1.1.1.5
> diff -u -p -r1.1.1.5 Makefile.in
> --- Makefile.in 2000/02/07 00:19:39 1.1.1.5
> +++ Makefile.in 2000/02/16 04:03:53
> @@ -100,6 +100,7 @@ dvi: gdb.dvi gdbint.dvi stabs.dvi refcar
> ps: gdb.ps gdbint.ps stabs.ps refcard.ps
> html: gdb_toc.html gdbint_toc.html stabs_toc.html
> all-doc: info dvi ps
> +diststuff: info
>
> install-info: info
> for i in *.info* ; do \
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: Kevin Buettner <kevinb@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Minor change to gdb/doc/agentexpr.texi
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AC8B93.6A1F0028@cygnus.com>
References: <1000216043742.ZM2605@ocotillo.lan> <5mk8k3tv6h.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00235.html
Content-length: 820
"J.T. Conklin" wrote:
>
> >>>>> "Kevin" == Kevin Buettner <kevinb@cygnus.com> writes:
> Kevin> I've just committed a minor change (see below) to
> Kevin> gdb/doc/agentexpr.texi. Intel does not want us to use "Merced"
> Kevin> in the gdb documentation. And when referring to their next
> Kevin> generation architecture, we must use "IA-64". No other variant
> Kevin> is acceptable.
>
> I have no problem with the change per se, but the implication that
> some other party can dictate what is, and what is not, "acceptable"
> to put in FSF manuals is disturbing.
In this case, while I think it is important I dont think it is a
concern. Where a tradmark name is used in a published document it
should be used correctly.
(Unless of course the FSF has some policy where it refuses to recognize
trademarks.)
Andrew
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: eliz@is.elta.co.il
Cc: jimb@zwingli.cygnus.com, kevinb@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Linux sigtramp detection code moved to its proper place
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003201214.e2KCEYK00493@delius.kettenis.local>
References: <200003162241.RAA19616@zwingli.cygnus.com> <1000316225504.ZM3009@ocotillo.lan> <npsnxp8ix6.fsf@zwingli.cygnus.com> <200003182227.RAA07058@indy.delorie.com> <200003192248.e2JMm1H00626@delius.kettenis.local> <200003201002.FAA09374@indy.delorie.com>
X-SW-Source: 2000-q1/msg00813.html
Content-length: 1004
Date: Mon, 20 Mar 2000 05:02:58 -0500 (EST)
From: Eli Zaretskii <eliz@delorie.com>
> How about i386linux-tdep.c, for example?
>
> Yuck, that's ugly!
How is it uglier than i386gnu-nat.c?
I want either i386-linux-nat.c and i386-linux-tdep.c or
i386linux-nat.c and i386linux-tdep.c, but *not* a mixture of those.
If I ever see the need for target dependent code for the Hurd/i386 it
will end up in i386gnu-tdep.c (which isn't 8.3 unique either).
> Is it really important that these Linux-specific files are correctly
> extracted on MS-DOS? I believe your argument was about buggy tar
> programs floating around, but I don't think it is too much too ask
> people to fix their tar before trying to build GDB.
What would you suggest for a non-buggy Tar program to do, exactly?
Simply overwrite the files, possibly asking confirmation from the
user. This shouldn't be a problem, since the DJGPP native port
doesn't need i386-linux-nat.c nor i386-linux-tdep.c.
Mark
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Cc: Michael Snyder <msnyder@cygnus.com>
Subject: [PATCH RFA] linux-thread.c, lin-thread.c changes
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000324204825.ZM4807@ocotillo.lan>
X-SW-Source: 2000-q1/msg00996.html
Content-length: 2748
I request approval for committing the changes below.
The lines that read
#if TARGET_PTR_BIT > TARGET_INT_BIT
cause a compilation error on linux/ia64 due to the fact that
TARGET_PTR_BIT and TARGET_INT_BIT are computed at runtime for the
IA-64 architecture. (When we get around to multi-arching the other
linux ports, they'll have the same problem.)
* linux-thread.c, lin-thread.c (save_inferior_pid,
restore_inferior_pid): Don't do compile time comparison
of TARGET_PTR_BIT and TARGET_INT_BIT.
Index: linux-thread.c
===================================================================
RCS file: /cvs/src/src/gdb/linux-thread.c,v
retrieving revision 1.5
diff -u -p -r1.5 linux-thread.c
--- linux-thread.c 2000/03/18 01:56:31 1.5
+++ linux-thread.c 2000/03/24 20:36:43
@@ -378,25 +378,22 @@ linuxthreads_find_trap (pid, stop)
/* Cleanup stub for save_inferior_pid. */
static void
-restore_inferior_pid (arg)
- void *arg;
+restore_inferior_pid (void *arg)
{
-#if TARGET_PTR_BIT > TARGET_INT_BIT
- inferior_pid = (int) ((long) arg);
-#else
- inferior_pid = (int) arg;
-#endif
+ int *saved_pid_ptr = arg;
+ inferior_pid = *saved_pid_ptr;
+ free (arg);
}
/* Register a cleanup to restore the value of inferior_pid. */
static struct cleanup *
-save_inferior_pid ()
+save_inferior_pid (void)
{
-#if TARGET_PTR_BIT > TARGET_INT_BIT
- return make_cleanup (restore_inferior_pid, (void *) ((long) inferior_pid));
-#else
- return make_cleanup (restore_inferior_pid, (void *) inferior_pid);
-#endif
+ int *saved_pid_ptr;
+
+ saved_pid_ptr = xmalloc (sizeof (int));
+ *saved_pid_ptr = inferior_pid;
+ return make_cleanup (restore_inferior_pid, saved_pid_ptr);
}
static void
Index: lin-thread.c
===================================================================
RCS file: /cvs/src/src/gdb/lin-thread.c,v
retrieving revision 1.2
diff -u -p -r1.2 lin-thread.c
--- lin-thread.c 2000/02/09 08:52:46 1.2
+++ lin-thread.c 2000/03/24 20:36:47
@@ -658,21 +658,19 @@ init_thread_db_library ()
static struct cleanup *
save_inferior_pid (void)
{
-#if TARGET_PTR_BIT > TARGET_INT_BIT
- return make_cleanup (restore_inferior_pid, (void *) ((long) inferior_pid));
-#else
- return make_cleanup (restore_inferior_pid, (void *) inferior_pid);
-#endif
+ int *saved_pid_ptr;
+
+ saved_pid_ptr = xmalloc (sizeof (int));
+ *saved_pid_ptr = inferior_pid;
+ return make_cleanup (restore_inferior_pid, saved_pid_ptr);
}
static void
-restore_inferior_pid (void *saved_pid)
+restore_inferior_pid (void *arg)
{
-#if TARGET_PTR_BIT > TARGET_INT_BIT
- inferior_pid = (int) ((long) saved_pid);
-#else
- inferior_pid = (int) saved_pid;
-#endif
+ int *saved_pid_ptr = arg;
+ inferior_pid = *saved_pid_ptr;
+ free (arg);
}
/*
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
[not found] ` <npsnx91szl.fsf@zwingli.cygnus.com>
@ 2000-04-01 0:00 ` Andrew Cagney
0 siblings, 0 replies; 6+ messages in thread
From: Andrew Cagney @ 2000-04-01 0:00 UTC (permalink / raw)
To: Jim Blandy; +Cc: Stephane Carrez, gdb-patches
Jim Blandy wrote:
> > o it gives the user a better experience:
> > (gdb) x/i 0x800000200
> > 0x800000200 <start>: ldi $1, 0
> > (gdb) print &start
> > $1 = 0x800000200
> > vs
> > x/i 0xffffffff800000200
> > 0xffffffff800000200 <start>: ldi $1, 0
> > (gdb) print &start
> > $2 = 0xffffffff800000200
> > at the cost of carrying around wrong
> > information and complicating the target.
>
> But which is the correct address --- 0x0000000080000200, or
> 0xffffffff80000200?
That is target dependant but well defined.
The MIPS ISA/ABI is carefully defined so MIPS2 on MIPS3 et.al. ensures
that the upper 32 bits is signextended from the low 32 bits.
Andrew
From john@feith.com Sat Apr 01 00:00:00 2000
From: John Wehle <john@feith.com>
To: jimb@cygnus.com
Cc: 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: <200003062256.RAA10752@jwlab.FEITH.COM>
X-SW-Source: 2000-q1/msg00548.html
Content-length: 837
Jim Blandy wrote on May 04, 1999:
>> Just curious what the status is of my patch for debugging
>> frame pointerless i386 code. Last we "spoke" (on March 9)
>> Jim B was going to look at it. Is it still in the queue?
>> Are there any issues with it that I need to address?
>
> Yes, I'm still on the spot for this. It's definitely on my queue, and
> towards the top.
>
> I won't reject it without letting you know why. :)
Figured since it's been a few months it was safe to ping you
again regarding the status of this patch. :-)
-- John
-------------------------------------------------------------------------
| Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com |
| John Wehle | Fax: 1-215-540-5495 | |
-------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 6+ messages in thread
* path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
@ 2000-04-01 0:00 Stephane Carrez
[not found] ` <38BB5463.D6E5B75C@cygnus.com>
0 siblings, 1 reply; 6+ messages in thread
From: Stephane Carrez @ 2000-04-01 0:00 UTC (permalink / raw)
To: gdb-patches
Hi!
The following patch fixes GDB dwarf-2 reader to support 16-bit address
targets.
In 'dwarf2_build_psymtabs_hard' there was a hack to guess the size of the
target address. We were using the bfd 'elf_size_info::arch_size' member.
This corresponds to the ELF file arch size, not the target address size.
I suggest to use 'bfd_arch_bits_per_address' which really corresponds to
what we need.
Then, in 'read_address', we just have to read 2-bytes addresses.
I've been using this fix for a while with the 68HC11 port.
Can you integrate it?
Thanks,
Stephane
2000-02-22 Stephane Carrez <stcarrez@worldnet.fr>
* dwarf2read.c (dwarf2_build_psymtabs_hard): Use
bfd_arch_bits_per_address to get the size of addresses.
(read_address): Read 16-bits addresses.
--- /src/gnu/cygnus/gdb/gdb/dwarf2read.c Tue Feb 15 21:42:05 2000
+++ gdb/dwarf2read.c Mon Feb 21 21:17:46 2000
@@ -938,7 +938,7 @@ dwarf2_build_psymtabs_hard (objfile, mai
CORE_ADDR lowpc, highpc;
/* Number of bytes of any addresses that are signficant */
- address_significant_size = get_elf_backend_data (abfd)->s->arch_size / 8;
+ address_significant_size = bfd_arch_bits_per_address (abfd) / 8;
info_ptr = dwarf_info_buffer;
abbrev_ptr = dwarf_abbrev_buffer;
@@ -980,6 +980,7 @@ dwarf2_build_psymtabs_hard (objfile, mai
(long) (beg_of_comp_unit - dwarf_info_buffer));
return;
}
+
if (address_size < address_significant_size)
{
error ("Dwarf Error: bad address size (%ld) in compilation unit header (offset 0x%lx + 11).",
@@ -3487,6 +3488,9 @@ read_address (abfd, buf)
switch (address_size)
{
+ case 2:
+ retval = bfd_get_16 (abfd, (bfd_byte *) buf);
+ break;
case 4:
retval = bfd_get_32 (abfd, (bfd_byte *) buf);
break;
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jimb@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Patch for i386-linux-nat.c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001292235.e0TMZNI01759@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00047.html
Content-length: 21211
Hi Jim,
Here is a patch for i386-linux-nat.c. The main reason for the patch
is to change gregset_t and fpregset_t to elf_gregset_t and
elf_fpregset_t. There were two different definitions of gregset_t and
fpregset_t on Linux, which were quite different from each other. The
next glibc (version 2.1.3) will finaly put an end to this braindamage,
but this will break GDB.
While hacking on the file I noticed that there were quite a number of
inconsistencies in the comments and names of variables. I've gone
over all the comments and rewritten most of them to describe in a more
precise way what they do and to use more consistent terminology. I
know gratitious reformatting is frowned upon, but I honestly think
that this patch makes the file a lot easier to read.
Mark
PS Before christmas I sent a message about a fix to supply_fpregset to
mask of the reserved bits of the FP control registers:
http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00375.html
You promised to look at it, but probably forgot about it. Of course
the patch included in there interferes with the one here. I'll create
a new patch when after this patch has been applied.
2000-01-29 Mark Kettenis <kettenis@gnu.org>
* i386-linux-nat.c: Use elf_gregset_t and elf_fpregset_t instead
of gregset_t and fpregset_t. Those are the only names that are
guaranteed to specify the right types for all supported Linux
systems out there.
Various doc fixes and gratitious local variable renames, all in an
attempt to stress similarities between the code and unify the
terminology used.
(regmap): Remove trailing comma.
(FPREG_ADDR): Renamed from FPREGSET_T_FPREG_ADDR.
(convert_to_gregset): Make static. Remove GDB_REGS argument. It
is unnecessary and wasn't used anyway. All callers changed.
(convert_to_fpregset, convert_to_xfpregset): Likewise.
Index: gdb/i386-linux-nat.c
===================================================================
RCS file: /cvs/gdb/gdb/gdb/i386-linux-nat.c,v
retrieving revision 1.1.1.8
diff -u -r1.1.1.8 i386-linux-nat.c
--- gdb/i386-linux-nat.c 2000/01/18 00:54:14 1.1.1.8
+++ gdb/i386-linux-nat.c 2000/01/29 22:34:40
@@ -20,7 +20,7 @@
#include "inferior.h"
#include "gdbcore.h"
-/* For i386_linux_skip_solib_resolver */
+/* For i386_linux_skip_solib_resolver. */
#include "symtab.h"
#include "frame.h"
#include "symfile.h"
@@ -34,27 +34,40 @@
#include <sys/reg.h>
#endif
-/*
- * Some systems (Linux) may have threads implemented as pseudo-processes,
- * in which case we may be tracing more than one process at a time.
- * In that case, inferior_pid will contain the main process ID and the
- * individual thread (process) id mashed together. These macros are
- * used to separate them out. The definitions may be overridden in tm.h
- */
+/* On Linux, threads are implemented as pseudo-processes, in which
+ case we may be tracing more than one process at a time. In that
+ case, inferior_pid will contain the main process ID and the
+ individual thread (process) ID mashed together. These macros are
+ used to separate them out. These definitions should be overridden
+ if thread support is included. */
#if !defined (PIDGET) /* Default definition for PIDGET/TIDGET. */
-#define PIDGET(PID) PID
-#define TIDGET(PID) 0
+# define PIDGET(PID) PID
+# define TIDGET(PID) 0
#endif
-/* This is a duplicate of the table in i386-xdep.c. */
+/* The register sets used in Linux ELF core-dumps are identical to the
+ register sets in `struct user' that was used for in a.out
+ core-dumps, that is also used by `ptrace'. The corresponding types
+ are `elf_gregset_t' for the general-purpose registers (with
+ `elf_greg_t' the type of a single GP register) and `elf_fpregset_t'
+ for the floating-point registers.
+
+ Those types used to be available under the names `gregset_t' and
+ `fpregset_t' too, and this file used those names in the past. But
+ those names are now used for the register sets used in the
+ `mcontext_t' type, and have a different size and layout. */
+
+
+/* Mapping between the general-purpose registers in `struct user'
+ format and GDB's register file layout. */
static int regmap[] =
{
EAX, ECX, EDX, EBX,
UESP, EBP, ESI, EDI,
EIP, EFL, CS, SS,
- DS, ES, FS, GS,
+ DS, ES, FS, GS
};
@@ -92,40 +105,31 @@
\f
-/* Transfering the general registers between GDB, inferiors and core files. */
+/* Transfering the general-purpose registers between GDB, inferiors
+ and core files. */
-/* Given a pointer to a general register set in struct user format
- (gregset_t *), unpack the register contents and supply them as
- gdb's idea of the current register values. */
+/* Fill GDB's register file with the genereal-purpose register values
+ in *GREGSETP. */
void
-supply_gregset (gregsetp)
- gregset_t *gregsetp;
+supply_gregset (elf_gregset_t *gregsetp)
{
- register int regi;
- register greg_t *regp = (greg_t *) gregsetp;
+ elf_greg_t *regp = (elf_greg_t *) gregsetp;
+ int regi;
for (regi = 0; regi < NUM_GREGS; regi++)
- {
- supply_register (regi, (char *) (regp + regmap[regi]));
- }
+ supply_register (regi, (char *) (regp + regmap[regi]));
}
-/* Fill in a gregset_t object with selected data from a gdb-format
- register file.
- - GREGSETP points to the gregset_t object to be filled.
- - GDB_REGS points to the GDB-style register file providing the data.
- - VALID is an array indicating which registers in GDB_REGS are
- valid; the parts of *GREGSETP that would hold registers marked
- invalid in GDB_REGS are left unchanged. If VALID is zero, all
- registers are assumed to be valid. */
-void
-convert_to_gregset (gregset_t *gregsetp,
- char *gdb_regs,
- signed char *valid)
+/* Convert the valid general-purpose register values in GDB's register
+ file to `struct user' format and store them in *GREGSETP. The
+ array VALID indicates which register values are valid. If VALID is
+ NULL, all registers are assumed to be valid. */
+static void
+convert_to_gregset (elf_gregset_t *gregsetp, signed char *valid)
{
+ elf_greg_t *regp = (elf_greg_t *) gregsetp;
int regi;
- register greg_t *regp = (greg_t *) gregsetp;
for (regi = 0; regi < NUM_GREGS; regi++)
if (! valid || valid[regi])
@@ -133,64 +137,70 @@
}
-/* Store GDB's value for REGNO in *GREGSETP. If REGNO is -1, do all
- of them. */
+/* Fill register REGNO (if it is a general-purpose register) in
+ *GREGSETPS with the value in GDB's register file. If REGNO is -1,
+ do this for all registers. */
void
-fill_gregset (gregset_t *gregsetp,
- int regno)
+fill_gregset (elf_gregset_t *gregsetp, int regno)
{
if (regno == -1)
- convert_to_gregset (gregsetp, registers, 0);
- else if (regno >= 0 && regno < NUM_GREGS)
{
+ convert_to_gregset (gregsetp, NULL);
+ return;
+ }
+
+ if (GETREGS_SUPPLIES (regno))
+ {
signed char valid[NUM_GREGS];
+
memset (valid, 0, sizeof (valid));
valid[regno] = 1;
- convert_to_gregset (gregsetp, registers, valid);
+
+ convert_to_gregset (gregsetp, valid);
}
}
-/* Read the general registers from the process, and store them
- in registers[]. */
+/* Fetch all general-purpose registers from process/thread TID and
+ store their values in GDB's register file. */
static void
fetch_regs (int tid)
{
- int ret, regno;
- gregset_t buf;
+ elf_gregset_t regs;
+ int ret;
- ret = ptrace (PTRACE_GETREGS, tid, 0, (int) &buf);
+ ret = ptrace (PTRACE_GETREGS, tid, 0, (int) ®s);
if (ret < 0)
{
- warning ("Couldn't get registers");
+ warning ("Couldn't get registers.");
return;
}
- supply_gregset (&buf);
+ supply_gregset (®s);
}
-/* Set the inferior's general registers to the values in registers[]
- --- but only those registers marked as valid. */
+/* Store all valid general-purpose registers in GDB's register file
+ into the process/thread specified by TID. */
static void
store_regs (int tid)
{
- int ret, regno;
- gregset_t buf;
+ elf_gregset_t regs;
+ int ret;
- ret = ptrace (PTRACE_GETREGS, tid, 0, (int) &buf);
+ ret = ptrace (PTRACE_GETREGS, tid, 0, (int) ®s);
if (ret < 0)
{
- warning ("Couldn't get registers");
+ warning ("Couldn't get registers.");
return;
}
- convert_to_gregset (&buf, registers, register_valid);
+ convert_to_gregset (®s, register_valid);
- ret = ptrace (PTRACE_SETREGS, tid, 0, (int)buf);
+ ret = ptrace (PTRACE_SETREGS, tid, 0, (int) ®s);
if (ret < 0)
{
- warning ("Couldn't write registers");
+ warning ("Couldn't write registers.");
return;
}
}
@@ -199,20 +209,19 @@
\f
/* Transfering floating-point registers between GDB, inferiors and cores. */
-/* What is the address of st(N) within the fpregset_t structure F? */
-#define FPREGSET_T_FPREG_ADDR(f, n) \
- ((char *) &(f)->st_space + (n) * 10)
+/* What is the address of st(N) within the floating-point register set F? */
+#define FPREG_ADDR(f, n) ((char *) &(f)->st_space + (n) * 10)
/* Fill GDB's register file with the floating-point register values in
*FPREGSETP. */
void
-supply_fpregset (fpregset_t *fpregsetp)
+supply_fpregset (elf_fpregset_t *fpregsetp)
{
- int i;
+ int reg;
/* Supply the floating-point registers. */
- for (i = 0; i < 8; i++)
- supply_register (FP0_REGNUM + i, FPREGSET_T_FPREG_ADDR (fpregsetp, i));
+ for (reg = 0; reg < 8; reg++)
+ supply_register (FP0_REGNUM + reg, FPREG_ADDR (fpregsetp, reg));
supply_register (FCTRL_REGNUM, (char *) &fpregsetp->cwd);
supply_register (FSTAT_REGNUM, (char *) &fpregsetp->swd);
@@ -234,27 +243,21 @@
}
-/* Fill in an fpregset_t structure with selected data from a
- gdb-format register file.
- - FPREGSETP points to the structure to be filled.
- - GDB_REGS points to the GDB-style register file providing the data.
- - VALID is an array indicating which registers in GDB_REGS are
- valid; the parts of *FPREGSETP that would hold registers marked
- invalid in GDB_REGS are left unchanged. If VALID is zero, all
- registers are assumed to be valid. */
-void
-convert_to_fpregset (fpregset_t *fpregsetp,
- char *gdb_regs,
- signed char *valid)
+/* Convert the valid floating-point register values in GDB's register
+ file to `struct user' format and store them in *FPREGSETP. The
+ array VALID indicates which register values are valid. If VALID is
+ NULL, all registers are assumed to be valid. */
+static void
+convert_to_fpregset (elf_fpregset_t *fpregsetp, signed char *valid)
{
- int i;
+ int reg;
/* Fill in the floating-point registers. */
- for (i = 0; i < 8; i++)
- if (!valid || valid[i])
- memcpy (FPREGSET_T_FPREG_ADDR (fpregsetp, i),
- ®isters[REGISTER_BYTE (FP0_REGNUM + i)],
- REGISTER_RAW_SIZE(FP0_REGNUM + i));
+ for (reg = 0; reg < 8; reg++)
+ if (!valid || valid[reg])
+ memcpy (FPREG_ADDR (fpregsetp, reg),
+ ®isters[REGISTER_BYTE (FP0_REGNUM + reg)],
+ REGISTER_RAW_SIZE(FP0_REGNUM + reg));
#define fill(MEMBER, REGNO) \
if (! valid || valid[(REGNO)]) \
@@ -283,68 +286,78 @@
}
-/* Given a pointer to a floating point register set in (fpregset_t *)
- format, update all of the registers from gdb's idea of the current
- floating point register set. */
-
+/* Fill register REGNO (if it is a floating-point register) in
+ *FPREGSETP with the value in GDB's register file. If REGNO is -1,
+ do this for all registers. */
void
-fill_fpregset (fpregset_t *fpregsetp,
- int regno)
+fill_fpregset (elf_fpregset_t *fpregsetp, int regno)
{
- convert_to_fpregset (fpregsetp, registers, 0);
+ if (regno == -1)
+ {
+ convert_to_fpregset (fpregsetp, NULL);
+ return;
+ }
+
+ if (GETFPREGS_SUPPLIES(regno))
+ {
+ signed char valid[MAX_NUM_REGS];
+
+ memset (valid, 0, sizeof (valid));
+ valid[regno] = 1;
+
+ convert_to_fpregset (fpregsetp, valid);
+ }
}
-/* Get the whole floating point state of the process and store the
- floating point stack into registers[]. */
+/* Fetch all floating-point registers from process/thread TID and store
+ thier values in GDB's register file. */
static void
fetch_fpregs (int tid)
{
- int ret, regno;
- fpregset_t buf;
+ elf_fpregset_t fpregs;
+ int ret;
- ret = ptrace (PTRACE_GETFPREGS, tid, 0, (int) &buf);
+ ret = ptrace (PTRACE_GETFPREGS, tid, 0, (int) &fpregs);
if (ret < 0)
{
- warning ("Couldn't get floating point status");
+ warning ("Couldn't get floating point status.");
return;
}
- /* ptrace fills an fpregset_t, so we can use the same function we do
- for core files. */
- supply_fpregset (&buf);
+ supply_fpregset (&fpregs);
}
-/* Set the inferior's floating-point registers to the values in
- registers[] --- but only those registers marked valid. */
+/* Store all valid floating-point registers in GDB's register file
+ into the process/thread specified by TID. */
static void
store_fpregs (int tid)
{
+ elf_fpregset_t fpregs;
int ret;
- fpregset_t buf;
- ret = ptrace (PTRACE_GETFPREGS, tid, 0, (int) &buf);
+ ret = ptrace (PTRACE_GETFPREGS, tid, 0, (int) &fpregs);
if (ret < 0)
{
- warning ("Couldn't get floating point status");
+ warning ("Couldn't get floating point status.");
return;
}
- convert_to_fpregset (&buf, registers, register_valid);
+ convert_to_fpregset (&fpregs, register_valid);
- ret = ptrace (PTRACE_SETFPREGS, tid, 0, (int) &buf);
+ ret = ptrace (PTRACE_SETFPREGS, tid, 0, (int) &fpregs);
if (ret < 0)
{
- warning ("Couldn't write floating point status");
+ warning ("Couldn't write floating point status.");
return;
}
}
+
\f
/* Transfering floating-point and SSE registers to and from GDB. */
-
/* PTRACE_GETXFPREGS is a Cygnus invention, since we wrote our own
Linux kernel patch for SSE support. That patch may or may not
actually make it into the official distribution. If you find that
@@ -353,6 +366,9 @@
you can delete this code. */
#ifdef HAVE_PTRACE_GETXFPREGS
+
+/* Fill GDB's register file with the floating-point and SSE register
+ values in *XFPREGS. */
static void
supply_xfpregset (struct user_xfpregs_struct *xfpregs)
{
@@ -389,9 +405,12 @@
}
+/* Convert the valid floating-point and SSE registers in GDB's
+ register file to `struct user' format and store them in *XFPREGS.
+ The array VALID indicates which registers are valid. If VALID is
+ NULL, all registers are assumed to be valid. */
static void
convert_to_xfpregset (struct user_xfpregs_struct *xfpregs,
- char *gdb_regs,
signed char *valid)
{
int reg;
@@ -437,13 +456,14 @@
}
-/* Make a PTRACE_GETXFPREGS request, and supply all the register
- values that yields to GDB. */
+/* Fetch all registers covered by the PTRACE_SETXFPREGS request from
+ process/thread TID and store their values in GDB's register file.
+ Return non-zero if successful, zero otherwise. */
static int
fetch_xfpregs (int tid)
{
- int ret;
struct user_xfpregs_struct xfpregs;
+ int ret;
if (! have_ptrace_getxfpregs)
return 0;
@@ -457,7 +477,7 @@
return 0;
}
- warning ("couldn't read floating-point and SSE registers.");
+ warning ("Couldn't read floating-point and SSE registers.");
return 0;
}
@@ -466,13 +486,14 @@
}
-/* Send all the valid register values in GDB's register file covered
- by the PTRACE_SETXFPREGS request to the inferior. */
+/* Store all valid registers in GDB's register file covered by the
+ PTRACE_SETXFPREGS request into the process/thread specified by TID.
+ Return non-zero if successful, zero otherwise. */
static int
store_xfpregs (int tid)
{
- int ret;
struct user_xfpregs_struct xfpregs;
+ int ret;
if (! have_ptrace_getxfpregs)
return 0;
@@ -486,11 +507,11 @@
return 0;
}
- warning ("couldn't read floating-point and SSE registers.");
+ warning ("Couldn't read floating-point and SSE registers.");
return 0;
}
- convert_to_xfpregset (&xfpregs, registers, register_valid);
+ convert_to_xfpregset (&xfpregs, register_valid);
if (ptrace (PTRACE_SETXFPREGS, tid, 0, &xfpregs) < 0)
{
@@ -530,26 +551,26 @@
#endif
+
\f
/* Transferring arbitrary registers between GDB and inferior. */
-
-/* Fetch registers from the child process.
- Fetch all if regno == -1, otherwise fetch all ordinary
- registers or all floating point registers depending
- upon the value of regno. */
+/* Fetch register REGNO from the child process. If REGNO is -1, do
+ this for all registers (including the floating point and SSE
+ registers). */
void
fetch_inferior_registers (int regno)
{
- /* linux lwp id's are process id's */
int tid;
+ /* Linux LWP ID's are process ID's. */
if ((tid = TIDGET (inferior_pid)) == 0)
- tid = inferior_pid; /* not a threaded program */
+ tid = inferior_pid; /* Not a threaded program. */
- /* Use the xfpregs requests whenever possible, since they transfer
- more registers in one system call, and we'll cache the results.
- But remember that fetch_xfpregs can fail, and return zero. */
+ /* Use the PTRACE_GETXFPREGS request whenever possible, since it
+ transfers more registers in one system call, and we'll cache the
+ results. But remember that fetch_xfpregs can fail, and return
+ zero. */
if (regno == -1)
{
fetch_regs (tid);
@@ -586,24 +607,20 @@
}
-/* Store our register values back into the inferior.
- If REGNO is -1, do this for all registers.
- Otherwise, REGNO specifies which register, which
- then determines whether we store all ordinary
- registers or all of the floating point registers. */
-
+/* Store register REGNO back into the child process. If REGNO is -1,
+ do this for all registers (including the floating point and SSE
+ registers). */
void
-store_inferior_registers (regno)
- int regno;
+store_inferior_registers (int regno)
{
- /* linux lwp id's are process id's */
int tid;
+ /* Linux LWP ID's are process ID's. */
if ((tid = TIDGET (inferior_pid)) == 0)
- tid = inferior_pid; /* not a threaded program */
+ tid = inferior_pid; /* Not a threaded program. */
- /* Use the xfpregs requests whenever possible, since they transfer
- more registers in one system call. But remember that
+ /* Use the PTRACE_SETXFPREGS requests whenever possibl, since it
+ transfers more registers in one system call. But remember that
store_xfpregs can fail, and return zero. */
if (regno == -1)
{
@@ -626,7 +643,8 @@
return;
/* Either our processor or our kernel doesn't support the SSE
- registers, so just write the FP registers in the traditional way. */
+ registers, so just write the FP registers in the traditional
+ way. */
store_fpregs (tid);
return;
}
@@ -651,26 +669,25 @@
register contents. CORE_REG_SIZE is its size.
WHICH says which register set corelow suspects this is:
- 0 --- the general register set, in gregset format
- 2 --- the floating-point register set, in fpregset format
- 3 --- the extended floating-point register set, in struct
- user_xfpregs_struct format
+ 0 --- the general-purpose register set, in elf_gregset_t format
+ 2 --- the floating-point register set, in elf_fpregset_t format
+ 3 --- the extended floating-point register set, in struct
+ user_xfpregs_struct format
- DUMMY isn't used on Linux. */
+ REG_ADDR isn't used on Linux. */
static void
i386_linux_fetch_core_registers (char *core_reg_sect,
unsigned core_reg_size,
- int which,
- CORE_ADDR dummy)
+ int which, CORE_ADDR reg_addr)
{
- gregset_t gregset;
- fpregset_t fpregset;
+ elf_gregset_t gregset;
+ elf_fpregset_t fpregset;
switch (which)
{
case 0:
if (core_reg_size != sizeof (gregset))
- warning ("wrong size gregset struct in core file");
+ warning ("Wrong size gregset in core file.");
else
{
memcpy (&gregset, core_reg_sect, sizeof (gregset));
@@ -680,7 +697,7 @@
case 2:
if (core_reg_size != sizeof (fpregset))
- warning ("wrong size fpregset struct in core file");
+ warning ("Wrong size fpregset in core file.");
else
{
memcpy (&fpregset, core_reg_sect, sizeof (fpregset));
@@ -691,9 +708,10 @@
#ifdef HAVE_PTRACE_GETXFPREGS
{
struct user_xfpregs_struct xfpregset;
+
case 3:
- if (core_reg_size != sizeof (struct user_xfpregs_struct))
- warning ("wrong size user_xfpregs_struct in core file");
+ if (core_reg_size != sizeof (xfpregset))
+ warning ("Wrong size user_xfpregs_struct in core file.");
else
{
memcpy (&xfpregset, core_reg_sect, sizeof (xfpregset));
@@ -720,6 +738,7 @@
i386_linux_fetch_core_registers, /* core_read_registers */
NULL /* next */
};
+
\f
/* Calling functions in shared libraries. */
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Replace ../include/wait.h with gdb_wait.h.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A244B4.DF8E231C@cygnus.com>
References: <38A12872.13D194C4@cygnus.com> <200002091429.e19ETk916570@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00108.html
Content-length: 676
FYI,
Mark Kettenis wrote:
> There is a problem with `linux-thread.c', where `gdb_wait.h' is included
> before config.h. This means that HAVE_SYS_WAIT_H and HAVE_WAIT_H are
> still undefined and the system headers are never used.
FYI, I've comitted just this bit. Per other e-mail, the rest will
follow.
Andrew
> +#include "defs.h"
> #include <sys/types.h> /* for pid_t */
> #include <sys/ptrace.h> /* for PT_* flags */
> #include "gdb_wait.h" /* for WUNTRACED and __WCLONE flags */
> #include <signal.h> /* for struct sigaction and NSIG */
> #include <sys/utsname.h>
>
> -#include "defs.h"
> #include "target.h"
> #include "inferior.h"
> #include "gdbcore.h"
From nsd@cygnus.com Sat Apr 01 00:00:00 2000
From: nsd@cygnus.com
To: john@feith.com
Cc: cgf@cygnus.com, eliz@delorie.com, gdb-patches@sourceware.cygnus.com, jimb@cygnus.com, msnyder@cygnus.com
Subject: Re: GDB 4.17 Patch for stack aligned i386 code
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003250007.AAA07650@nog.bosbc.com>
References: <200003242355.SAA14221@jwlab.FEITH.COM>
X-SW-Source: 2000-q1/msg01011.html
Content-length: 520
>Are you handling non-leaf functions even when the stack pointer is changing?
Yes. It works by emulating instructions to figure out the stack pointer
on entry to or exit from the function. The opcodes library, with a few
minor changes, provides the instruction information in an
architecture-independent format.
>Does your patch handle functions where the prologue uses "andl" to align
>the frame?
I don't know. Do you happen to have an example of how to generate such
code? I'd be interested in trying it.
Nick
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] Configury changes for IA-64
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000321051613.ZM20603@ocotillo.lan>
References: <1000321003058.ZM20160@ocotillo.lan> <38D6FD73.AEF13B2D@cygnus.com> <ac131313@cygnus.com>
X-SW-Source: 2000-q1/msg00848.html
Content-length: 175
On Mar 21, 3:41pm, Andrew Cagney wrote:
> PS, should the configure.tgt addition appear after ``i960-*''?
Right you are. I'll fix it before checking it in.
Thanks,
Kevin
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>
Cc: elena@cygnus.com
Subject: [MAINT] Expand readline/ maintaners
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C21E40.34CF06CB@cygnus.com>
X-SW-Source: 2000-q1/msg00521.html
Content-length: 1252
FYI,
I've added the following.
Andrew
Sun Mar 5 19:40:27 2000 Andrew Cagney <cagney@b1.cygnus.com>
* MAINTAINERS (readline/): Expand to include host maintainers.
Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.20
diff -p -r1.20 MAINTAINERS
*** MAINTAINERS 2000/03/04 06:27:00 1.20
--- MAINTAINERS 2000/03/05 08:41:50
*************** Core: Generic components used by all of
*** 80,86 ****
generic arch support Andrew Cagney cagney@cygnus.com
target vector Andrew Cagney cagney@cygnus.com
main (main.c, top.c) Elena Zannoni ezannoni@cygnus.com
- readline Elena Zannoni ezannoni@cygnus.com
event loop Elena Zannoni ezannoni@cygnus.com
generic symtabs Jim Blandy jimb@cygnus.com
dwarf readers Jim Blandy jimb@cygnus.com
--- 80,85 ----
*************** mmalloc/ ALL Host maintainers
*** 133,138 ****
--- 132,142 ----
sim/ See sim/MAINTAINERS, co-ordinated by:
Frank Ch. Eigler fche@cygnus.com
+
+ readline/ Master version: ftp://ftp.cwru.edu/pub/bash/
+ Elena Zannoni ezannoni@cygnus.com
+ Host maintainers (host dependant parts)
+ (but get your changes into the master version)
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: msnyder@cygnus.com
Cc: dima@Chg.RU, gdb-patches@sourceware.cygnus.com
Subject: Re: typo in gdb.texinfo
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003160953.EAA01859@indy.delorie.com>
References: <200003151932.WAA39200@netserv1.chg.ru> <38CFE64A.2BBB@cygnus.com>
X-SW-Source: 2000-q1/msg00735.html
Content-length: 482
> 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?
AFAIK, `gdb.ini' is used in the DJGPP version only (Windows does allow
leading dots in file names, but DOS doesn't), and the different name
is explicitly mentioned in the manual, see the nodes "Mode Options"
and "Command Files".
So I don't think we need to hide this name behind a variable, at least
not because of Windows.
From cgf@cygnus.com Sat Apr 01 00:00:00 2000
From: cgf@cygnus.com (Chris Faylor)
To: gdb-patches@sourceware.cygnus.com
Subject: Re: Add support for WinCE toolchains
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <88vbe5$4r5$1@cronkite.cygnus.com>
References: <200002222350.PAA09035@elmo.cygnus.com> <38B32684.530F4F66@apple.com> <200002230024.TAA11216@envy.delorie.com> <38B32E01.34616D70@apple.com>
X-SW-Source: 2000-q1/msg00319.html
Content-length: 1875
In article < 38B32E01.34616D70@apple.com >, Stan Shebs <shebs@apple.com> wrote:
>DJ Delorie wrote:
>>
>> > This should get a special mention in gdb/NEWS, and ideally in README
>> > also; this is one of those situations where you'll be glad you
>> > forestalled a slew of complaints and bug reports by documenting it
>> > in several places.
>>
>> Is it acceptable to add notes to configure, so that if you said
>> "./configure --target=arm-pe" it could print out "Note: if you wanted
>> Windows CE, use arm-wince-pe instead" ? Maybe in the toplevel configure?
>
>My kneejerk is to be unenthusiastic, although I'm not sure why. I guess it
>seems to me that notes in configure should be more about issues that are
>more directly related to the configure script, while in this case (IIRC) the
>differences are more in the sources. But that's a pretty weak theoretical
>argument, and if the extra warning sets even one user on the path of rightness,
>then it's worthwhile to add.
Um. I'm working with Andrew on finalizing the wince stuff. Getting
this checked into sourceware just now is premature. One reason is that
it doesn't work on the ARM yet.
One of the things I've done is to regularize the name of files that I
used. Everything has a "wince" in it now since the WinCE version of PE
is apparently non-standard. I've also moved WinCE-specific code out of
the generic target files into their own files.
If there is going to be a note, it should go in a top-level README. gdb
doesn't currently care if the name of the target is arm-foo-wince. It's
bfd that cares, I believe.
Anyway, I would request that this patch be ignored for now. Andrew will
handle this all in a future merge.
--
cgf@cygnus.com Cygnus Solutions, a Red Hat company
http://sourcware.cygnus.com/ http://www.redhat.com/
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: shebs@shebs.cnchost.com
Cc: dima@Chg.RU, eliz@is.elta.co.il, gdb-patches@sourceware.cygnus.com
Subject: Re: patch for gdb.texinfo
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001281909.e0SJ97M18034@delius.kettenis.local>
References: <200001281642.TAA04176@netserv1.chg.ru> <3891CD13.A68984BA@shebs.cnchost.com>
X-SW-Source: 2000-q1/msg00045.html
Content-length: 1510
Date: Fri, 28 Jan 2000 09:08:52 -0800
From: Stan Shebs <shebs@shebs.cnchost.com>
(Hi everybody!)
Welcome back Stan!
Dmitry Sivachenko wrote:
> I think we should use new features of texinfo. May be in future
> versions typeseting @env and @command will differ from the
> current behaviour. By the way, FreeBSD team already updated
> texinfo to 4.0 in base distribution.
I disagree here. We do have to worry about backward compatibility,
just as we had to support K&R compilers for a long time, and just
as we support many old OS versions. Certainly many GDB users would
be disappointed if we trashed Linux support for any kernel older
than, say, 2.2.5!
Well, it's slightly more complicated than that.
It is standard GNU procedure to include the info files in the
distribution. So the user doesn't need makeinfo when building from an
official release. It is also standard procedure to include
texinfo.tex in the distribution, thus for making a printed manual an
up-to-date texinfo isn't necessary either.
Thus someone who isn't actively hacking on package doesn't need texinfo at
all.
Cygnus might do things a little different. Is GDB still distributed
with texinfo included? The CVS version suggests that this is the
case. Since the version in CVS is older than texinfo 4.0, using new
features would not be very convenient! Maybe it is time for an
upgrade? Because I think that if using new feature improves the
markup we should try to use them.
Mark
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Stephane Carrez <Stephane.Carrez@worldnet.fr>
Cc: gdb-patches@sourceware.cygnus.com, Jim Blandy <jimb@cygnus.com>
Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C225F3.9E236A55@cygnus.com>
References: <38B2F3D3.54CF0AF0@worldnet.fr> <38BB5463.D6E5B75C@cygnus.com> <38C0D9D9.70987863@worldnet.fr>
X-SW-Source: 2000-q1/msg00525.html
Content-length: 1747
Stephane Carrez wrote:
>
> Hi!
>
> Andrew Cagney wrote:
> >
> > As for the change:
> >
> > > - address_significant_size = get_elf_backend_data (abfd)->s->arch_size / 8;
> > > + address_significant_size = bfd_arch_bits_per_address (abfd) / 8;
> >
> > I'm not so sure. Does bfd_arch_bits_per_address() return 16 while the
> > elf data arch_size indicate something else (elf32 vs elf16?)
> >
> > I've attatched some references to when a similar problem was discussed
> > for a 64 bit target with 32 bit ELF binaries.
> >
> > Jim?
> >
> > Andrew
> >
> > http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00267.html
> > http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00263.html
> >
> Yes
>
> It returns the value held by the cpu-* bfd_arch_info_type structure:
>
> return abfd->arch_info->bits_per_address;
>
> So, it's not related to the ELF format but really concerns the CPU address.
> The mips architecture is able to return either 32 or 64 depending on
> the CPU flavor.
>
> From: Andrew Cagney <ac131313 at cygnus dot com>:
> > Is there a way of determining if an object file is 32 or 64 bit? (eg
> > elf32/elf64, aout32 vs aout64).
> > Perhaphs bfd_arch_bits_per_address(ABFD) is correct?
> I think it's not correct but you should rather do:
>
> get_elf_backend_data (abfd)->s->arch_size
>
> elf16 is not a good idea. I think we must not mix the size of cpu
> address with the format of ELF files. The ELF file can be larger than
> 64K and we might need indexes larger than 16-bit.
When I say ``elf16'', I was thinking of an elf object file that has 16
bit addresses. I'm not sure what other consequences such a move would
have.
Is there any reason why s->arch_size isn't 16 in your case?
Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Stephane Carrez <Stephane.Carrez@worldnet.fr>, gdb-patches@sourceware.cygnus.com
Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E06721.6D3A08CD@cygnus.com>
References: <38D4DCB0.88313CB2@worldnet.fr> <38D5B6E0.50FF6A5E@cygnus.com> <38D68C56.856CB00C@worldnet.fr> <38D74A9E.A85ED8EC@cygnus.com> <38D7E6BC.79543EBA@worldnet.fr> <npd7og40xc.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg01079.html
Content-length: 1991
Jim Blandy wrote:
> Or maybe I'm misunderstanding things. Andrew, as the committer of
> this change, can you comment?
From something in '97, I'll try :-)
> Mon Dec 15 11:38:52 1997 Andrew Cagney <cagney@b1.cygnus.com>
>
> * dwarf2read.c: From change proposed by Gavin Koch.
> (address_significant_size): New static variable.
> (dwarf2_build_psymtabs_hard): Check consistency between
> `address_size' and `address_significant_size'.
> (read_address): MASK out all but the significant bits, as
> determined by `address_significant_size', of any addresses.
> (elf-bfd.h): Include.
> (dwarf2_build_psymtabs_hard): Set `address_significant_size'
> according to the arch_size of the elf object file.
I believe it is for an embedded 64 bit mips target (o64?) that is using
64 bit addresses within an elf32 executable. (but the addresses are
assumed to be 32bit sign extended). Due to elf32, some debug info is 64
bits, but other (symbol table?) is only 32 bits.
The mask has two effects:
o it makes data from the two tables
match.
o it gives the user a better experience:
(gdb) x/i 0x800000200
0x800000200 <start>: ldi $1, 0
(gdb) print &start
$1 = 0x800000200
vs
x/i 0xffffffff800000200
0xffffffff800000200 <start>: ldi $1, 0
(gdb) print &start
$2 = 0xffffffff800000200
at the cost of carrying around wrong
information and complicating the target.
As for ``fixing'' it.
One part is deprecating that object file format and changing it to
elf64. I believe that, at the time the above format was created, BFD
didn't support elf64.
Also on the list is getting GDB to provide the above experience without
having the internal structures lie (ie have symtab contain correct
information). This is likely to be important any way as people are
starting to work on the problem of a single GDB being able to debug both
elf32 and elf64 binaries.
I think I've got this right :-/
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: GDB 5 2000-03-29
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E17D2C.F7EB65B9@cygnus.com>
X-SW-Source: 2000-q1/msg01102.html
Content-length: 6421
Below is my updated TODO list for GDB 5. I've also attatched the patch
I'm applying to TODO. You can see the gory details in the sources.
Looking at it. There are four ``must haves'' left.
For the watchpoint patches, if at least some have been addressed, I'd
like to put the rest off.
For Solaris/x86, what shape is it in?
The remainder look like must fix bugs.
Andrew
GDB 5.0: Must have
------------------
These are things that have been identifed as must-have for this
release of GDB.
--
Watch point related patches (Eli Zaretskii, Michael Snyder, ???)
Eli writes: This doesn't include the watchpoint-related patches I sent
beginning with August or September, and mentioned them again three
weeks ago. Here again are the pointers to the relevant messages:
Hardware breakpoints and watchpoints: patches
http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00173.html
Re: Hardware breakpoints and watchpoints: patches
http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00204.html
Re: Hardware breakpoints and watchpoints: patches
http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00200.html
Hardware watchpoints for bitfields
http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00201.html
--
Tom's speedups to GDB (Tom Tromey, Jim Blandy)
I believe that there was a late breaking fix that stopped a coredump.
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00869.html
--
Solaris/x86 - which? (Nick Duffek, Peter Schauer, Michael Snyder?)
Nick D's working through patches from Michael Snyder and Peter S.
--
RFA: procfs.c: init_procfs_ops should set
procfs_ops.to_has_[all]_memory (Peter Schauer, Andrew Cagney?)
I am pretty sure that this is caused by some accidental deletion, but
procfs.c:init_procfs_ops no longer sets procfs_ops.to_has_memory and
procfs_ops.to_has_all_memory.
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg01057.html
Wed Mar 29 13:40:40 2000 Andrew Cagney <cagney@b1.cygnus.com>
* TODO: Update GDB 5 status.
Index: TODO
===================================================================
RCS file: /cvs/src/src/gdb/TODO,v
retrieving revision 1.2
diff -u -r1.2 TODO
--- TODO 2000/03/27 10:24:58 1.2
+++ TODO 2000/03/29 03:43:21
@@ -62,26 +62,18 @@
--
-Texinfo broken/builds (Andrew Cagney, Stan Shebs)
-Cagney probably botched a fix to a botch.
+RFA: procfs.c: init_procfs_ops should set
+procfs_ops.to_has_[all]_memory (Peter Schauer, Andrew Cagney?)
---
+I am pretty sure that this is caused by some accidental deletion, but
+procfs.c:init_procfs_ops no longer sets procfs_ops.to_has_memory and
+procfs_ops.to_has_all_memory.
-x86 linux GDB and SIGALRM
- http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg01057.html
--
-RFA: breakpoint.c: Minor output fixes for hardware watchpoints
- http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00558.html
-
-During implementation of hardware watchpoints on Solaris, I noticed the
-following inconsistencies in breakpoint.c output between software and
-hardware breakpoints.
-
---
-
GDB 5.0: Nice to have
---------------------
@@ -126,6 +118,12 @@
The pascal support patches nave been added to the patch data base. I
[cagney] strongly suspect that they are better suited for 5.1.
+Indent -gnu ?
+ http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00496.html
+
+2 pascal language patches inserted in database
+ http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00521.html
+
--
Programs run under GDB have SIGCHLD masked.
@@ -198,6 +196,39 @@
--
+x86 linux GDB and SIGALRM (???)
+ http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html
+
+--
+
+Migrate qfThreadInfo packet -> qThreadInfo. (Andrew Cagney)
+
+Add support for packet enable/disable commands with these thread
+packets. General cleanup.
+
+[PATCH] Document the ThreadInfo remote protocol queries
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00832.html
+
+[PATCH] "info threads" queries for remote.c
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00831.html
+
+--
+
+MI documentation in GDB user guide. (Andrew Cagney, Elena Zannoni,
+Stan Shebs, anyone else?)
+
+> (Are there plans to make gdbmi.texi be part of the manual as well?)
+
+I'd like to see it go in there sooner rather than later too. Otherwise
+you're introducing discrepancies between the manual and the documentation,
+and everybody is confused - witness the lack of doc for the tracing
+commands still, some two years after they were added...
+
+[PATCH] GDB command-line switches and annotations docs
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00639.html
+
+--
+
GDB 5.0: Won't have
-------------------
@@ -232,6 +263,33 @@
--
+Elimination of make_cleanup_func. (Andrew Cagney)
+
+make_cleanup_func elimination
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00791.html
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00814.html
+
+--
+
+Allow GDB to use installed regex. Think about updating regex to more
+recent version (Andrew Cagney).
+
+Re: A new patch for regex
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00635.html
+
+A patch for gnu-regex
+ http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00568.html
+
+--
+
+ChangeLog.mi vs ChangeLog-mi (Andrew Cagney)
+Needs further debate.
+
+Re: [PATCH] Add change-log variables to more MI files
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00811.html
+
+--
+
GDB 5.0: Test results
---------------------
@@ -329,6 +387,30 @@
General Wish List
=================
+
+--
+
+GDBARCH cleanup (Andrew Cagney)
+
+The non-generated parts of gdbarch.{sh,h,c} should be separated out
+into gdbarch-utils.[hc] (Name ok).
+
+The ``info architecture'' command should be replaced with a fixed
+``set architecture'' (implemented using the command.c enum code).
+
+Document that gdbarch_init_ftype could easily fail because it didn't
+identify an architecture.
+
+--
+
+Check that GDB can handle all BFD architectures (Andrew Cagney)
+
+There should be a test that checks that BFD/GDB are in sync with
+regard to architecture changes. Something like a test that first
+queries GDB for all supported architectures and then feeds each back
+to GDB.. Anyone interested in learning how to write tests? :-)
+
+--
This list is probably not up to date, and opinions vary about the
importance or even desirability of some of the items.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [MAINT] src/mmalloc maintainers
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B9BF29.19152928@cygnus.com>
References: <38B35300.41508CB6@cygnus.com>
X-SW-Source: 2000-q1/msg00388.html
Content-length: 4258
Andrew Cagney wrote:
>
> Hello,
>
> This directory is probably best described as one of GDB's forgotten
> siblings. At present it isn't clear what the maintenance policy is.
> With that in mind I'd like to propose:
>
> GDB's host/native maintainers have implicit check-in
> rights to the src/mmalloc tree. If there isn't a
> relevant host/native maintainer than the head maintainer
> ends up with the problem :-)
>
> I can't see anyone doing anything to that directory tree unless they are
> a native/host maintainer and then the only thing would be fixing
> configury problems.
>
> I'm almost tempted to include target maintainers. I suspect, however,
> that getting the native expert a chance to look things over would be
> safer.
>
> thoughts?
FYI, I've checked in the attatched. It hopefully reflects this
proposal.
Andrew
Index: gdb/ChangeLog
Mon Feb 28 10:58:45 2000 Andrew Cagney <cagney@b1.cygnus.com>
* MAINTAINERS: Mention mmalloc. Expand Host/Native and
Target/Architecture maintainers descriptions.
Index: mmalloc/ChangeLog
Mon Feb 28 10:33:51 2000 Andrew Cagney <cagney@b1.cygnus.com>
* MAINTAINERS: New file.
Index: gdb/MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.11
diff -p -r1.11 MAINTAINERS
*** MAINTAINERS 2000/02/26 06:20:56 1.11
--- MAINTAINERS 2000/02/28 00:06:00
*************** available to step in if the first mainta
*** 21,29 ****
reason.
! Target/Architecture: Generic ISA - Instruction Set Architecture -
! issues. API variants, CPU variants. *-tdep.c.
d10v target Andrew Cagney cagney@cygnus.com
d30v target Andrew Cagney cagney@cygnus.com
mips target Andrew Cagney cagney@cygnus.com
--- 21,32 ----
reason.
! Target/Architecture:
+ Generic ISA (Instruction Set Architecture) issues, API variants, CPU
+ variants. *-tdep.c. The Target/Architecture maintainer works with the
+ host maintainer when resolving build issues.
+
d10v target Andrew Cagney cagney@cygnus.com
d30v target Andrew Cagney cagney@cygnus.com
mips target Andrew Cagney cagney@cygnus.com
*************** arm target Fernando Nasser fnasser@cyg
*** 36,47 ****
m32r target Michael Snyder msnyder@cygnus.com
IA-64 target Kevin Buettner kevinb@cygnus.com
! Host/Native: Target specific native support - typically shared
! libraries and quirks to procfs/ptrace/... A native maintainer works
! with the arch and core maintainer when resolving more generic
! problems.
hp testsuite (gdb.hp) Jimmy Guo adl-debugger-wdb-merge-guru@cup.hp.com
djgpp native Eli Zaretskii eliz@gnu.org
DJ Delorie dj@cygnus.com
--- 39,55 ----
m32r target Michael Snyder msnyder@cygnus.com
IA-64 target Kevin Buettner kevinb@cygnus.com
+
+ Host/Native:
! The Native maintainer is responsible for target specific
! native support - typically shared libraries and quirks to
! procfs/ptrace/... The Native maintainer works with the Arch and Core
! maintainers when resolving more generic problems.
+ The host maintainer ensures that gdb (including mmalloc) can be built
+ as a cross debugger on their platform.
+
hp testsuite (gdb.hp) Jimmy Guo adl-debugger-wdb-merge-guru@cup.hp.com
djgpp native Eli Zaretskii eliz@gnu.org
DJ Delorie dj@cygnus.com
*************** Misc:
*** 105,111 ****
Web pages. Jim Kingdon kingdon@redhat.com
(anyone can edit; kingdon is just lead maintainer)
Makefile.in, configure* ALL
!
Write After Approval
--- 113,119 ----
Web pages. Jim Kingdon kingdon@redhat.com
(anyone can edit; kingdon is just lead maintainer)
Makefile.in, configure* ALL
! mmalloc ALL Host maintainers
Write After Approval
Index: mmalloc/MAINTAINERS
===================================================================
RCS file: MAINTAINERS
diff -N MAINTAINERS
*** /dev/null Tue May 5 13:32:27 1998
--- MAINTAINERS Sun Feb 27 16:06:09 2000
***************
*** 0 ****
--- 1,5 ----
+ The mmalloc directory is maintained by the GDB group's Host
+ maintainers.
+
+ This code is in a maintain-only phase - only configury patches fixing
+ host compile problems are generally accepted.
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: Fernando Nasser <fnasser@redhat.com>, Kevin Buettner <kevinb@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: store_floating() and arm-tdep.c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C7F23D.61AF@cygnus.com>
References: <1000229000345.ZM15006@ocotillo.lan> <38BCE46B.CD7889B5@cygnus.com> <1000302074643.ZM19182@ocotillo.lan> <38C7BF53.731F8CF6@redhat.com> <38C7C9A4.3566EC87@netwinder.org>
X-SW-Source: 2000-q1/msg00630.html
Content-length: 986
Scott Bambrough wrote:
>
> Fernando Nasser wrote:
>
> > Now that Kevin fixed store_floating() we can use it in arm-tdep.c (as
> > well as extract_floating). The code in there works fine for remote
> > targets but Scott has reported it fails for native Linux-ARM.
>
> I'll be looking into this today. Don't worry about it.
>
> > P.S.: I can run the test on remote ARM targets. I will need someone to
> > volunteer running the tests on native as well? Scott, I guess you are
> > the most appropriate "volunteer" :-)
>
> I've been running tests on the ARM Linux target on a NetWinder regularly. The
> results of the testsuite follow. Most of the problems are due to no
> linuxthreads support and problems stepping in/out or backtracing in signal
> handlers. I'll work at implementing support for these over time. I was hoping
> to port the x86 work, but just haven't had the time.
Hmm, the new thread_db module should be pretty
target-independent (correct me if I'm wrong).
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [GDB-MAINT] Updated maintainer list
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A3A58E.CDB11CE9@cygnus.com>
X-SW-Source: 2000-q1/msg00122.html
Content-length: 3448
Hello maintainers,
Below is the current list of maintainers. As such, you will all be
getting check-in rights (adminstration and time permitting).
Given the move to a public CVS repository now is probably a good time to
review your current maintenance responsibilities and decide if you wish
to continue them. I'm not trying to scare you or anything :-) It's just
that this really is a big and dramatic change.
d10v target Andrew Cagney cagney at cygnus dot com
d30v target Andrew Cagney cagney at cygnus dot com
mips target Andrew Cagney cagney at cygnus dot com
mn10300 target Andrew Cagney cagney at cygnus dot com
powerpc target Elena Zannoni ezannoni at cygnus dot com
arm target Jim Ingham jingham at cygnus dot com
m32r target Michael Snyder msnyder at cygnus dot com
hp testsuite (gdb.hp) Jimmy Guo adl-debugger-wdb-merge-guru at cup dot
hp dot com
djgpp native DJ Delorie dj at cygnus dot com
win32 host & native Chris Faylor cgf at cygnus dot com
x86 linux native Jim Blandy jimb at cygnus dot com
hurd native Mark Kettenis kettenis at wins.va.nl
macos host & native Stan Shebs shebs at apple dot com
hpux, hp pa native Jeff Law law at cygnus dot com
generic arch support Andrew Cagney cagney at cygnus dot com
target vector Andrew Cagney cagney at cygnus dot com
main (main.c, top.c) Elena Zannoni ezannoni at cygnus dot com
readline Elena Zannoni ezannoni at cygnus dot com
generic symtabs Jim Blandy jimb at cygnus dot com
dwarf readers Jim Blandy jimb at cygnus dot com
elf reader Jim Blandy jimb at cygnus dot com
stabs reader Jim Blandy jimb at cygnus dot com
tracing Michael Snyder msnyder at cygnus dot com
threads Michael Snyder msnyder at cygnus dot com
breakpoint.c Michael Snyder msnyder at cygnus dot com
language support David Taylor taylor at cygnus dot com
expression eval David Taylor taylor at cygnus dot com
defs.h David Taylor taylor at cygnus dot com
utils.c David Taylor taylor at cygnus dot com
Scheme support Jim Blandy jimb at cygnus dot com
svr4 shlibs (solib.c) Jim Blandy jimb at cygnus dot com
coff reader Philippe De Muyter phdm at macqel dot be
remote.c Andrew Cagney cagney at cygnus dot com
sds protocol Stan Shebs shebs at apple dot com
rdi/adp protocol Stan Shebs shebs at apple dot com
gdbserver Stan Shebs shebs at apple dot com
documentation Stan Shebs shebs at apple dot com
testsuite Stan Shebs shebs at apple dot com
command interpreter Fernando Nasser fnasser at cygnus dot com
gdbtk (c & tcl) Jim Ingham jingham at cygnus dot com
libgui (w/foundry, sn) Jim Ingham jingham at cygnus dot com
For what its worth, I've already received recommendations that:
djgpp responsibility be transfered to Eli Zaretskii. (Eli, I assume
this
is ok with you. You were presented with glowing references :-)
GNU/Linux/PPC responsibility go to Kevin Buettner. Given Kevin's
currently
frantically trying to get that code merged in I can't see any problems.
(actually, all I can see are benefits :-).
powerpc target be transfered to Kevin Buettner. Here it's Elena
Zannoni,
the current maintainer looking to pass on the reins. I can't see
problems as Kevin is already knee deep in the AIX ABI code that
is just one of the three ABI's burried in rs6000-tdep.c.
I personaly would like to ask J.T. Conklin (jtc at redback dot com) to
step forward and (at least) accept check-in after aproval rights.
enjoy,
Andrew
From dima@Chg.RU Sat Apr 01 00:00:00 2000
From: Dmitry Sivachenko <dima@Chg.RU>
To: gdb-patches@sourceware.cygnus.com
Subject: small patch to gdb.texinfo
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001301823.VAA60148@netserv1.chg.ru>
X-SW-Source: 2000-q1/msg00051.html
Content-length: 5976
Hello again!
(I really don't what to spam your mailing list :)
This new small patch to revision 1.1.1.14 of gdb.texinfo, cosmetic changes
only. Please apply it.
Thank you in advance,
--dima
PS: I don't sure about mapped symbol file name, please check it, I have no
support of it on my FreeBSD box...
--- gdb.texinfo.orig Sun Jan 30 21:01:45 2000
+++ gdb.texinfo Sun Jan 30 21:06:00 2000
@@ -225,9 +225,9 @@
from anyone else.
@node Contributors
-@unnumberedsec Contributors to GDB
+@unnumberedsec Contributors to @value{GDBN}
-Richard Stallman was the original author of GDB, and of many other
+Richard Stallman was the original author of @value{GDBN}, and of many other
@sc{gnu} programs. Many others have contributed to its development.
This section attempts to credit major contributors. One of the virtues
of free software is that everyone is free to contribute to it; with
@@ -258,7 +258,7 @@
Richard Stallman, assisted at various times by Peter TerMaat, Chris
Hanson, and Richard Mlynarik, handled releases through 2.8.
-Michael Tiemann is the author of most of the @sc{gnu} C++ support in GDB,
+Michael Tiemann is the author of most of the @sc{gnu} C++ support in @value{GDBN},
with significant additional contributions from Per Bothner. James
Clark wrote the @sc{gnu} C++ demangler. Early work on C++ was by Peter
TerMaat (who also did much general update work leading to release 3.0).
@@ -325,7 +325,7 @@
Matsushita sponsored the support for the MN10200 and MN10300 processors.
-Fujitsu sponsored the support for SPARClite and FR30 processors
+Fujitsu sponsored the support for SPARClite and FR30 processors.
Kung Hsu, Jeff Law, and Rick Sladkey added support for hardware
watchpoints.
@@ -335,7 +335,7 @@
Stu Grossman wrote gdbserver.
Jim Kingdon, Peter Schauer, Ian Taylor, and Stu Grossman made
-nearly innumerable bug fixes and cleanups throughout GDB.
+nearly innumerable bug fixes and cleanups throughout @value{GDBN}.
The following people at the Hewlett-Packard Company contributed
support for the PA-RISC 2.0 architecture, HP-UX 10.20, 10.30, and 11.0
@@ -345,8 +345,8 @@
Rehrauer, and Elena Zannoni. Kim Haase provided HP-specific
information in this manual.
-Cygnus Solutions has sponsored GDB maintenance and much of its
-development since 1991. Cygnus engineers who have worked on GDB
+Cygnus Solutions has sponsored @value{GDBN} maintenance and much of its
+development since 1991. Cygnus engineers who have worked on @value{GDBN}
fulltime include Mark Alexander, Jim Blandy, Per Bothner, Kevin
Buettner, Edith Epstein, Chris Faylor, Fred Fish, Martin Hunt, Jim
Ingham, John Gilmore, Stu Grossman, Kung Hsu, Jim Kingdon, John Metzler,
@@ -695,7 +695,7 @@
``process'', and there is often no way to get a core dump. @value{GDBN}
will warn you if it is unable to attach or to read core dumps.
-You can run @code{gdb} without printing the front material, which describes
+You can run @code{@value{GDBP}} without printing the front material, which describes
@value{GDBN}'s non-warranty, by specifying @code{-silent}:
@smallexample
@@ -789,7 +789,7 @@
system call, you can use this option
to have @value{GDBN} write the symbols from your
program into a reusable file in the current directory. If the program you are debugging is
-called @file{/tmp/fred}, the mapped symbol file is @file{./fred.syms}.
+called @file{/tmp/fred}, the mapped symbol file is @file{/tmp/fred.syms}.
Future @value{GDBN} debugging sessions notice the presence of this file,
and can quickly map in symbol information from it, rather than reading
the symbol table from the executable program.
@@ -859,7 +859,7 @@
@item -nowindows
@itemx -nw
``No windows''. If @value{GDBN} comes with a graphical user interface
-(GUI) built in, then this option tells GDB to only use the command-line
+(GUI) built in, then this option tells @value{GDBN} to only use the command-line
interface. If no GUI is available, this option has no effect.
@item -windows
@@ -916,7 +916,7 @@
@table @code
@kindex quit @r{[}@var{expression}@r{]}
@kindex q
-@item quit
+@item quit @r{[}@var{expression}@r{]}
To exit @value{GDBN}, use the @code{quit} command (abbreviated @code{q}), or
type an end-of-file character (usually @kbd{C-d}). If you do not supply
@var{expression}, @value{GDBN} will terminate normally; otherwise it will
@@ -986,7 +986,7 @@
arguments whose meaning depends on the command name. For example, the
command @code{step} accepts an argument which is the number of times to
step, as in @samp{step 5}. You can also use the @code{step} command
-with no arguments. Some command names do not allow any arguments.
+with no arguments. Some commands do not allow any arguments.
@cindex abbreviation
@value{GDBN} command names may always be truncated if that abbreviation is
@@ -1000,7 +1000,7 @@
@cindex repeating commands
@kindex RET
A blank line as input to @value{GDBN} (typing just @key{RET}) means to
-repeat the previous command. Certain commands (for example, @code{run})
+repeat the previous command. Certain commands (for example, @code{run})
will not repeat this way; these are commands whose unintentional
repetition might cause trouble and which you are unlikely to want to
repeat.
@@ -1289,7 +1289,7 @@
version of @value{GDBN} you are running; as @value{GDBN} evolves, new
commands are introduced, and old ones may wither away. Also, many
system vendors ship variant versions of @value{GDBN}, and there are
-variant versions of @value{GDBN} in GNU/Linux distributions as well.
+variant versions of @value{GDBN} in @sc{gnu}/Linux distributions as well.
The version number is the same as the one announced when you start
@value{GDBN}.
@@ -1300,7 +1300,7 @@
@kindex show warranty
@item show warranty
Display the @sc{gnu} ``NO WARRANTY'' statement, or a warranty,
-if your version of @value{GDB} comes with one.
+if your version of @value{GDBN} comes with one.
@end table
From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: David Whedon <davidw@gordian.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [REPOST #2] patch: command deprecator
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14554.39919.562287.915864@kwikemart.cygnus.com>
References: <Pine.BSF.3.96.1000229114028.22997B-100000@ares.gordian.com> <38DA9AE8.64AF8635@cygnus.com>
X-SW-Source: 2000-q1/msg00951.html
Content-length: 432
Fernando Nasser writes:
> Andrew,
>
> I know that there are 3 new functions (and one test proc) in David's patch and it represents an added functionality, but
> the changes are not so big. Is there any chance that we could safely include those without his assignment?
>
> David: Maybe you got it (the assignment to FSF) already?
>
I saw David's name in the last assignments mail form the FSF. So he's
all set.
Elena
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
[not found] ` <38C225F3.9E236A55@cygnus.com>
@ 2000-03-28 8:24 ` Jim Blandy
0 siblings, 0 replies; 6+ messages in thread
From: Jim Blandy @ 2000-03-28 8:24 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Stephane Carrez, gdb-patches, Jim Blandy
> > elf16 is not a good idea. I think we must not mix the size of cpu
> > address with the format of ELF files. The ELF file can be larger than
> > 64K and we might need indexes larger than 16-bit.
>
> When I say ``elf16'', I was thinking of an elf object file that has 16
> bit addresses. I'm not sure what other consequences such a move would
> have.
>
> Is there any reason why s->arch_size isn't 16 in your case?
s->arch_size is not an especially meaningful field. It exists only to
indicate whether you've got an ELF32 or ELF64 format file.
I think inventing a new ELF16 file format is a bad idea. There are a
zillion things to take into account. It's much simpler to just use
ELF32, and only link things into the lower 64k, which is what
we've done with other 16-bit processors in the past.
If you want to know the actual processor address size, there's a
different BFD field whose job is to provide that information. That's
bfd_arch_bits_per_address, which Stephane suggested we use instead.
In general, the change that has dwarf2read checking the ELF backend
data has just been a pain from day one. I remember fixing related
dependency problems, people on the binutils list saying "This looks
really wrong," and so on. GDB shouldn't be using internal BFD
headers, and consulting internal ELF BFD data structures.
I also buy Jim Kingdon's argument that it shouldn't be necessary to
mask off the upper bits. The data in the ELF file should be correct.
I'm going to revert the change which introduced
address_significant_size in the first place. If this causes problems,
then we'll fix the bug correctly.
From jimb@zwingli.cygnus.com Tue Mar 28 08:24:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] Don't trim addresses in Dwarf debug info
Date: Tue, 28 Mar 2000 08:24:00 -0000
Message-id: <200003281624.LAA23161@zwingli.cygnus.com>
X-SW-Source: 2000-03/msg00645.html
Content-length: 4499
I've committed this:
2000-03-27 Jim Blandy <jimb@redhat.com>
* dwarf2read.c: Revert Andrew Cagney's change of Dec 15, 1997.
Don't include "bfd-elf.h".
(address_significant_size): Delete variable.
(dwarf2_build_psymtabs_hard): Don't set it, or check for
consistency between it and the Dwarf 2 compilation unit header
address size.
(read_address): Don't mask off bits above
address_significant_size.
* Makefile.in (dwarf2read.o): Don't depend on $(elf_bfd_h).
(elf_bfd_h): Remove variable; it's no longer used.
Index: gdb/dwarf2read.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/dwarf2read.c,v
retrieving revision 2.37
diff -c -r2.37 dwarf2read.c
*** gdb/dwarf2read.c 2000/02/29 07:14:21 2.37
--- gdb/dwarf2read.c 2000/03/27 20:50:09
***************
*** 27,33 ****
#include "defs.h"
#include "bfd.h"
- #include "elf-bfd.h"
#include "symtab.h"
#include "gdbtypes.h"
#include "symfile.h"
--- 27,32 ----
***************
*** 546,560 ****
whatever scope is currently getting read. */
static int address_size;
- /* Some elf32 object file formats while linked for a 32 bit address
- space contain debug information that has assumed 64 bit
- addresses. Eg 64 bit MIPS target produced by GCC/GAS/LD where the
- symbol table contains 32bit address values while its .debug_info
- section contains 64 bit address values.
- ADDRESS_SIGNIFICANT_SIZE specifies the number significant bits in
- the ADDRESS_SIZE bytes read from the file */
- static int address_significant_size;
-
/* Externals references. */
extern int info_verbose; /* From main.c; nonzero => verbose */
--- 545,550 ----
***************
*** 937,945 ****
int comp_unit_has_pc_info;
CORE_ADDR lowpc, highpc;
- /* Number of bytes of any addresses that are signficant */
- address_significant_size = get_elf_backend_data (abfd)->s->arch_size / 8;
-
info_ptr = dwarf_info_buffer;
abbrev_ptr = dwarf_abbrev_buffer;
--- 927,932 ----
***************
*** 980,992 ****
(long) (beg_of_comp_unit - dwarf_info_buffer));
return;
}
- if (address_size < address_significant_size)
- {
- error ("Dwarf Error: bad address size (%ld) in compilation unit header (offset 0x%lx + 11).",
- (long) cu_header.addr_size,
- (long) (beg_of_comp_unit - dwarf_info_buffer));
- }
-
/* Read the abbrevs for this compilation unit into a table */
dwarf2_read_abbrevs (abfd, cu_header.abbrev_offset);
make_cleanup (dwarf2_empty_abbrev_table, NULL);
--- 967,972 ----
***************
*** 3499,3516 ****
default:
/* *THE* alternative is 8, right? */
abort ();
- }
- /* If the address being read is larger than the address that is
- applicable for the object file format then mask it down to the
- correct size. Take care to avoid unnecessary shift or shift
- overflow */
- if (address_size > address_significant_size
- && address_significant_size < sizeof (CORE_ADDR))
- {
- CORE_ADDR mask = ((CORE_ADDR) 0) - 1;
- retval &= ~(mask << (address_significant_size * 8));
}
! return retval;
}
static char *
--- 3479,3487 ----
default:
/* *THE* alternative is 8, right? */
abort ();
}
!
! return retval;
}
static char *
Index: gdb/Makefile.in
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/Makefile.in,v
retrieving revision 1.760
diff -c -r1.760 Makefile.in
*** gdb/Makefile.in 2000/03/20 04:36:02 1.760
--- gdb/Makefile.in 2000/03/27 20:50:10
***************
*** 507,513 ****
getopt_h = $(INCLUDE_DIR)/getopt.h
floatformat_h = $(INCLUDE_DIR)/floatformat.h
bfd_h = $(BFD_DIR)/bfd.h
- elf_bfd_h = $(BFD_SRC)/elf-bfd.h
dis-asm_h = $(INCLUDE_DIR)/dis-asm.h
remote-sim_h = $(INCLUDE_DIR)/remote-sim.h
--- 507,512 ----
***************
*** 1251,1257 ****
$(expression_h) $(gdbtypes_h) language.h objfiles.h symfile.h \
$(symtab_h) gdb_string.h
! dwarf2read.o: dwarf2read.c $(bfd_h) $(elf_bfd_h) buildsym.h $(defs_h) \
$(expression_h) $(gdbtypes_h) language.h objfiles.h symfile.h \
$(symtab_h) gdb_string.h
--- 1250,1256 ----
$(expression_h) $(gdbtypes_h) language.h objfiles.h symfile.h \
$(symtab_h) gdb_string.h
! dwarf2read.o: dwarf2read.c $(bfd_h) buildsym.h $(defs_h) \
$(expression_h) $(gdbtypes_h) language.h objfiles.h symfile.h \
$(symtab_h) gdb_string.h
From jimb@zwingli.cygnus.com Tue Mar 28 08:26:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Jim Kingdon <kingdon@redhat.com>, Stephane Carrez <Stephane.Carrez@worldnet.fr>, gdb-patches@sourceware.cygnus.com, Jim Blandy <jimb@cygnus.com>
Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
Date: Tue, 28 Mar 2000 08:26:00 -0000
Message-id: <npk8in2h8y.fsf@zwingli.cygnus.com>
References: <38B2F3D3.54CF0AF0@worldnet.fr> <38BB5463.D6E5B75C@cygnus.com> <38C0D9D9.70987863@worldnet.fr> <38C225F3.9E236A55@cygnus.com> <bput8j8vi.fsf@rtl.cygnus.com> <38C737EE.513259B9@cygnus.com>
X-SW-Source: 2000-03/msg00646.html
Content-length: 1204
> > The whole address_significant_size code in dwarf2read.c strikes me as
> > a rather ugly kludge to work around bugs elsewhere in the tool chain.
> > If someone is supplying a 32 bit pointer to GDB on a 16 bit target,
> > shouldn't the rest of the tool chain be responsible for making sure
> > the high bits are zero rather than expecting GDB to mask it off?
> > Granted there might be complications here, like there are cases on
> > MIPS where we treat an address as signed rather than unsigned, but I'm
> > also pretty clear on whether that is actually design or just a bug. I
> > could be wrong/persuadable, of course, and perhaps someone has a
> > better idea of all this (in which case I'd suggest commenting
> > arch_size at bfd/elf-bfd.h and/or expanding comments at
> > bfd_arch_bits_per_address in bfd/archures.c).
>
> FYI, in the MIPS case it is a feature of the hardware. GDB has little
> choice in the matter.
Can you explain why, in the MIPS case, GCC/GAS/LD are unable to place
correct information in the upper bits of the Dwarf addresses?
(That sounds like a rhetorical question, but it's not. I'm having a
hard time imagining why address_significant_bits was the right
solution.)
From jimb@zwingli.cygnus.com Tue Mar 28 08:50:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Chris Faylor <cgf@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFA] Avoid core dumping on corrupt stabs entry
Date: Tue, 28 Mar 2000 08:50:00 -0000
Message-id: <npity72g5n.fsf@zwingli.cygnus.com>
References: <20000327204057.A24783@cygnus.com>
X-SW-Source: 2000-03/msg00647.html
Content-length: 860
Approved, thanks.
> Any objections to this patch? It seems to be in the spirit of the rest
> of the file.
>
> cgf
>
> 2000-03-27 Christopher Faylor <cgf@cygnus.com>
>
> * partial-stab.h: Add one more check against corrupted or irregular
> stabs entry.
>
> Index: partial-stab.h
> ===================================================================
> RCS file: /cvs/cvsfiles/devo/gdb/partial-stab.h,v
> retrieving revision 2.68
> diff -u -p -r2.68 partial-stab.h
> --- partial-stab.h 1999/09/14 22:50:39 2.68
> +++ partial-stab.h 2000/03/28 01:37:53
> @@ -393,7 +393,7 @@ switch (CUR_SYMBOL_TYPE)
>
> #ifdef DBXREAD_ONLY
> /* See if this is an end of function stab. */
> - if (CUR_SYMBOL_TYPE == N_FUN && *namestring == '\000')
> + if (pst && CUR_SYMBOL_TYPE == N_FUN && *namestring == '\000')
> {
> unsigned long valu;
>
>
From shebs@shebs.cnchost.com Tue Mar 28 08:59:00 2000
From: Stan Shebs <shebs@shebs.cnchost.com>
To: gdb-patches@sourceware.cygnus.com
Cc: 3diff@gnu.org
Subject: GDB manual changes
Date: Tue, 28 Mar 2000 08:59:00 -0000
Message-id: <38E0E672.478B088F@shebs.cnchost.com>
X-SW-Source: 2000-03/msg00648.html
Content-length: 136933
I've just committed a pile of changes to the manual. This includes
the duplication of the top-level menu for the benefit of @ifhtml,
the re-removal of node links, and various formatting changes to
make @smallbook come out right (as requested by Brian Youmans).
I tested on 3.12, 3.12h (RH 6.1 version), and 4.0. Apparently
texi2html has a problem with the top-level menu that is under
@ifhtml, and it gets garbled, although 4.0 makeinfo -html works
fine (but it can only make one monster html file, sigh). It's
functionally no worse than before, but looks bad.
I'm still planning to rewrite the introduction to use a more
meaningful example program, and we still have undocumented
commands that ought to be mentioned, so this isn't the end,
but this should be a good base for the next round of tweaks.
(I left the remote protocol section mostly untouched, since JT
has a patch to apply.)
Stan
2000-03-28 Stan Shebs <shebs@apple.com>
* gdb.texinfo: Update dates, bump to Eighth Edition (note
expectation of additional changes before release), update
ISBN, add copy of top-level menu for @ifhtml, remove explicit
node links, rephrase and/or shorten lines to fix formatting
problem in both regular and @smallbook formats.
* annotate.texi: Shorten lines in example, use smallexample
consistently everywhere.
* Makefile.in: Add comment about texinfo 4.0 html generation.
(SFILES_INCLUDED): Add annotate.texi.
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/doc/Makefile.in,v
retrieving revision 1.3
diff -p -r1.3 Makefile.in
*** Makefile.in 2000/03/24 07:27:24 1.3
--- Makefile.in 2000/03/28 16:33:45
*************** TEXIDIR=${gdbdir}/../texinfo
*** 40,45 ****
--- 40,49 ----
# where to find makeinfo, preferably one designed for texinfo-2
MAKEINFO=makeinfo
+ # Note that texinfo 4.0's makeinfo --html can only generate a
+ # single file, which would be too large, so continue to use
+ # texi2html. -sts 2000-03-28
+
MAKEHTML = texi2html
MAKEHTMLFLAGS = -glossary -menu -split_chapter
*************** TEXINDEX = texindex
*** 83,89 ****
DVIPS = dvips
# Main GDB manual's source files
! SFILES_INCLUDED = gdb-cfg.texi
SFILES_LOCAL = $(srcdir)/gdb.texinfo GDBvn.texi $(SFILES_INCLUDED)
--- 87,93 ----
DVIPS = dvips
# Main GDB manual's source files
! SFILES_INCLUDED = gdb-cfg.texi $(srcdir)/annotate.texi
SFILES_LOCAL = $(srcdir)/gdb.texinfo GDBvn.texi $(SFILES_INCLUDED)
Index: annotate.texi
===================================================================
RCS file: /cvs/src/src/gdb/doc/annotate.texi,v
retrieving revision 1.3
diff -p -r1.3 annotate.texi
*** annotate.texi 2000/03/24 07:30:06 1.3
--- annotate.texi 2000/03/28 16:33:45
***************
*** 60,68 ****
@chapter @value{GDBN} Annotations
@end ifclear
! This chapter describes annotations in @value{GDBN}, the GNU symbolic debugger.
! Annotations are designed to interface @value{GDBN} to graphical user interfaces
! or other similar programs which want to interact with @value{GDBN} at a
relatively high level.
@ignore
--- 60,68 ----
@chapter @value{GDBN} Annotations
@end ifclear
! This chapter describes annotations in @value{GDBN}. Annotations are
! designed to interface @value{GDBN} to graphical user interfaces or other
! similar programs which want to interact with @value{GDBN} at a
relatively high level.
@ignore
*************** additional information, and a newline.
*** 100,109 ****
cannot contain newline characters.
Any output not beginning with a newline and two @samp{control-z}
! characters denotes literal output from @value{GDBN}. Currently there is no need
! for @value{GDBN} to output a newline followed by two @samp{control-z} characters,
! but if there was such a need, the annotations could be extended with an
! @samp{escape} annotation which means those three characters as output.
A simple example of starting up @value{GDBN} with annotations is:
--- 100,110 ----
cannot contain newline characters.
Any output not beginning with a newline and two @samp{control-z}
! characters denotes literal output from @value{GDBN}. Currently there is
! no need for @value{GDBN} to output a newline followed by two
! @samp{control-z} characters, but if there was such a need, the
! annotations could be extended with an @samp{escape} annotation which
! means those three characters as output.
A simple example of starting up @value{GDBN} with annotations is:
*************** A simple example of starting up @value{G
*** 111,120 ****
$ gdb --annotate=2
GNU GDB 5.0
Copyright 2000 Free Software Foundation, Inc.
! GDB is free software, covered by the GNU General Public License, and you are
! welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
! There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc-sun-sunos4.1.3"
^Z^Zpre-prompt
--- 112,123 ----
$ gdb --annotate=2
GNU GDB 5.0
Copyright 2000 Free Software Foundation, Inc.
! GDB is free software, covered by the GNU General Public License,
! and you are welcome to change it and/or distribute copies of it
! under certain conditions.
Type "show copying" to see the conditions.
! There is absolutely no warranty for GDB. Type "show warranty"
! for details.
This GDB was configured as "sparc-sun-sunos4.1.3"
^Z^Zpre-prompt
*************** quit
*** 126,144 ****
$
@end smallexample
! Here @samp{quit} is input to @value{GDBN}; the rest is output from @value{GDBN}. The three
! lines beginning @samp{^Z^Z} (where @samp{^Z} denotes a @samp{control-z}
! character) are annotations; the rest is output from @value{GDBN}.
@node Server Prefix
@section The Server Prefix
@cindex server prefix for annotations
! To issue a command to @value{GDBN} without affecting certain aspects of the state
! which is seen by users, prefix it with @samp{server }. This means that
! this command will not affect the command history, nor will it affect
! @value{GDBN}'s notion of which command to repeat if @key{RET} is pressed on a
! line by itself.
The server prefix does not affect the recording of values into the value
history; to print a value without recording it into the value history,
--- 129,148 ----
$
@end smallexample
! Here @samp{quit} is input to @value{GDBN}; the rest is output from
! @value{GDBN}. The three lines beginning @samp{^Z^Z} (where @samp{^Z}
! denotes a @samp{control-z} character) are annotations; the rest is
! output from @value{GDBN}.
@node Server Prefix
@section The Server Prefix
@cindex server prefix for annotations
! To issue a command to @value{GDBN} without affecting certain aspects of
! the state which is seen by users, prefix it with @samp{server }. This
! means that this command will not affect the command history, nor will it
! affect @value{GDBN}'s notion of which command to repeat if @key{RET} is
! pressed on a line by itself.
The server prefix does not affect the recording of values into the value
history; to print a value without recording it into the value history,
*************** use the @code{output} command instead of
*** 148,155 ****
@section Values
@cindex annotations for values
! When a value is printed in various contexts, @value{GDBN} uses annotations to
! delimit the value from the surrounding text.
@findex value-history-begin
@findex value-history-value
--- 152,159 ----
@section Values
@cindex annotations for values
! When a value is printed in various contexts, @value{GDBN} uses
! annotations to delimit the value from the surrounding text.
@findex value-history-begin
@findex value-history-value
*************** delimit the value from the surrounding t
*** 157,169 ****
If a value is printed using @code{print} and added to the value history,
the annotation looks like
! @example
^Z^Zvalue-history-begin @var{history-number} @var{value-flags}
@var{history-string}
^Z^Zvalue-history-value
@var{the-value}
^Z^Zvalue-history-end
! @end example
where @var{history-number} is the number it is getting in the value
history, @var{history-string} is a string, such as @samp{$5 = }, which
--- 161,173 ----
If a value is printed using @code{print} and added to the value history,
the annotation looks like
! @smallexample
^Z^Zvalue-history-begin @var{history-number} @var{value-flags}
@var{history-string}
^Z^Zvalue-history-value
@var{the-value}
^Z^Zvalue-history-end
! @end smallexample
where @var{history-number} is the number it is getting in the value
history, @var{history-string} is a string, such as @samp{$5 = }, which
*************** a value which can be dereferenced and @s
*** 176,186 ****
If the value is not added to the value history (it is an invalid float
or it is printed with the @code{output} command), the annotation is similar:
! @example
^Z^Zvalue-begin @var{value-flags}
@var{the-value}
^Z^Zvalue-end
! @end example
@findex arg-begin
@findex arg-name-end
--- 180,190 ----
If the value is not added to the value history (it is an invalid float
or it is printed with the @code{output} command), the annotation is similar:
! @smallexample
^Z^Zvalue-begin @var{value-flags}
@var{the-value}
^Z^Zvalue-end
! @end smallexample
@findex arg-begin
@findex arg-name-end
*************** or it is printed with the @code{output}
*** 189,195 ****
When @value{GDBN} prints an argument to a function (for example, in the output
from the @code{backtrace} command), it annotates it as follows:
! @example
^Z^Zarg-begin
@var{argument-name}
^Z^Zarg-name-end
--- 193,199 ----
When @value{GDBN} prints an argument to a function (for example, in the output
from the @code{backtrace} command), it annotates it as follows:
! @smallexample
^Z^Zarg-begin
@var{argument-name}
^Z^Zarg-name-end
*************** from the @code{backtrace} command), it a
*** 197,203 ****
^Z^Zarg-value @var{value-flags}
@var{the-value}
^Z^Zarg-end
! @end example
where @var{argument-name} is the name of the argument,
@var{separator-string} is text which separates the name from the value
--- 201,207 ----
^Z^Zarg-value @var{value-flags}
@var{the-value}
^Z^Zarg-end
! @end smallexample
where @var{argument-name} is the name of the argument,
@var{separator-string} is text which separates the name from the value
*************** for the user's benefit (such as @samp{=}
*** 211,217 ****
@findex field-end
When printing a structure, @value{GDBN} annotates it as follows:
! @example
^Z^Zfield-begin @var{value-flags}
@var{field-name}
^Z^Zfield-name-end
--- 215,221 ----
@findex field-end
When printing a structure, @value{GDBN} annotates it as follows:
! @smallexample
^Z^Zfield-begin @var{value-flags}
@var{field-name}
^Z^Zfield-name-end
*************** When printing a structure, @value{GDBN}
*** 219,225 ****
^Z^Zfield-value
@var{the-value}
^Z^Zfield-end
! @end example
where @var{field-name} is the name of the field, @var{separator-string}
is text which separates the name from the value for the user's benefit
--- 223,229 ----
^Z^Zfield-value
@var{the-value}
^Z^Zfield-end
! @end smallexample
where @var{field-name} is the name of the field, @var{separator-string}
is text which separates the name from the value for the user's benefit
*************** same meanings as in a @code{value-histor
*** 228,236 ****
When printing an array, @value{GDBN} annotates it as follows:
! @example
^Z^Zarray-section-begin @var{array-index} @var{value-flags}
! @end example
where @var{array-index} is the index of the first element being
annotated and @var{value-flags} has the same meaning as in a
--- 232,240 ----
When printing an array, @value{GDBN} annotates it as follows:
! @smallexample
^Z^Zarray-section-begin @var{array-index} @var{value-flags}
! @end smallexample
where @var{array-index} is the index of the first element being
annotated and @var{value-flags} has the same meaning as in a
*************** annotated and @var{value-flags} has the
*** 238,260 ****
of elements, where is element can be either a single element:
@findex elt
! @example
@samp{,} @var{whitespace} ; @r{omitted for the first element}
@var{the-value}
^Z^Zelt
! @end example
or a repeated element
@findex elt-rep
@findex elt-rep-end
! @example
@samp{,} @var{whitespace} ; @r{omitted for the first element}
@var{the-value}
^Z^Zelt-rep @var{number-of-repititions}
@var{repetition-string}
^Z^Zelt-rep-end
! @end example
In both cases, @var{the-value} is the output for the value of the
element and @var{whitespace} can contain spaces, tabs, and newlines. In
--- 242,264 ----
of elements, where is element can be either a single element:
@findex elt
! @smallexample
@samp{,} @var{whitespace} ; @r{omitted for the first element}
@var{the-value}
^Z^Zelt
! @end smallexample
or a repeated element
@findex elt-rep
@findex elt-rep-end
! @smallexample
@samp{,} @var{whitespace} ; @r{omitted for the first element}
@var{the-value}
^Z^Zelt-rep @var{number-of-repititions}
@var{repetition-string}
^Z^Zelt-rep-end
! @end smallexample
In both cases, @var{the-value} is the output for the value of the
element and @var{whitespace} can contain spaces, tabs, and newlines. In
*************** user that repitition is being depicted.
*** 267,275 ****
Once all the array elements have been output, the array annotation is
ended with
! @example
^Z^Zarray-section-end
! @end example
@node Frame Annotations
@section Frames
--- 271,279 ----
Once all the array elements have been output, the array annotation is
ended with
! @smallexample
^Z^Zarray-section-end
! @end smallexample
@node Frame Annotations
@section Frames
*************** to frames printed when @value{GDBN} stop
*** 282,291 ****
@findex frame-begin
The frame annotation begins with
! @example
^Z^Zframe-begin @var{level} @var{address}
@var{level-string}
! @end example
where @var{level} is the number of the frame (0 is the innermost frame,
and other frames have positive numbers), @var{address} is the address of
--- 286,295 ----
@findex frame-begin
The frame annotation begins with
! @smallexample
^Z^Zframe-begin @var{level} @var{address}
@var{level-string}
! @end smallexample
where @var{level} is the number of the frame (0 is the innermost frame,
and other frames have positive numbers), @var{address} is the address of
*************** designed to convey the level to the user
*** 295,303 ****
does not depend on the language). The frame ends with
@findex frame-end
! @example
^Z^Zframe-end
! @end example
Between these annotations is the main body of the frame, which can
consist of
--- 299,307 ----
does not depend on the language). The frame ends with
@findex frame-end
! @smallexample
^Z^Zframe-end
! @end smallexample
Between these annotations is the main body of the frame, which can
consist of
*************** consist of
*** 305,314 ****
@itemize @bullet
@item
@findex function-call
! @example
^Z^Zfunction-call
@var{function-call-string}
! @end example
where @var{function-call-string} is text designed to convey to the user
that this frame is associated with a function call made by @value{GDBN} to a
--- 309,318 ----
@itemize @bullet
@item
@findex function-call
! @smallexample
^Z^Zfunction-call
@var{function-call-string}
! @end smallexample
where @var{function-call-string} is text designed to convey to the user
that this frame is associated with a function call made by @value{GDBN} to a
*************** function in the program being debugged.
*** 316,325 ****
@item
@findex signal-handler-caller
! @example
^Z^Zsignal-handler-caller
@var{signal-handler-caller-string}
! @end example
where @var{signal-handler-caller-string} is text designed to convey to
the user that this frame is associated with whatever mechanism is used
--- 320,329 ----
@item
@findex signal-handler-caller
! @smallexample
^Z^Zsignal-handler-caller
@var{signal-handler-caller-string}
! @end smallexample
where @var{signal-handler-caller-string} is text designed to convey to
the user that this frame is associated with whatever mechanism is used
*************** A normal frame.
*** 334,345 ****
This can optionally (depending on whether this is thought of as
interesting information for the user to see) begin with
! @example
^Z^Zframe-address
@var{address}
^Z^Zframe-address-end
@var{separator-string}
! @end example
where @var{address} is the address executing in the frame (the same
address as in the @code{frame-begin} annotation, but printed in a form
--- 338,349 ----
This can optionally (depending on whether this is thought of as
interesting information for the user to see) begin with
! @smallexample
^Z^Zframe-address
@var{address}
^Z^Zframe-address-end
@var{separator-string}
! @end smallexample
where @var{address} is the address executing in the frame (the same
address as in the @code{frame-begin} annotation, but printed in a form
*************** benefit.
*** 352,363 ****
@findex frame-args
Then comes
! @example
^Z^Zframe-function-name
@var{function-name}
^Z^Zframe-args
@var{arguments}
! @end example
where @var{function-name} is the name of the function executing in the
frame, or @samp{??} if not known, and @var{arguments} are the arguments
--- 356,367 ----
@findex frame-args
Then comes
! @smallexample
^Z^Zframe-function-name
@var{function-name}
^Z^Zframe-args
@var{arguments}
! @end smallexample
where @var{function-name} is the name of the function executing in the
frame, or @samp{??} if not known, and @var{arguments} are the arguments
*************** individually as well, @pxref{Value Annot
*** 371,377 ****
@findex frame-source-end
If source information is available, a reference to it is then printed:
! @example
^Z^Zframe-source-begin
@var{source-intro-string}
^Z^Zframe-source-file
--- 375,381 ----
@findex frame-source-end
If source information is available, a reference to it is then printed:
! @smallexample
^Z^Zframe-source-begin
@var{source-intro-string}
^Z^Zframe-source-file
*************** If source information is available, a re
*** 381,387 ****
^Z^Zframe-source-line
@var{line-number}
^Z^Zframe-source-end
! @end example
where @var{source-intro-string} separates for the user's benefit the
reference from the text which precedes it, @var{filename} is the name of
--- 385,391 ----
^Z^Zframe-source-line
@var{line-number}
^Z^Zframe-source-end
! @end smallexample
where @var{source-intro-string} separates for the user's benefit the
reference from the text which precedes it, @var{filename} is the name of
*************** If @value{GDBN} prints some information
*** 393,402 ****
library, which load segment, etc.; currently only done on the RS/6000),
it is annotated with
! @example
^Z^Zframe-where
@var{information}
! @end example
Then, if source is to actually be displayed for this frame (for example,
this is not true for output from the @code{backtrace} command), then a
--- 397,406 ----
library, which load segment, etc.; currently only done on the RS/6000),
it is annotated with
! @smallexample
^Z^Zframe-where
@var{information}
! @end smallexample
Then, if source is to actually be displayed for this frame (for example,
this is not true for output from the @code{backtrace} command), then a
*************** output, not in addition.
*** 419,425 ****
When @value{GDBN} is told to display something using the @code{display} command,
the results of the display are annotated:
! @example
^Z^Zdisplay-begin
@var{number}
^Z^Zdisplay-number-end
--- 423,429 ----
When @value{GDBN} is told to display something using the @code{display} command,
the results of the display are annotated:
! @smallexample
^Z^Zdisplay-begin
@var{number}
^Z^Zdisplay-number-end
*************** the results of the display are annotated
*** 433,439 ****
^Z^Zdisplay-value
@var{value}
^Z^Zdisplay-end
! @end example
where @var{number} is the number of the display, @var{number-separator}
is intended to separate the number from what follows for the user,
--- 437,443 ----
^Z^Zdisplay-value
@var{value}
^Z^Zdisplay-end
! @end smallexample
where @var{number} is the number of the display, @var{number-separator}
is intended to separate the number from what follows for the user,
*************** annotation which denotes the end of any
*** 459,469 ****
associated with the input. For example, the @code{prompt} input type
features the following annotations:
! @example
^Z^Zpre-prompt
^Z^Zprompt
^Z^Zpost-prompt
! @end example
The input types are
--- 463,473 ----
associated with the input. For example, the @code{prompt} input type
features the following annotations:
! @smallexample
^Z^Zpre-prompt
^Z^Zprompt
^Z^Zpost-prompt
! @end smallexample
The input types are
*************** presence of annotations.
*** 508,523 ****
@cindex annotations for errors, warnings and interrupts
@findex quit
! @example
^Z^Zquit
! @end example
This annotation occurs right before @value{GDBN} responds to an interrupt.
@findex error
! @example
^Z^Zerror
! @end example
This annotation occurs right before @value{GDBN} responds to an error.
--- 512,527 ----
@cindex annotations for errors, warnings and interrupts
@findex quit
! @smallexample
^Z^Zquit
! @end smallexample
This annotation occurs right before @value{GDBN} responds to an interrupt.
@findex error
! @smallexample
^Z^Zerror
! @end smallexample
This annotation occurs right before @value{GDBN} responds to an error.
*************** to the top level.
*** 532,540 ****
@findex error-begin
A quit or error annotation may be preceded by
! @example
^Z^Zerror-begin
! @end example
Any output between that and the quit or error annotation is the error
message.
--- 536,544 ----
@findex error-begin
A quit or error annotation may be preceded by
! @smallexample
^Z^Zerror-begin
! @end smallexample
Any output between that and the quit or error annotation is the error
message.
*************** The output from the @code{info breakpoin
*** 551,561 ****
@findex breakpoints-headers
@findex breakpoints-table
! @example
^Z^Zbreakpoints-headers
@var{header-entry}
^Z^Zbreakpoints-table
! @end example
where @var{header-entry} has the same syntax as an entry (see below) but
instead of containing data, it contains strings which are intended to
--- 555,565 ----
@findex breakpoints-headers
@findex breakpoints-table
! @smallexample
^Z^Zbreakpoints-headers
@var{header-entry}
^Z^Zbreakpoints-table
! @end smallexample
where @var{header-entry} has the same syntax as an entry (see below) but
instead of containing data, it contains strings which are intended to
*************** of:
*** 566,572 ****
@findex record
@findex field
! @example
^Z^Zrecord
^Z^Zfield 0
@var{number}
--- 570,576 ----
@findex record
@findex field
! @smallexample
^Z^Zrecord
^Z^Zfield 0
@var{number}
*************** of:
*** 588,594 ****
@var{ignore-count}
^Z^Zfield 9
@var{commands}
! @end example
Note that @var{address} is intended for user consumption---the syntax
varies depending on the language.
--- 592,598 ----
@var{ignore-count}
^Z^Zfield 9
@var{commands}
! @end smallexample
Note that @var{address} is intended for user consumption---the syntax
varies depending on the language.
*************** varies depending on the language.
*** 596,604 ****
The output ends with
@findex breakpoints-table-end
! @example
^Z^Zbreakpoints-table-end
! @end example
@node Invalidation
@section Invalidation Notices
--- 600,608 ----
The output ends with
@findex breakpoints-table-end
! @smallexample
^Z^Zbreakpoints-table-end
! @end smallexample
@node Invalidation
@section Invalidation Notices
*************** deleted a breakpoint.
*** 630,644 ****
When the program starts executing due to a @value{GDBN} command such as
@code{step} or @code{continue},
! @example
^Z^Zstarting
! @end example
is output. When the program stops,
! @example
^Z^Zstopped
! @end example
is output. Before the @code{stopped} annotation, a variety of
annotations describe how the program stopped.
--- 634,648 ----
When the program starts executing due to a @value{GDBN} command such as
@code{step} or @code{continue},
! @smallexample
^Z^Zstarting
! @end smallexample
is output. When the program stops,
! @smallexample
^Z^Zstopped
! @end smallexample
is output. Before the @code{stopped} annotation, a variety of
annotations describe how the program stopped.
*************** successful exit, otherwise nonzero).
*** 658,664 ****
The program exited with a signal. After the @code{^Z^Zsignalled}, the
annotation continues:
! @example
@var{intro-text}
^Z^Zsignal-name
@var{name}
--- 662,668 ----
The program exited with a signal. After the @code{^Z^Zsignalled}, the
annotation continues:
! @smallexample
@var{intro-text}
^Z^Zsignal-name
@var{name}
*************** annotation continues:
*** 668,674 ****
@var{string}
^Z^Zsignal-string-end
@var{end-text}
! @end example
where @var{name} is the name of the signal, such as @code{SIGILL} or
@code{SIGSEGV}, and @var{string} is the explanation of the signal, such
--- 672,678 ----
@var{string}
^Z^Zsignal-string-end
@var{end-text}
! @end smallexample
where @var{name} is the name of the signal, such as @code{SIGILL} or
@code{SIGSEGV}, and @var{string} is the explanation of the signal, such
*************** The program hit watchpoint number @var{n
*** 698,706 ****
@findex source
The following annotation is used instead of displaying source code:
! @example
^Z^Zsource @var{filename}:@var{line}:@var{character}:@var{middle}:@var{addr}
! @end example
where @var{filename} is an absolute file name indicating which source
file, @var{line} is the line number within that file (where 1 is the
--- 702,710 ----
@findex source
The following annotation is used instead of displaying source code:
! @smallexample
^Z^Zsource @var{filename}:@var{line}:@var{character}:@var{middle}:@var{addr}
! @end smallexample
where @var{filename} is an absolute file name indicating which source
file, @var{line} is the line number within that file (where 1 is the
Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.8
diff -p -r1.8 gdb.texinfo
*** gdb.texinfo 2000/03/28 02:25:13 1.8
--- gdb.texinfo 2000/03/28 16:33:52
***************
*** 1,5 ****
\input texinfo @c -*-texinfo-*-
! @c Copyright 1988-1999
@c Free Software Foundation, Inc.
@c
@c %**start of header
--- 1,5 ----
\input texinfo @c -*-texinfo-*-
! @c Copyright 1988-2000
@c Free Software Foundation, Inc.
@c
@c %**start of header
***************
*** 25,39 ****
@syncodeindex vr cp
@c !!set GDB manual's edition---not the same as GDB version!
! @set EDITION Seventh
@c !!set GDB manual's revision date
! @set DATE February 1999
! @c THIS MANUAL REQUIRES TEXINFO-2 macros and info-makers to format properly.
@c This is a dir.info fragment to support semi-automated addition of
! @c manuals to an info tree. zoo@cygnus.com is developing this facility.
@dircategory Programming & development tools.
@direntry
* Gdb: (gdb). The @sc{gnu} debugger.
--- 25,39 ----
@syncodeindex vr cp
@c !!set GDB manual's edition---not the same as GDB version!
! @set EDITION Eighth
@c !!set GDB manual's revision date
! @set DATE March 2000
! @c THIS MANUAL REQUIRES TEXINFO 3.12 OR LATER.
@c This is a dir.info fragment to support semi-automated addition of
! @c manuals to an info tree.
@dircategory Programming & development tools.
@direntry
* Gdb: (gdb). The @sc{gnu} debugger.
*************** This is the @value{EDITION} Edition, @va
*** 47,53 ****
of @cite{Debugging with @value{GDBN}: the @sc{gnu} Source-Level Debugger}
for @value{GDBN} Version @value{GDBVN}.
! Copyright (C) 1988-1999 Free Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
--- 47,53 ----
of @cite{Debugging with @value{GDBN}: the @sc{gnu} Source-Level Debugger}
for @value{GDBN} Version @value{GDBVN}.
! Copyright (C) 1988-2000 Free Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
*************** into another language, under the above c
*** 85,101 ****
}
@end tex
- @c ISBN seems to be wrong...
-
@vskip 0pt plus 1filll
! Copyright @copyright{} 1988-1999 Free Software Foundation, Inc.
@sp 2
Published by the Free Software Foundation @*
59 Temple Place - Suite 330, @*
Boston, MA 02111-1307 USA @*
! Printed copies are available for $20 each. @*
! ISBN 1-882114-11-6 @*
!
Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.
--- 85,98 ----
}
@end tex
@vskip 0pt plus 1filll
! Copyright @copyright{} 1988-2000 Free Software Foundation, Inc.
@sp 2
Published by the Free Software Foundation @*
59 Temple Place - Suite 330, @*
Boston, MA 02111-1307 USA @*
! ISBN 1-882114-77-9 @*
!
Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.
*************** into another language, under the above c
*** 110,127 ****
@end titlepage
@page
-
- @node Top, Summary, (dir), (dir)
@ifinfo
@top Debugging with @value{GDBN}
This file describes @value{GDBN}, the @sc{gnu} symbolic debugger.
This is the @value{EDITION} Edition, @value{DATE}, for @value{GDBN} Version
@value{GDBVN}.
! Copyright (C) 1988-1999 Free Software Foundation, Inc.
@end ifinfo
@menu
* Summary:: Summary of @value{GDBN}
* Sample Session:: A sample @value{GDBN} session
--- 107,173 ----
@end titlepage
@page
@ifinfo
+ @node Top, Summary, (dir), (dir)
+
@top Debugging with @value{GDBN}
This file describes @value{GDBN}, the @sc{gnu} symbolic debugger.
This is the @value{EDITION} Edition, @value{DATE}, for @value{GDBN} Version
@value{GDBVN}.
+
+ Copyright (C) 1988-2000 Free Software Foundation, Inc.
+
+ @menu
+ * Summary:: Summary of @value{GDBN}
+ * Sample Session:: A sample @value{GDBN} session
+
+ * Invocation:: Getting in and out of @value{GDBN}
+ * Commands:: @value{GDBN} commands
+ * Running:: Running programs under @value{GDBN}
+ * Stopping:: Stopping and continuing
+ * Stack:: Examining the stack
+ * Source:: Examining source files
+ * Data:: Examining data
! * Languages:: Using @value{GDBN} with different languages
!
! * Symbols:: Examining the symbol table
! * Altering:: Altering execution
! * GDB Files:: @value{GDBN} files
! * Targets:: Specifying a debugging target
! * Configurations:: Configuration-specific information
! * Controlling GDB:: Controlling @value{GDBN}
! * Sequences:: Canned sequences of commands
! * Emacs:: Using @value{GDBN} under @sc{gnu} Emacs
! * Annotations:: @value{GDBN}'s annotation interface.
!
! * GDB Bugs:: Reporting bugs in @value{GDBN}
! * Formatting Documentation:: How to format and print @value{GDBN} documentation
!
! * Command Line Editing:: Command Line Editing
! * Using History Interactively:: Using History Interactively
! * Installing GDB:: Installing GDB
! * Index:: Index
! @end menu
!
@end ifinfo
+
+ @c the replication sucks, but this avoids a texinfo 3.12 lameness
+
+ @ifhtml
+ @node Top
+
+ @top Debugging with @value{GDBN}
+
+ This file describes @value{GDBN}, the @sc{gnu} symbolic debugger.
+
+ This is the @value{EDITION} Edition, @value{DATE}, for @value{GDBN} Version
+ @value{GDBVN}.
+
+ Copyright (C) 1988-2000 Free Software Foundation, Inc.
+
@menu
* Summary:: Summary of @value{GDBN}
* Sample Session:: A sample @value{GDBN} session
*************** Copyright (C) 1988-1999 Free Software Fo
*** 144,150 ****
* 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
--- 190,196 ----
* Controlling GDB:: Controlling @value{GDBN}
* Sequences:: Canned sequences of commands
* Emacs:: Using @value{GDBN} under @sc{gnu} Emacs
! * Annotations:: @value{GDBN}'s annotation interface.
* GDB Bugs:: Reporting bugs in @value{GDBN}
* Formatting Documentation:: How to format and print @value{GDBN} documentation
*************** Copyright (C) 1988-1999 Free Software Fo
*** 155,161 ****
* Index:: Index
@end menu
! @node Summary, Sample Session, Top, Top
@unnumbered Summary of @value{GDBN}
The purpose of a debugger such as @value{GDBN} is to allow you to see what is
--- 201,209 ----
* Index:: Index
@end menu
! @end ifhtml
!
! @node Summary
@unnumbered Summary of @value{GDBN}
The purpose of a debugger such as @value{GDBN} is to allow you to see what is
*************** underscore.
*** 205,211 ****
* Contributors:: Contributors to GDB
@end menu
! @node Free Software, Contributors, Summary, Summary
@unnumberedsec Free software
@value{GDBN} is @dfn{free software}, protected by the @sc{gnu}
--- 253,259 ----
* Contributors:: Contributors to GDB
@end menu
! @node Free Software
@unnumberedsec Free software
@value{GDBN} is @dfn{free software}, protected by the @sc{gnu}
*************** Fundamentally, the General Public Licens
*** 221,227 ****
you have these freedoms and that you cannot take these freedoms away
from anyone else.
! @node Contributors, , Free Software, Summary
@unnumberedsec Contributors to @value{GDBN}
Richard Stallman was the original author of @value{GDBN}, and of many
--- 269,275 ----
you have these freedoms and that you cannot take these freedoms away
from anyone else.
! @node Contributors
@unnumberedsec Contributors to @value{GDBN}
Richard Stallman was the original author of @value{GDBN}, and of many
*************** Thomas, Michael Tiemann, Tom Tromey, Ron
*** 360,366 ****
Zuhn have made contributions both large and small.
! @node Sample Session, Invocation, Summary, Top
@chapter A Sample @value{GDBN} Session
You can use this manual at your leisure to read all about @value{GDBN}.
--- 408,414 ----
Zuhn have made contributions both large and small.
! @node Sample Session
@chapter A Sample @value{GDBN} Session
You can use this manual at your leisure to read all about @value{GDBN}.
*************** session with the @value{GDBN} @code{quit
*** 630,636 ****
(@value{GDBP}) @b{quit}
@end smallexample
! @node Invocation, Commands, Sample Session, Top
@chapter Getting In and Out of @value{GDBN}
This chapter discusses how to start @value{GDBN}, and how to get out of it.
--- 678,684 ----
(@value{GDBP}) @b{quit}
@end smallexample
! @node Invocation
@chapter Getting In and Out of @value{GDBN}
This chapter discusses how to start @value{GDBN}, and how to get out of it.
*************** type @kbd{quit} or @kbd{C-d} to exit.
*** 648,654 ****
* Shell Commands:: How to use shell commands inside @value{GDBN}
@end menu
! @node Invoking GDB, Quitting GDB, Invocation, Invocation
@section Invoking @value{GDBN}
Invoke @value{GDBN} by running the program @code{@value{GDBP}}. Once started,
--- 696,702 ----
* Shell Commands:: How to use shell commands inside @value{GDBN}
@end menu
! @node Invoking GDB
@section Invoking @value{GDBN}
Invoke @value{GDBN} by running the program @code{@value{GDBP}}. Once started,
*************** in sequential order. The order makes a
*** 725,731 ****
* Mode Options:: Choosing modes
@end menu
! @node File Options, Mode Options, Invoking GDB, Invoking GDB
@subsection Choosing files
When @value{GDBN} starts, it reads any arguments other than options as
--- 773,779 ----
* Mode Options:: Choosing modes
@end menu
! @node File Options
@subsection Choosing files
When @value{GDBN} starts, it reads any arguments other than options as
*************** but build a @file{.syms} file for future
*** 833,839 ****
gdb -batch -nx -mapped -readnow programname
@end example
! @node Mode Options, , File Options, Invoking GDB
@subsection Choosing modes
You can run @value{GDBN} in various alternative modes---for example, in
--- 881,887 ----
gdb -batch -nx -mapped -readnow programname
@end example
! @node Mode Options
@subsection Choosing modes
You can run @value{GDBN} in various alternative modes---for example, in
*************** no-warranty blurb, and exit.
*** 1014,1020 ****
@end table
! @node Quitting GDB, Shell Commands, Invoking GDB, Invocation
@section Quitting @value{GDBN}
@cindex exiting @value{GDBN}
@cindex leaving @value{GDBN}
--- 1062,1068 ----
@end table
! @node Quitting GDB
@section Quitting @value{GDBN}
@cindex exiting @value{GDBN}
@cindex leaving @value{GDBN}
*************** If you have been using @value{GDBN} to c
*** 1042,1048 ****
device, you can release it with the @code{detach} command
(@pxref{Attach, ,Debugging an already-running process}).
! @node Shell Commands, , Quitting GDB, Invocation
@section Shell commands
If you need to execute occasional shell commands during your
--- 1090,1096 ----
device, you can release it with the @code{detach} command
(@pxref{Attach, ,Debugging an already-running process}).
! @node Shell Commands
@section Shell commands
If you need to execute occasional shell commands during your
*************** Execute the @code{make} program with the
*** 1071,1077 ****
arguments. This is equivalent to @samp{shell make @var{make-args}}.
@end table
! @node Commands, Running, Invocation, Top
@chapter @value{GDBN} Commands
You can abbreviate a @value{GDBN} command to the first few letters of the command
--- 1119,1125 ----
arguments. This is equivalent to @samp{shell make @var{make-args}}.
@end table
! @node Commands
@chapter @value{GDBN} Commands
You can abbreviate a @value{GDBN} command to the first few letters of the command
*************** show you the alternatives available, if
*** 1086,1092 ****
* Help:: How to ask @value{GDBN} for help
@end menu
! @node Command Syntax, Completion, Commands, Commands
@section Command syntax
A @value{GDBN} command is a single line of input. There is no limit on
--- 1134,1140 ----
* Help:: How to ask @value{GDBN} for help
@end menu
! @node Command Syntax
@section Command syntax
A @value{GDBN} command is a single line of input. There is no limit on
*************** Any text from a @kbd{#} to the end of th
*** 1129,1135 ****
nothing. This is useful mainly in command files (@pxref{Command
Files,,Command files}).
! @node Completion, Help, Command Syntax, Commands
@section Command completion
@cindex completion
--- 1177,1183 ----
nothing. This is useful mainly in command files (@pxref{Command
Files,,Command files}).
! @node Completion
@section Command completion
@cindex completion
*************** overload-resolution off} to disable over
*** 1248,1254 ****
see @ref{Debugging C plus plus, ,@value{GDBN} features for C++}.
! @node Help, , Completion, Commands
@section Getting help
@cindex online documentation
@kindex help
--- 1296,1302 ----
see @ref{Debugging C plus plus, ,@value{GDBN} features for C++}.
! @node Help
@section Getting help
@cindex online documentation
@kindex help
*************** apropos reload
*** 1331,1340 ****
@noindent results in:
@smallexample
! @group
! set symbol-reloading -- Set dynamic symbol table reloading multiple times in one run
! show symbol-reloading -- Show dynamic symbol table reloading multiple times in one run
! @end group
@end smallexample
@kindex complete
--- 1379,1390 ----
@noindent results in:
@smallexample
! @c @group
! set symbol-reloading -- Set dynamic symbol table reloading
! multiple times in one run
! show symbol-reloading -- Show dynamic symbol table reloading
! multiple times in one run
! @c @end group
@end smallexample
@kindex complete
*************** if your version of @value{GDBN} comes wi
*** 1433,1439 ****
@end table
! @node Running, Stopping, Commands, Top
@chapter Running Programs Under @value{GDBN}
When you run a program under @value{GDBN}, you must first generate
--- 1483,1489 ----
@end table
! @node Running
@chapter Running Programs Under @value{GDBN}
When you run a program under @value{GDBN}, you must first generate
*************** kill a child process.
*** 1459,1465 ****
* Processes:: Debugging programs with multiple processes
@end menu
! @node Compilation, Starting, Running, Running
@section Compiling for debugging
In order to debug a program effectively, you need to generate
--- 1509,1515 ----
* Processes:: Debugging programs with multiple processes
@end menu
! @node Compilation
@section Compiling for debugging
In order to debug a program effectively, you need to generate
*************** Older versions of the @sc{gnu} C compile
*** 1500,1506 ****
format; if your @sc{gnu} C compiler has this option, do not use it.
@need 2000
! @node Starting, Arguments, Compilation, Running
@section Starting your program
@cindex starting
@cindex running
--- 1550,1556 ----
format; if your @sc{gnu} C compiler has this option, do not use it.
@need 2000
! @node Starting
@section Starting your program
@cindex starting
@cindex running
*************** time @value{GDBN} read its symbols, @val
*** 1576,1582 ****
table, and reads it again. When it does this, @value{GDBN} tries to retain
your current breakpoints.
! @node Arguments, Environment, Starting, Running
@section Your program's arguments
@cindex arguments (to your program)
--- 1626,1632 ----
table, and reads it again. When it does this, @value{GDBN} tries to retain
your current breakpoints.
! @node Arguments
@section Your program's arguments
@cindex arguments (to your program)
*************** it again without arguments.
*** 1610,1616 ****
Show the arguments to give your program when it is started.
@end table
! @node Environment, Working Directory, Arguments, Running
@section Your program's environment
@cindex environment (of your program)
--- 1660,1666 ----
Show the arguments to give your program when it is started.
@end table
! @node Environment
@section Your program's environment
@cindex environment (of your program)
*************** your program. You may wish to move sett
*** 1693,1699 ****
files that are only run when you sign on, such as @file{.login} or
@file{.profile}.
! @node Working Directory, Input/Output, Environment, Running
@section Your program's working directory
@cindex working directory (of your program)
--- 1743,1749 ----
files that are only run when you sign on, such as @file{.login} or
@file{.profile}.
! @node Working Directory
@section Your program's working directory
@cindex working directory (of your program)
*************** Set the @value{GDBN} working directory t
*** 1717,1723 ****
Print the @value{GDBN} working directory.
@end table
! @node Input/Output, Attach, Working Directory, Running
@section Your program's input and output
@cindex redirection
--- 1767,1773 ----
Print the @value{GDBN} working directory.
@end table
! @node Input/Output
@section Your program's input and output
@cindex redirection
*************** When you use the @code{tty} command or r
*** 1771,1777 ****
command, only the input @emph{for your program} is affected. The input
for @value{GDBN} still comes from your terminal.
! @node Attach, Kill Process, Input/Output, Running
@section Debugging an already-running process
@kindex attach
@cindex attach
--- 1821,1827 ----
command, only the input @emph{for your program} is affected. The input
for @value{GDBN} still comes from your terminal.
! @node Attach
@section Debugging an already-running process
@kindex attach
@cindex attach
*************** control whether or not you need to confi
*** 1827,1833 ****
confirm} command (@pxref{Messages/Warnings, ,Optional warnings and
messages}).
! @node Kill Process, Threads, Attach, Running
@section Killing the child process
@table @code
--- 1877,1883 ----
confirm} command (@pxref{Messages/Warnings, ,Optional warnings and
messages}).
! @node Kill Process
@section Killing the child process
@table @code
*************** next type @code{run}, @value{GDBN} notic
*** 1852,1858 ****
reads the symbol table again (while trying to preserve your current
breakpoint settings).
! @node Threads, Processes, Kill Process, Running
@section Debugging programs with multiple threads
@cindex threads of execution
--- 1902,1908 ----
reads the symbol table again (while trying to preserve your current
breakpoint settings).
! @node Threads
@section Debugging programs with multiple threads
@cindex threads of execution
*************** For example,
*** 2017,2025 ****
@example
(@value{GDBP}) info threads
! * 3 system thread 26607 worker (wptr=0x7b09c318 "@@") at quicksort.c:137
! 2 system thread 26606 0x7b0030d8 in __ksleep () from /usr/lib/libc.2
! 1 system thread 27905 0x7b003498 in _brk () from /usr/lib/libc.2
@end example
@table @code
--- 2067,2078 ----
@example
(@value{GDBP}) info threads
! * 3 system thread 26607 worker (wptr=0x7b09c318 "@@") \@*
! at quicksort.c:137
! 2 system thread 26606 0x7b0030d8 in __ksleep () \@*
! from /usr/lib/libc.2
! 1 system thread 27905 0x7b003498 in _brk () \@*
! from /usr/lib/libc.2
@end example
@table @code
*************** programs with multiple threads.
*** 2069,2075 ****
@xref{Set Watchpoints,,Setting watchpoints}, for information about
watchpoints in programs with multiple threads.
! @node Processes, , Threads, Running
@section Debugging programs with multiple processes
@cindex fork, debugging programs which call
--- 2122,2128 ----
@xref{Set Watchpoints,,Setting watchpoints}, for information about
watchpoints in programs with multiple threads.
! @node Processes
@section Debugging programs with multiple processes
@cindex fork, debugging programs which call
*************** You can use the @code{catch} command to
*** 2146,2152 ****
a @code{fork}, @code{vfork}, or @code{exec} call is made. @xref{Set
Catchpoints, ,Setting catchpoints}.
! @node Stopping, Stack, Running, Top
@chapter Stopping and Continuing
The principal purposes of using a debugger are so that you can stop your
--- 2199,2205 ----
a @code{fork}, @code{vfork}, or @code{exec} call is made. @xref{Set
Catchpoints, ,Setting catchpoints}.
! @node Stopping
@chapter Stopping and Continuing
The principal purposes of using a debugger are so that you can stop your
*************** running or not, what process it is, and
*** 2175,2181 ****
* Thread Stops:: Stopping and starting multi-thread programs
@end menu
! @node Breakpoints, Continuing and Stepping, Stopping, Stopping
@section Breakpoints, watchpoints, and catchpoints
@cindex breakpoints
--- 2228,2234 ----
* Thread Stops:: Stopping and starting multi-thread programs
@end menu
! @node Breakpoints
@section Breakpoints, watchpoints, and catchpoints
@cindex breakpoints
*************** all breakpoint in that range are operate
*** 2249,2255 ****
* Error in Breakpoints:: ``Cannot insert breakpoints''
@end menu
! @node Set Breaks, Set Watchpoints, Breakpoints, Breakpoints
@subsection Setting breakpoints
@c FIXME LMB what does GDB do if no code on line of breakpt?
--- 2302,2308 ----
* Error in Breakpoints:: ``Cannot insert breakpoints''
@end menu
! @node Set Breaks
@subsection Setting breakpoints
@c FIXME LMB what does GDB do if no code on line of breakpt?
*************** Shared library events.
*** 2481,2487 ****
@end table
! @node Set Watchpoints, Set Catchpoints, Set Breaks, Breakpoints
@subsection Setting watchpoints
@cindex setting watchpoints
--- 2534,2540 ----
@end table
! @node Set Watchpoints
@subsection Setting watchpoints
@cindex setting watchpoints
*************** when a non-current thread's activity cha
*** 2624,2630 ****
watchpoints, in contrast, watch an expression in all threads.)
@end quotation
! @node Set Catchpoints, Delete Breaks, Set Watchpoints, Breakpoints
@subsection Setting catchpoints
@cindex catchpoints, setting
@cindex exception handlers
--- 2677,2683 ----
watchpoints, in contrast, watch an expression in all threads.)
@end quotation
! @node Set Catchpoints
@subsection Setting catchpoints
@cindex catchpoints, setting
@cindex exception handlers
*************** breakpoints to stop your program when an
*** 2732,2738 ****
raised.
! @node Delete Breaks, Disabling, Set Catchpoints, Breakpoints
@subsection Deleting breakpoints
@cindex clearing breakpoints, watchpoints, catchpoints
--- 2785,2791 ----
raised.
! @node Delete Breaks
@subsection Deleting breakpoints
@cindex clearing breakpoints, watchpoints, catchpoints
*************** breakpoints (@value{GDBN} asks confirmat
*** 2777,2783 ****
confirm off}). You can abbreviate this command as @code{d}.
@end table
! @node Disabling, Conditions, Delete Breaks, Breakpoints
@subsection Disabling breakpoints
@kindex disable breakpoints
--- 2830,2836 ----
confirm off}). You can abbreviate this command as @code{d}.
@end table
! @node Disabling
@subsection Disabling breakpoints
@kindex disable breakpoints
*************** breakpoint of its own, but it does not c
*** 2850,2856 ****
breakpoints; see @ref{Continuing and Stepping, ,Continuing and
stepping}.)
! @node Conditions, Break Commands, Disabling, Breakpoints
@subsection Break conditions
@cindex conditional breakpoints
@cindex breakpoint conditions
--- 2903,2909 ----
breakpoints; see @ref{Continuing and Stepping, ,Continuing and
stepping}.)
! @node Conditions
@subsection Break conditions
@cindex conditional breakpoints
@cindex breakpoint conditions
*************** variables}.
*** 2967,2973 ****
Ignore counts apply to breakpoints, watchpoints, and catchpoints.
! @node Break Commands, Breakpoint Menus, Conditions, Breakpoints
@subsection Breakpoint command lists
@cindex breakpoint commands
--- 3020,3026 ----
Ignore counts apply to breakpoints, watchpoints, and catchpoints.
! @node Break Commands
@subsection Breakpoint command lists
@cindex breakpoint commands
*************** cont
*** 3048,3054 ****
end
@end example
! @node Breakpoint Menus, Error in Breakpoints, Break Commands, Breakpoints
@subsection Breakpoint menus
@cindex overloading
@cindex symbol overloading
--- 3101,3107 ----
end
@end example
! @node Breakpoint Menus
@subsection Breakpoint menus
@cindex overloading
@cindex symbol overloading
*************** Use the "delete" command to delete unwan
*** 3095,3101 ****
@end smallexample
@c @ifclear BARETARGET
! @node Error in Breakpoints, , Breakpoint Menus, Breakpoints
@subsection ``Cannot insert breakpoints''
@c
@c FIXME!! 14/6/95 Is there a real example of this? Let's use it.
--- 3148,3154 ----
@end smallexample
@c @ifclear BARETARGET
! @node Error in Breakpoints
@subsection ``Cannot insert breakpoints''
@c
@c FIXME!! 14/6/95 Is there a real example of this? Let's use it.
*************** When this message is printed, you need t
*** 3148,3154 ****
hardware-assisted breakpoints and watchpoints, and then continue.
! @node Continuing and Stepping, Signals, Breakpoints, Stopping
@section Continuing and stepping
@cindex stepping
--- 3201,3207 ----
hardware-assisted breakpoints and watchpoints, and then continue.
! @node Continuing and Stepping
@section Continuing and stepping
@cindex stepping
*************** proceed until the function returns.
*** 3350,3356 ****
An argument is a repeat count, as in @code{next}.
@end table
! @node Signals, Thread Stops, Continuing and Stepping, Stopping
@section Signals
@cindex signals
--- 3403,3409 ----
An argument is a repeat count, as in @code{next}.
@end table
! @node Signals
@section Signals
@cindex signals
*************** a result of the fatal signal once it saw
*** 3446,3452 ****
you can continue with @samp{signal 0}. @xref{Signaling, ,Giving your
program a signal}.
! @node Thread Stops, , Signals, Stopping
@section Stopping and starting multi-thread programs
When your program has multiple threads (@pxref{Threads,, Debugging
--- 3499,3505 ----
you can continue with @samp{signal 0}. @xref{Signaling, ,Giving your
program a signal}.
! @node Thread Stops
@section Stopping and starting multi-thread programs
When your program has multiple threads (@pxref{Threads,, Debugging
*************** Display the current scheduler locking mo
*** 3531,3537 ****
@end table
! @node Stack, Source, Stopping, Top
@chapter Examining the Stack
When your program has stopped, the first thing you need to know is where it
--- 3584,3590 ----
@end table
! @node Stack
@chapter Examining the Stack
When your program has stopped, the first thing you need to know is where it
*************** currently executing frame and describes
*** 3570,3576 ****
@end menu
! @node Frames, Backtrace, Stack, Stack
@section Stack frames
@cindex frame, definition
--- 3623,3629 ----
@end menu
! @node Frames
@section Stack frames
@cindex frame, definition
*************** and so on upward. These numbers do not
*** 3608,3618 ****
they are assigned by @value{GDBN} to give you a way of designating stack
frames in @value{GDBN} commands.
! @c below produces an acceptable overful hbox. --mew 13aug1993
@cindex frameless execution
Some compilers provide a way to compile functions so that they operate
! without stack frames. (For example, the @code{@value{GCC}} option
! @samp{-fomit-frame-pointer} generates functions without a frame.)
This is occasionally done with heavily used library functions to save
the frame setup time. @value{GDBN} has limited facilities for dealing
with these function invocations. If the innermost function invocation
--- 3661,3675 ----
they are assigned by @value{GDBN} to give you a way of designating stack
frames in @value{GDBN} commands.
! @c The -fomit-frame-pointer below perennially causes hbox overflow
! @c underflow problems.
@cindex frameless execution
Some compilers provide a way to compile functions so that they operate
! without stack frames. (For example, the @value{GCC} option
! @example
! @samp{-fomit-frame-pointer}
! @end example
! generates functions without a frame.)
This is occasionally done with heavily used library functions to save
the frame setup time. @value{GDBN} has limited facilities for dealing
with these function invocations. If the innermost function invocation
*************** to another without printing the frame.
*** 3636,3642 ****
@code{frame}.
@end table
! @node Backtrace, Selection, Frames, Stack
@section Backtraces
@cindex backtraces
--- 3693,3699 ----
@code{frame}.
@end table
! @node Backtrace
@section Backtraces
@cindex backtraces
*************** The display for frame zero does not begi
*** 3699,3705 ****
value, indicating that your program has stopped at the beginning of the
code for line @code{993} of @code{builtin.c}.
! @node Selection, Frame Info, Backtrace, Stack
@section Selecting a frame
Most commands for examining the stack and other data in your program work on
--- 3756,3762 ----
value, indicating that your program has stopped at the beginning of the
code for line @code{993} of @code{builtin.c}.
! @node Selection
@section Selecting a frame
Most commands for examining the stack and other data in your program work on
*************** in @value{GDBN} command scripts, where t
*** 3785,3791 ****
distracting.
@end table
! @node Frame Info, , Selection, Stack
@section Information about a frame
There are several other commands to print information about the selected
--- 3842,3848 ----
distracting.
@end table
! @node Frame Info
@section Information about a frame
There are several other commands to print information about the selected
*************** exception handlers, visit the associated
*** 3861,3867 ****
@end table
! @node Source, Data, Stack, Top
@chapter Examining Source Files
@value{GDBN} can print parts of your program's source, since the debugging
--- 3918,3924 ----
@end table
! @node Source
@chapter Examining Source Files
@value{GDBN} can print parts of your program's source, since the debugging
*************** prefer to use Emacs facilities to view s
*** 3883,3889 ****
* Machine Code:: Source and machine code
@end menu
! @node List, Search, Source, Source
@section Printing source lines
@kindex list
--- 3940,3946 ----
* Machine Code:: Source and machine code
@end menu
! @node List
@section Printing source lines
@kindex list
*************** Specifies the line containing the progra
*** 4000,4006 ****
@var{address} may be any expression.
@end table
! @node Search, Source Path, List, Source
@section Searching source files
@cindex searching
@kindex reverse-search
--- 4057,4063 ----
@var{address} may be any expression.
@end table
! @node Search
@section Searching source files
@cindex searching
@kindex reverse-search
*************** for @var{regexp}. It lists the line tha
*** 4026,4032 ****
this command as @code{rev}.
@end table
! @node Source Path, Machine Code, Search, Source
@section Specifying source directories
@cindex source path
--- 4083,4089 ----
this command as @code{rev}.
@end table
! @node Source Path
@section Specifying source directories
@cindex source path
*************** directories you want in the source path.
*** 4109,4115 ****
directories in one command.
@end enumerate
! @node Machine Code, , Source Path, Source
@section Source and machine code
You can use the command @code{info line} to map source lines to program
--- 4166,4172 ----
directories in one command.
@end enumerate
! @node Machine Code
@section Source and machine code
You can use the command @code{info line} to map source lines to program
*************** assemblers for x86-based targets.
*** 4210,4216 ****
@end table
! @node Data, Languages, Source, Top
@chapter Examining Data
@cindex printing data
--- 4267,4273 ----
@end table
! @node Data
@chapter Examining Data
@cindex printing data
*************** Table}.
*** 4265,4271 ****
* Floating Point Hardware:: Floating point hardware
@end menu
! @node Expressions, Variables, Data, Data
@section Expressions
@cindex expressions
--- 4322,4328 ----
* Floating Point Hardware:: Floating point hardware
@end menu
! @node Expressions
@section Expressions
@cindex expressions
*************** a cast). This construct is allowed rega
*** 4318,4324 ****
normally supposed to reside at @var{addr}.
@end table
! @node Variables, Arrays, Expressions, Data
@section Program variables
The most common kind of expression to use is the name of a variable
--- 4375,4381 ----
normally supposed to reside at @var{addr}.
@end table
! @node Variables
@section Program variables
The most common kind of expression to use is the name of a variable
*************** Program or @sc{gnu} CC, gcc.info, Using
*** 4439,4445 ****
information.
! @node Arrays, Output Formats, Variables, Data
@section Artificial arrays
@cindex artificial array
--- 4496,4502 ----
information.
! @node Arrays
@section Artificial arrays
@cindex artificial array
*************** p dtab[$i++]->fv
*** 4511,4517 ****
@dots{}
@end example
! @node Output Formats, Memory, Arrays, Data
@section Output formats
@cindex formatted output
--- 4568,4574 ----
@dots{}
@end example
! @node Output Formats
@section Output formats
@cindex formatted output
*************** To reprint the last value in the value h
*** 4580,4586 ****
you can use the @code{print} command with just a format and no
expression. For example, @samp{p/x} reprints the last value in hex.
! @node Memory, Auto Display, Output Formats, Data
@section Examining memory
You can use the command @code{x} (for ``examine'') to examine memory in
--- 4637,4643 ----
you can use the @code{print} command with just a format and no
expression. For example, @samp{p/x} reprints the last value in hex.
! @node Memory
@section Examining memory
You can use the command @code{x} (for ``examine'') to examine memory in
*************** If the @code{x} command has a repeat cou
*** 4685,4691 ****
are from the last memory unit printed; this is not the same as the last
address printed if several units were printed on the last line of output.
! @node Auto Display, Print Settings, Memory, Data
@section Automatic display
@cindex automatic display
@cindex display of expressions
--- 4742,4748 ----
are from the last memory unit printed; this is not the same as the last
address printed if several units were printed on the last line of output.
! @node Auto Display
@section Automatic display
@cindex automatic display
@cindex display of expressions
*************** there is no variable @code{last_char}---
*** 4781,4787 ****
automatically. The next time your program stops where @code{last_char}
is meaningful, you can enable the display expression once again.
! @node Print Settings, Value History, Auto Display, Data
@section Print settings
@cindex format options
--- 4838,4844 ----
automatically. The next time your program stops where @code{last_char}
is meaningful, you can enable the display expression once again.
! @node Print Settings
@section Print settings
@cindex format options
*************** Do not pretty print C++ virtual function
*** 5142,5148 ****
Show whether C++ virtual function tables are pretty printed, or not.
@end table
! @node Value History, Convenience Vars, Print Settings, Data
@section Value history
@cindex value history
--- 5199,5205 ----
Show whether C++ virtual function tables are pretty printed, or not.
@end table
! @node Value History
@section Value history
@cindex value history
*************** values are available, @code{show values
*** 5219,5225 ****
Pressing @key{RET} to repeat @code{show values @var{n}} has exactly the
same effect as @samp{show values +}.
! @node Convenience Vars, Registers, Value History, Data
@section Convenience variables
@cindex convenience variables
--- 5276,5282 ----
Pressing @key{RET} to repeat @code{show values @var{n}} has exactly the
same effect as @samp{show values +}.
! @node Convenience Vars
@section Convenience variables
@cindex convenience variables
*************** On HP-UX systems, if you refer to a func
*** 5305,5311 ****
begins with a dollar sign, @value{GDBN} searches for a user or system
name first, before it searches for a convenience variable.
! @node Registers, Floating Point Hardware, Convenience Vars, Data
@section Registers
@cindex registers
--- 5362,5368 ----
begins with a dollar sign, @value{GDBN} searches for a user or system
name first, before it searches for a convenience variable.
! @node Registers
@section Registers
@cindex registers
*************** code generated by your compiler. If som
*** 5404,5410 ****
@value{GDBN} is unable to locate the saved registers, the selected stack
frame makes no difference.
! @node Floating Point Hardware, , Registers, Data
@section Floating point hardware
@cindex floating point
--- 5461,5467 ----
@value{GDBN} is unable to locate the saved registers, the selected stack
frame makes no difference.
! @node Floating Point Hardware
@section Floating point hardware
@cindex floating point
*************** floating point chip. Currently, @samp{i
*** 5420,5426 ****
the ARM and x86 machines.
@end table
! @node Languages, Symbols, Data, Top
@chapter Using @value{GDBN} with Different Languages
@cindex languages
--- 5477,5483 ----
the ARM and x86 machines.
@end table
! @node Languages
@chapter Using @value{GDBN} with Different Languages
@cindex languages
*************** language}.
*** 5446,5452 ****
* Support:: Supported languages
@end menu
! @node Setting, Show, Languages, Languages
@section Switching between source languages
There are two ways to control the working language---either have @value{GDBN}
--- 5503,5509 ----
* Support:: Supported languages
@end menu
! @node Setting
@section Switching between source languages
There are two ways to control the working language---either have @value{GDBN}
*************** program, and will display that source co
*** 5480,5486 ****
* Automatically:: Having @value{GDBN} infer the source language
@end menu
! @node Filenames, Manually, Setting, Setting
@subsection List of filename extensions and languages
If a source file name ends in one of the following extensions, then
--- 5537,5543 ----
* Automatically:: Having @value{GDBN} infer the source language
@end menu
! @node Filenames
@subsection List of filename extensions and languages
If a source file name ends in one of the following extensions, then
*************** Assembler source file. This actually be
*** 5520,5526 ****
In addition, you may set the language associated with a filename
extension. @xref{Show, , Displaying the language}.
! @node Manually, Automatically, Filenames, Setting
@subsection Setting the working language
If you allow @value{GDBN} to set the language automatically,
--- 5577,5583 ----
In addition, you may set the language associated with a filename
extension. @xref{Show, , Displaying the language}.
! @node Manually
@subsection Setting the working language
If you allow @value{GDBN} to set the language automatically,
*************** might not have the effect you intended.
*** 5552,5558 ****
printed would be the value of @code{a}. In Modula-2, this means to compare
@code{a} to the result of @code{b+c}, yielding a @code{BOOLEAN} value.
! @node Automatically, , Manually, Setting
@subsection Having @value{GDBN} infer the source language
To have @value{GDBN} set the working language automatically, use
--- 5609,5615 ----
printed would be the value of @code{a}. In Modula-2, this means to compare
@code{a} to the result of @code{b+c}, yielding a @code{BOOLEAN} value.
! @node Automatically
@subsection Having @value{GDBN} infer the source language
To have @value{GDBN} set the working language automatically, use
*************** written in one source language can be us
*** 5571,5577 ****
a different source language. Using @samp{set language auto} in this
case frees you from having to set the working language manually.
! @node Show, Checks, Setting, Languages
@section Displaying the language
The following commands help you find out which language is the
--- 5628,5634 ----
a different source language. Using @samp{set language auto} in this
case frees you from having to set the working language manually.
! @node Show
@section Displaying the language
The following commands help you find out which language is the
*************** the source language @var{language}.
*** 5613,5619 ****
List all the filename extensions and the associated languages.
@end table
! @node Checks, Support, Show, Languages
@section Type and range checking
@quotation
--- 5670,5676 ----
List all the filename extensions and the associated languages.
@end table
! @node Checks
@section Type and range checking
@quotation
*************** for the default settings of supported la
*** 5646,5652 ****
@cindex type checking
@cindex checks, type
! @node Type Checking, Range Checking, Checks, Checks
@subsection An overview of type checking
Some languages, such as Modula-2, are strongly typed, meaning that the
--- 5703,5709 ----
@cindex type checking
@cindex checks, type
! @node Type Checking
@subsection An overview of type checking
Some languages, such as Modula-2, are strongly typed, meaning that the
*************** is setting it automatically.
*** 5717,5723 ****
@cindex range checking
@cindex checks, range
! @node Range Checking, , Type Checking, Checks
@subsection An overview of range checking
In some languages (such as Modula-2), it is an error to exceed the
--- 5774,5780 ----
@cindex range checking
@cindex checks, range
! @node Range Checking
@subsection An overview of range checking
In some languages (such as Modula-2), it is an error to exceed the
*************** Show the current setting of the range ch
*** 5776,5782 ****
being set automatically by @value{GDBN}.
@end table
! @node Support, , Checks, Languages
@section Supported languages
@value{GDBN} supports C, C++, Fortran, Java, Chill, assembly, and Modula-2.
--- 5833,5839 ----
being set automatically by @value{GDBN}.
@end table
! @node Support
@section Supported languages
@value{GDBN} supports C, C++, Fortran, Java, Chill, assembly, and Modula-2.
*************** language reference or tutorial.
*** 5801,5807 ****
* Chill:: Chill
@end menu
! @node C, Modula-2, Support, Support
@subsection C and C++
@cindex C and C++
--- 5858,5864 ----
* Chill:: Chill
@end menu
! @node C
@subsection C and C++
@cindex C and C++
*************** CC, gcc.info, Using @sc{gnu} CC}, for mo
*** 5836,5842 ****
* Debugging C plus plus:: @value{GDBN} features for C++
@end menu
! @node C Operators, C Constants, C, C
@subsubsection C and C++ operators
@cindex C and C++ operators
--- 5893,5899 ----
* Debugging C plus plus:: @value{GDBN} features for C++
@end menu
! @node C Operators
@subsubsection C and C++ operators
@cindex C and C++ operators
*************** predefined meaning.
*** 5996,6002 ****
* C Constants::
@end menu
! @node C Constants, C plus plus expressions, C Operators, C
@subsubsection C and C++ constants
@cindex C and C++ constants
--- 6053,6059 ----
* C Constants::
@end menu
! @node C Constants
@subsubsection C and C++ constants
@cindex C and C++ constants
*************** and @samp{@{&"hi", &"there", &"fred"@}}
*** 6064,6070 ****
* Debugging C::
@end menu
! @node C plus plus expressions, C Defaults, C Constants, C
@subsubsection C++ expressions
@cindex expressions in C++
--- 6121,6127 ----
* Debugging C::
@end menu
! @node C plus plus expressions
@subsubsection C++ expressions
@cindex expressions in C++
*************** calling virtual functions correctly, pri
*** 6169,6175 ****
objects, calling functions in a base subobject, casting objects, and
invoking user-defined operators.
! @node C Defaults, C Checks, C plus plus expressions, C
@subsubsection C and C++ defaults
@cindex C and C++ defaults
--- 6226,6232 ----
objects, calling functions in a base subobject, casting objects, and
invoking user-defined operators.
! @node C Defaults
@subsubsection C and C++ defaults
@cindex C and C++ defaults
*************** for further details.
*** 6190,6196 ****
@c unimplemented. If (b) changes, it might make sense to let this node
@c appear even if Mod-2 does not, but meanwhile ignore it. roland 16jul93.
! @node C Checks, Debugging C, C Defaults, C
@subsubsection C and C++ type and range checks
@cindex C and C++ checks
--- 6247,6253 ----
@c unimplemented. If (b) changes, it might make sense to let this node
@c appear even if Mod-2 does not, but meanwhile ignore it. roland 16jul93.
! @node C Checks
@subsubsection C and C++ type and range checks
@cindex C and C++ checks
*************** Range checking, if turned on, is done on
*** 6222,6228 ****
indices are not checked, since they are often used to index a pointer
that is not itself an array.
! @node Debugging C, Debugging C plus plus, C Checks, C
@subsubsection @value{GDBN} and C
The @code{set print union} and @code{show print union} commands apply to
--- 6279,6285 ----
indices are not checked, since they are often used to index a pointer
that is not itself an array.
! @node Debugging C
@subsubsection @value{GDBN} and C
The @code{set print union} and @code{show print union} commands apply to
*************** with pointers and a memory allocation fu
*** 6238,6244 ****
* Debugging C plus plus::
@end menu
! @node Debugging C plus plus, , Debugging C, C
@subsubsection @value{GDBN} features for C++
@cindex commands for C++
--- 6295,6301 ----
* Debugging C plus plus::
@end menu
! @node Debugging C plus plus
@subsubsection @value{GDBN} features for C++
@cindex commands for C++
*************** available choices, or to finish the type
*** 6321,6327 ****
@xref{Completion,, Command completion}, for details on how to do this.
@end table
! @node Modula-2, Chill, C, Support
@subsection Modula-2
@cindex Modula-2, @value{GDBN} support
--- 6378,6384 ----
@xref{Completion,, Command completion}, for details on how to do this.
@end table
! @node Modula-2
@subsection Modula-2
@cindex Modula-2, @value{GDBN} support
*************** table.
*** 6345,6351 ****
* GDB/M2:: @value{GDBN} and Modula-2
@end menu
! @node M2 Operators, Built-In Func/Proc, Modula-2, Modula-2
@subsubsection Operators
@cindex Modula-2 operators
--- 6402,6408 ----
* GDB/M2:: @value{GDBN} and Modula-2
@end menu
! @node M2 Operators
@subsubsection Operators
@cindex Modula-2 operators
*************** treats the use of the operator @code{IN}
*** 6469,6475 ****
@end quotation
@cindex Modula-2 built-ins
! @node Built-In Func/Proc, M2 Constants, M2 Operators, Modula-2
@subsubsection Built-in functions and procedures
Modula-2 also makes available several built-in procedures and functions.
--- 6526,6532 ----
@end quotation
@cindex Modula-2 built-ins
! @node Built-In Func/Proc
@subsubsection Built-in functions and procedures
Modula-2 also makes available several built-in procedures and functions.
*************** an error.
*** 6581,6587 ****
@end quotation
@cindex Modula-2 constants
! @node M2 Constants, M2 Defaults, Built-In Func/Proc, Modula-2
@subsubsection Constants
@value{GDBN} allows you to express the constants of Modula-2 in the following
--- 6638,6644 ----
@end quotation
@cindex Modula-2 constants
! @node M2 Constants
@subsubsection Constants
@value{GDBN} allows you to express the constants of Modula-2 in the following
*************** Pointer constants consist of integral va
*** 6630,6636 ****
Set constants are not yet supported.
@end itemize
! @node M2 Defaults, Deviations, M2 Constants, Modula-2
@subsubsection Modula-2 defaults
@cindex Modula-2 defaults
--- 6687,6693 ----
Set constants are not yet supported.
@end itemize
! @node M2 Defaults
@subsubsection Modula-2 defaults
@cindex Modula-2 defaults
*************** code compiled from a file whose name end
*** 6644,6650 ****
working language to Modula-2. @xref{Automatically, ,Having @value{GDBN} set
the language automatically}, for further details.
! @node Deviations, M2 Checks, M2 Defaults, Modula-2
@subsubsection Deviations from standard Modula-2
@cindex Modula-2, deviations from
--- 6701,6707 ----
working language to Modula-2. @xref{Automatically, ,Having @value{GDBN} set
the language automatically}, for further details.
! @node Deviations
@subsubsection Deviations from standard Modula-2
@cindex Modula-2, deviations from
*************** argument.
*** 6674,6680 ****
All built-in procedures both modify @emph{and} return their argument.
@end itemize
! @node M2 Checks, M2 Scope, Deviations, Modula-2
@subsubsection Modula-2 type and range checks
@cindex Modula-2 checks
--- 6731,6737 ----
All built-in procedures both modify @emph{and} return their argument.
@end itemize
! @node M2 Checks
@subsubsection Modula-2 type and range checks
@cindex Modula-2 checks
*************** whose types are not equivalent is an err
*** 6702,6708 ****
Range checking is done on all mathematical operations, assignment, array
index bounds, and all built-in functions and procedures.
! @node M2 Scope, GDB/M2, M2 Checks, Modula-2
@subsubsection The scope operators @code{::} and @code{.}
@cindex scope
@kindex .
--- 6759,6765 ----
Range checking is done on all mathematical operations, assignment, array
index bounds, and all built-in functions and procedures.
! @node M2 Scope
@subsubsection The scope operators @code{::} and @code{.}
@cindex scope
@kindex .
*************** an error if the identifier @var{id} was
*** 6742,6748 ****
module @var{module}, or if @var{id} is not an identifier in
@var{module}.
! @node GDB/M2, , M2 Scope, Modula-2
@subsubsection @value{GDBN} and Modula-2
Some @value{GDBN} commands have little use when debugging Modula-2 programs.
--- 6799,6805 ----
module @var{module}, or if @var{id} is not an identifier in
@var{module}.
! @node GDB/M2
@subsubsection @value{GDBN} and Modula-2
Some @value{GDBN} commands have little use when debugging Modula-2 programs.
*************** address can be specified by an integral
*** 6763,6769 ****
In @value{GDBN} scripts, the Modula-2 inequality operator @code{#} is
interpreted as the beginning of a comment. Use @code{<>} instead.
! @node Chill, , Modula-2, Support
@subsection Chill
The extensions made to @value{GDBN} to support Chill only support output
--- 6820,6826 ----
In @value{GDBN} scripts, the Modula-2 inequality operator @code{#} is
interpreted as the beginning of a comment. Use @code{<>} instead.
! @node Chill
@subsection Chill
The extensions made to @value{GDBN} to support Chill only support output
*************** of @value{GDBN} which support these topi
*** 6785,6791 ****
* Chill defaults::
@end menu
! @node How modes are displayed, Locations, Chill, Chill
@subsubsection How modes are displayed
The Chill Datatype- (Mode) support of @value{GDBN} is directly related
--- 6842,6848 ----
* Chill defaults::
@end menu
! @node How modes are displayed
@subsubsection How modes are displayed
The Chill Datatype- (Mode) support of @value{GDBN} is directly related
*************** type = SET (karli = 10, susi = 20, fritz
*** 6813,6822 ****
@end smallexample
If the type is an unnumbered set the set element values are omitted.
@item
! @emph{Range Mode} which is displayed by @code{type = <basemode>
! (<lower bound> : <upper bound>)}, where @code{<lower bound>, <upper
! bound>} can be of any discrete literal expression (e.g. set element
! names).
@end itemize
@item @r{@emph{Powerset Mode:}}
--- 6870,6881 ----
@end smallexample
If the type is an unnumbered set the set element values are omitted.
@item
! @emph{Range Mode} which is displayed by
! @smallexample
! @code{type = <basemode>(<lower bound> : <upper bound>)}
! @end smallexample
! where @code{<lower bound>, <upper bound>} can be of any discrete literal
! expression (e.g. set element names).
@end itemize
@item @r{@emph{Powerset Mode:}}
*************** type, and is therefore not really of int
*** 6852,6862 ****
@item @r{@emph{Synchronization Modes:}}
@itemize @bullet
@item
! @emph{Event Mode} which is displayed by @code{EVENT (<event length>)},
where @code{(<event length>)} is optional.
@item
! @emph{Buffer Mode} which is displayed by @code{BUFFER (<buffer length>)
! <buffer element mode>}, where @code{(<buffer length>)} is optional.
@end itemize
@item @r{@emph{Timing Modes:}}
--- 6911,6927 ----
@item @r{@emph{Synchronization Modes:}}
@itemize @bullet
@item
! @emph{Event Mode} which is displayed by
! @smallexample
! @code{EVENT (<event length>)}
! @end smallexample
where @code{(<event length>)} is optional.
@item
! @emph{Buffer Mode} which is displayed by
! @smallexample
! @code{BUFFER (<buffer length>)<buffer element mode>}
! @end smallexample
! where @code{(<buffer length>)} is optional.
@end itemize
@item @r{@emph{Timing Modes:}}
*************** Real Modes are predefined with @code{REA
*** 6873,6884 ****
@item @r{@emph{String Modes:}}
@itemize @bullet
@item
! @emph{Character String Mode} which is displayed by @code{CHARS(<string
! length>)}, followed by the keyword @code{VARYING} if the String Mode is
! a varying mode
@item
! @emph{Bit String Mode} which is displayed by @code{BOOLS(<string
! length>)}.
@end itemize
@item @r{@emph{Array Mode:}}
--- 6938,6955 ----
@item @r{@emph{String Modes:}}
@itemize @bullet
@item
! @emph{Character String Mode} which is displayed by
! @smallexample
! @code{CHARS(<string length>)}
! @end smallexample
! followed by the keyword @code{VARYING} if the String Mode is a varying
! mode
@item
! @emph{Bit String Mode} which is displayed by
! @smallexample
! @code{BOOLS(<string
! length>)}
! @end smallexample
@end itemize
@item @r{@emph{Array Mode:}}
*************** type = STRUCT (
*** 6914,6920 ****
@end smallexample
@end table
! @node Locations, Values and their Operations, How modes are displayed, Chill
@subsubsection Locations and their accesses
A location in Chill is an object which can contain values.
--- 6985,6991 ----
@end smallexample
@end table
! @node Locations
@subsubsection Locations and their accesses
A location in Chill is an object which can contain values.
*************** represents the address where the referen
*** 6942,6952 ****
value of the location referenced by the pointer, use the dereference
operator @samp{->}.
! Values of procedure mode locations are displayed by @code{@{ PROC
(<argument modes> ) <return mode> @} <address> <name of procedure
! location>}. @code{<argument modes>} is a list of modes according to the
! parameter specification of the procedure and @code{<address>} shows the
! address of the entry point.
@ignore
Locations of instance modes are displayed just like a structure with two
--- 7013,7027 ----
value of the location referenced by the pointer, use the dereference
operator @samp{->}.
! Values of procedure mode locations are displayed by
! @smallexample
! @code{@{ PROC
(<argument modes> ) <return mode> @} <address> <name of procedure
! location>}
! @end smallexample
! @code{<argument modes>} is a list of modes according to the parameter
! specification of the procedure and @code{<address>} shows the address of
! the entry point.
@ignore
Locations of instance modes are displayed just like a structure with two
*************** therefore the result can be quite confus
*** 6995,7001 ****
(@value{GDBP}) print int (s(3 up 4)) XXX TO be filled in !! XXX
@end smallexample
! @node Values and their Operations, Chill type and range checks, Locations, Chill
@subsubsection Values and their Operations
Values are used to alter locations, to investigate complex structures in
--- 7070,7076 ----
(@value{GDBP}) print int (s(3 up 4)) XXX TO be filled in !! XXX
@end smallexample
! @node Values and their Operations
@subsubsection Values and their Operations
Values are used to alter locations, to investigate complex structures in
*************** same manner as in Chill programs refer t
*** 7065,7071 ****
@end itemize
@item String Element Value
! A string element value is specified by @code{<string value>(<index>)},
where @code{<index>} is a integer expression. It delivers a character
value which is equivalent to the character indexed by @code{<index>} in
the string.
--- 7140,7149 ----
@end itemize
@item String Element Value
! A string element value is specified by
! @smallexample
! @code{<string value>(<index>)}
! @end smallexample
where @code{<index>} is a integer expression. It delivers a character
value which is equivalent to the character indexed by @code{<index>} in
the string.
*************** expression, then this procedure is calle
*** 7102,7109 ****
effects. This can lead to confusing results if used carelessly.}.
Values of duration mode locations are represented by @code{ULONG} literals.
- Values of time mode locations are represented by @code{TIME(<secs>:<nsecs>)}.
@ignore
This is not implemented yet:
--- 7180,7191 ----
effects. This can lead to confusing results if used carelessly.}.
Values of duration mode locations are represented by @code{ULONG} literals.
+
+ Values of time mode locations appear as
+ @smallexample
+ @code{TIME(<secs>:<nsecs>)}
+ @end smallexample
@ignore
This is not implemented yet:
*************** Membership operator.
*** 7198,7204 ****
@end table
@end table
! @node Chill type and range checks, Chill defaults, Values and their Operations, Chill
@subsubsection Chill type and range checks
@value{GDBN} considers two Chill variables mode equivalent if the sizes
--- 7280,7286 ----
@end table
@end table
! @node Chill type and range checks
@subsubsection Chill type and range checks
@value{GDBN} considers two Chill variables mode equivalent if the sizes
*************** off}.
*** 7224,7230 ****
see last paragraph ?
@end ignore
! @node Chill defaults, , Chill type and range checks, Chill
@subsubsection Chill defaults
If type and range checking are set automatically by @value{GDBN}, they
--- 7306,7312 ----
see last paragraph ?
@end ignore
! @node Chill defaults
@subsubsection Chill defaults
If type and range checking are set automatically by @value{GDBN}, they
*************** code compiled from a file whose name end
*** 7237,7243 ****
working language to Chill. @xref{Automatically, ,Having @value{GDBN} set
the language automatically}, for further details.
! @node Symbols, Altering, Languages, Top
@chapter Examining the Symbol Table
The commands described in this chapter allow you to inquire about the
--- 7319,7325 ----
working language to Chill. @xref{Automatically, ,Having @value{GDBN} set
the language automatically}, for further details.
! @node Symbols
@chapter Examining the Symbol Table
The commands described in this chapter allow you to inquire about the
*************** Replace symbol definitions for the corre
*** 7402,7413 ****
object file with a particular name is seen again.
@item set symbol-reloading off
! Do not replace symbol definitions when re-encountering object files of
! the same name. This is the default state; if you are not running on a
! system that permits automatically relinking modules, you should leave
! @code{symbol-reloading} off, since otherwise @value{GDBN} may discard symbols
! when linking large programs, that may contain several modules (from
! different directories or libraries) with the same name.
@kindex show symbol-reloading
@item show symbol-reloading
--- 7484,7496 ----
object file with a particular name is seen again.
@item set symbol-reloading off
! Do not replace symbol definitions when encountering object files of the
! same name more than once. This is the default state; if you are not
! running on a system that permits automatic relinking of modules, you
! should leave @code{symbol-reloading} off, since otherwise @value{GDBN}
! may discard symbols when linking large programs, that may contain
! several modules (from different directories or libraries) with the same
! name.
@kindex show symbol-reloading
@item show symbol-reloading
*************** required for each object file from which
*** 7459,7465 ****
@value{GDBN} reads symbols (in the description of @code{symbol-file}).
@end table
! @node Altering, GDB Files, Symbols, Top
@chapter Altering Execution
Once you think you have found an error in your program, you might want to
--- 7542,7548 ----
@value{GDBN} reads symbols (in the description of @code{symbol-file}).
@end table
! @node Altering
@chapter Altering Execution
Once you think you have found an error in your program, you might want to
*************** address, or even return prematurely from
*** 7481,7487 ****
* Patching:: Patching your program
@end menu
! @node Assignment, Jumping, Altering, Altering
@section Assignment to variables
@cindex assignment
--- 7564,7570 ----
* Patching:: Patching your program
@end menu
! @node Assignment
@section Assignment to variables
@cindex assignment
*************** $2 = 1
*** 7552,7558 ****
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/smith/cc_progs/a.out
! "/home/smith/cc_progs/a.out": can't open to read symbols: Invalid bfd target.
(@value{GDBP}) show g
The current BFD target is "=4".
@end group
--- 7635,7642 ----
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/smith/cc_progs/a.out
! "/home/smith/cc_progs/a.out": can't open to read symbols:
! Invalid bfd target.
(@value{GDBP}) show g
The current BFD target is "=4".
@end group
*************** set @{int@}0x83040 = 4
*** 7587,7593 ****
@noindent
stores the value 4 into that memory location.
! @node Jumping, Signaling, Assignment, Altering
@section Continuing at a different address
Ordinarily, when you continue your program, you do so at the place where
--- 7671,7677 ----
@noindent
stores the value 4 into that memory location.
! @node Jumping
@section Continuing at a different address
Ordinarily, when you continue your program, you do so at the place where
*************** that has already executed, in order to e
*** 7640,7646 ****
detail.
@c @group
! @node Signaling, Returning, Jumping, Altering
@section Giving your program a signal
@table @code
--- 7724,7730 ----
detail.
@c @group
! @node Signaling
@section Giving your program a signal
@table @code
*************** the signal handling tables (@pxref{Signa
*** 7669,7675 ****
passes the signal directly to your program.
! @node Returning, Calling, Signaling, Altering
@section Returning from a function
@table @code
--- 7753,7759 ----
passes the signal directly to your program.
! @node Returning
@section Returning from a function
@table @code
*************** returned. In contrast, the @code{finish
*** 7700,7706 ****
and Stepping, ,Continuing and stepping}) resumes execution until the
selected stack frame returns naturally.
! @node Calling, Patching, Returning, Altering
@section Calling program functions
@cindex calling functions
--- 7784,7790 ----
and Stepping, ,Continuing and stepping}) resumes execution until the
selected stack frame returns naturally.
! @node Calling
@section Calling program functions
@cindex calling functions
*************** calls a function in the target. This is
*** 7722,7728 ****
method of putting the scratch area on the stack does not work in systems
that have separate instruction and data spaces.
! @node Patching, , Calling, Altering
@section Patching programs
@cindex patching binaries
--- 7806,7812 ----
method of putting the scratch area on the stack does not work in systems
that have separate instruction and data spaces.
! @node Patching
@section Patching programs
@cindex patching binaries
*************** Display whether executable files and cor
*** 7757,7763 ****
as well as reading.
@end table
! @node GDB Files, Targets, Altering, Top
@chapter @value{GDBN} Files
@value{GDBN} needs to know the file name of the program to be debugged,
--- 7841,7847 ----
as well as reading.
@end table
! @node GDB Files
@chapter @value{GDBN} Files
@value{GDBN} needs to know the file name of the program to be debugged,
*************** program. To debug a core dump of a prev
*** 7770,7776 ****
* Symbol Errors:: Errors reading symbol files
@end menu
! @node Files, Symbol Errors, GDB Files, GDB Files
@section Commands to specify files
@cindex symbol table
--- 7854,7860 ----
* Symbol Errors:: Errors reading symbol files
@end menu
! @node Files
@section Commands to specify files
@cindex symbol table
*************** directories to search, just as the shell
*** 7799,7805 ****
to run. You can change the value of this variable, for both @value{GDBN}
and your program, using the @code{path} command.
! On systems with memory-mapped files, an auxiliary file
@file{@var{filename}.syms} may hold symbol table information for
@var{filename}. If so, @value{GDBN} maps in the symbol table from
@file{@var{filename}.syms}, starting up more quickly. See the
--- 7883,7889 ----
to run. You can change the value of this variable, for both @value{GDBN}
and your program, using the @code{path} command.
! On systems with memory-mapped files, an auxiliary file named
@file{@var{filename}.syms} may hold symbol table information for
@var{filename}. If so, @value{GDBN} maps in the symbol table from
@file{@var{filename}.syms}, starting up more quickly. See the
*************** Otherwise, symbols must be loaded manual
*** 8050,8056 ****
Display the current autoloading size threshold, in megabytes.
@end table
! @node Symbol Errors, , Files, GDB Files
@section Errors reading symbol files
While reading a symbol file, @value{GDBN} occasionally encounters problems,
--- 8134,8140 ----
Display the current autoloading size threshold, in megabytes.
@end table
! @node Symbol Errors
@section Errors reading symbol files
While reading a symbol file, @value{GDBN} occasionally encounters problems,
*************** it.
*** 8139,8145 ****
@end table
! @node Targets, Configurations, GDB Files, Top
@chapter Specifying a Debugging Target
@cindex debugging target
--- 8223,8229 ----
@end table
! @node Targets
@chapter Specifying a Debugging Target
@cindex debugging target
*************** command to specify one of the target typ
*** 8165,8171 ****
@end menu
! @node Active Targets, Target Commands, Targets, Targets
@section Active targets
@cindex stacking targets
--- 8249,8255 ----
@end menu
! @node Active Targets
@section Active targets
@cindex stacking targets
*************** files}). To specify as a target a proce
*** 8200,8206 ****
the @code{attach} command (@pxref{Attach, ,Debugging an already-running
process}).
! @node Target Commands, Byte Order, Active Targets, Targets
@section Commands for managing targets
@table @code
--- 8284,8290 ----
the @code{attach} command (@pxref{Attach, ,Debugging an already-running
process}).
! @node Target Commands
@section Commands for managing targets
@table @code
*************** specifies a fixed address.
*** 8332,8338 ****
@code{load} does not repeat if you press @key{RET} again after using it.
@end table
! @node Byte Order, Remote, Target Commands, Targets
@section Choosing target byte order
@cindex choosing target byte order
--- 8416,8422 ----
@code{load} does not repeat if you press @key{RET} again after using it.
@end table
! @node Byte Order
@section Choosing target byte order
@cindex choosing target byte order
*************** Note that these commands merely adjust i
*** 8372,8378 ****
data on the host, and that they have absolutely no effect on the
target system.
! @node Remote, KOD, Byte Order, Targets
@section Remote debugging
@cindex remote debugging
--- 8456,8462 ----
data on the host, and that they have absolutely no effect on the
target system.
! @node Remote
@section Remote debugging
@cindex remote debugging
*************** configuration of @value{GDBN}; use @code
*** 8396,8402 ****
* Remote Serial:: @value{GDBN} remote serial protocol
@end menu
! @node Remote Serial, , Remote, Remote
@subsection The @value{GDBN} remote serial protocol
@cindex remote serial debugging, overview
--- 8480,8486 ----
* Remote Serial:: @value{GDBN} remote serial protocol
@end menu
! @node Remote Serial
@subsection The @value{GDBN} remote serial protocol
@cindex remote serial debugging, overview
*************** recently added stubs.
*** 8494,8500 ****
* NetWare:: Using the `gdbserve.nlm' program
@end menu
! @node Stub Contents, Bootstrapping, Remote Serial, Remote Serial
@subsubsection What the stub can do for you
@cindex remote serial stub
--- 8578,8584 ----
* NetWare:: Using the `gdbserve.nlm' program
@end menu
! @node Stub Contents
@subsubsection What the stub can do for you
@cindex remote serial stub
*************** to make certain your program stops at a
*** 8545,8551 ****
start of your debugging session.
@end table
! @node Bootstrapping, Debug Session, Stub Contents, Remote Serial
@subsubsection What you must do for the stub
@cindex remote stub, support routines
--- 8629,8635 ----
start of your debugging session.
@end table
! @node Bootstrapping
@subsubsection What you must do for the stub
@cindex remote stub, support routines
*************** but in general the stubs are likely to u
*** 8636,8642 ****
subroutines which @code{@value{GCC}} generates as inline code.
! @node Debug Session, Protocol, Bootstrapping, Remote Serial
@subsubsection Putting it all together
@cindex remote serial debugging summary
--- 8720,8726 ----
subroutines which @code{@value{GCC}} generates as inline code.
! @node Debug Session
@subsubsection Putting it all together
@cindex remote serial debugging summary
*************** steps.
*** 8645,8651 ****
@enumerate
@item
! Make sure you have the supporting low-level routines
(@pxref{Bootstrapping,,What you must do for the stub}):
@display
@code{getDebugChar}, @code{putDebugChar},
--- 8729,8735 ----
@enumerate
@item
! Make sure you have defined the supporting low-level routines
(@pxref{Bootstrapping,,What you must do for the stub}):
@display
@code{getDebugChar}, @code{putDebugChar},
*************** If you type @kbd{y}, @value{GDBN} abando
*** 8742,8748 ****
remote} again to connect once more.) If you type @kbd{n}, @value{GDBN}
goes back to waiting.
! @node Protocol, Server, Debug Session, Remote Serial
@subsubsection Communication protocol
@cindex debugging stub, example
--- 8826,8832 ----
remote} again to connect once more.) If you type @kbd{n}, @value{GDBN}
goes back to waiting.
! @node Protocol
@subsubsection Communication protocol
@cindex debugging stub, example
*************** bytes. For a software breakpoint, @var{
*** 9264,9270 ****
the instruction to be patched. For hardware breakpoints and watchpoints
@var{length} specifies the memory region to be monitored. To avoid
potential problems with duplicate packets, the operations should be
! implemented in an ident-potentent way.
@item
@tab reply @code{E}@var{NN}
@tab for an error
--- 9348,9354 ----
the instruction to be patched. For hardware breakpoints and watchpoints
@var{length} specifies the memory region to be monitored. To avoid
potential problems with duplicate packets, the operations should be
! implemented in an idempotent way.
@item
@tab reply @code{E}@var{NN}
@tab for an error
*************** applicable for certains sorts of targets
*** 9312,9325 ****
@tab
The process terminated with signal @var{AA}.
! @item @code{N}@var{AA}@code{;}@var{tttttttt}@code{;}@var{dddddddd}@code{;}@var{bbbbbbbb} @strong{(obsolete)}
@tab
! @var{AA} = signal number; @var{tttttttt} = address of symbol "_start";
! @var{dddddddd} = base of data section; @var{bbbbbbbb} = base of bss
! section. @emph{Note: only used by Cisco Systems targets. The difference
! between this reply and the "qOffsets" query is that the 'N' packet may
! arrive spontaneously whereas the 'qOffsets' is a query initiated by the
! host debugger.}
@item @code{O}@var{XX...}
@tab
--- 9396,9409 ----
@tab
The process terminated with signal @var{AA}.
! @item @code{N}@var{AA}@code{;}@var{t...}@code{;}@var{d...}@code{;}@var{b...} @strong{(obsolete)}
@tab
! @var{AA} = signal number; @var{t...} = address of symbol "_start";
! @var{d...} = base of data section; @var{b...} = base of bss section.
! @emph{Note: only used by Cisco Systems targets. The difference between
! this reply and the "qOffsets" query is that the 'N' packet may arrive
! spontaneously whereas the 'qOffsets' is a query initiated by the host
! debugger.}
@item @code{O}@var{XX...}
@tab
*************** Example sequence of a target being stepp
*** 9536,9542 ****
<- @code{+}
@end example
! @node Server, NetWare, Protocol, Remote Serial
@subsubsection Using the @code{gdbserver} program
@kindex gdbserver
--- 9620,9626 ----
<- @code{+}
@end example
! @node Server
@subsubsection Using the @code{gdbserver} program
@kindex gdbserver
*************** text depends on the host system, but whi
*** 9638,9644 ****
@samp{Connection refused}.
@end table
! @node NetWare, , Server, Remote Serial
@subsubsection Using the @code{gdbserve.nlm} program
@kindex gdbserve.nlm
--- 9722,9728 ----
@samp{Connection refused}.
@end table
! @node NetWare
@subsubsection Using the @code{gdbserve.nlm} program
@kindex gdbserve.nlm
*************** argument is a device name (usually a ser
*** 9695,9701 ****
communications with the server via serial line @file{/dev/ttyb}.
@end table
! @node KOD, , Remote, Targets
@section Kernel Object Display
@cindex kernel object display
--- 9779,9785 ----
communications with the server via serial line @file{/dev/ttyb}.
@end table
! @node KOD
@section Kernel Object Display
@cindex kernel object display
*************** There is currently no way to determine w
*** 9734,9740 ****
is supported other than to try it.
! @node Configurations, Controlling GDB, Targets, Top
@chapter Configuration-Specific Information
While nearly all @value{GDBN} commands are available for all native and
--- 9818,9824 ----
is supported other than to try it.
! @node Configurations
@chapter Configuration-Specific Information
While nearly all @value{GDBN} commands are available for all native and
*************** are quite different from each other.
*** 9754,9760 ****
* Architectures::
@end menu
! @node Native, Embedded OS, Configurations, Configurations
@section Native
This section describes details specific to particular native
--- 9838,9844 ----
* Architectures::
@end menu
! @node Native
@section Native
This section describes details specific to particular native
*************** configurations.
*** 9765,9778 ****
* SVR4 Process Information:: SVR4 process information
@end menu
! @node HP-UX, SVR4 Process Information, Native, Native
@subsection HP-UX
On HP-UX systems, if you refer to a function or variable name that
begins with a dollar sign, @value{GDBN} searches for a user or system
name first, before it searches for a convenience variable.
! @node SVR4 Process Information, , HP-UX, Native
@subsection SVR4 process information
@kindex /proc
--- 9849,9862 ----
* SVR4 Process Information:: SVR4 process information
@end menu
! @node HP-UX
@subsection HP-UX
On HP-UX systems, if you refer to a function or variable name that
begins with a dollar sign, @value{GDBN} searches for a user or system
name first, before it searches for a convenience variable.
! @node SVR4 Process Information
@subsection SVR4 process information
@kindex /proc
*************** received.
*** 9817,9823 ****
Show all the above information about the process.
@end table
! @node Embedded OS, Embedded Processors, Native, Configurations
@section Embedded Operating Systems
This section describes configurations involving the debugging of
--- 9901,9907 ----
Show all the above information about the process.
@end table
! @node Embedded OS
@section Embedded Operating Systems
This section describes configurations involving the debugging of
*************** architectures.
*** 9831,9837 ****
@value{GDBN} includes the ability to debug programs running on
various real-time operating systems.
! @node VxWorks, , Embedded OS, Embedded OS
@subsection Using @value{GDBN} with VxWorks
@cindex VxWorks
--- 9915,9921 ----
@value{GDBN} includes the ability to debug programs running on
various real-time operating systems.
! @node VxWorks
@subsection Using @value{GDBN} with VxWorks
@cindex VxWorks
*************** run @value{GDBN}. From your Unix host,
*** 9898,9904 ****
* VxWorks Attach:: Running tasks
@end menu
! @node VxWorks Connection, VxWorks Download, VxWorks, VxWorks
@subsubsection Connecting to VxWorks
The @value{GDBN} command @code{target} lets you connect to a VxWorks target on the
--- 9982,9988 ----
* VxWorks Attach:: Running tasks
@end menu
! @node VxWorks Connection
@subsubsection Connecting to VxWorks
The @value{GDBN} command @code{target} lets you connect to a VxWorks target on the
*************** When this happens, add the appropriate d
*** 9931,9937 ****
the @value{GDBN} command @code{path}, and execute the @code{target}
command again.
! @node VxWorks Download, VxWorks Attach, VxWorks Connection, VxWorks
@subsubsection VxWorks download
@cindex download to VxWorks
--- 10015,10021 ----
the @value{GDBN} command @code{path}, and execute the @code{target}
command again.
! @node VxWorks Download
@subsubsection VxWorks download
@cindex download to VxWorks
*************** history. (This is necessary in order to
*** 9977,9983 ****
debugger's data structures that reference the target system's symbol
table.)
! @node VxWorks Attach, , VxWorks Download, VxWorks
@subsubsection Running tasks
@cindex running VxWorks tasks
--- 10061,10067 ----
debugger's data structures that reference the target system's symbol
table.)
! @node VxWorks Attach
@subsubsection Running tasks
@cindex running VxWorks tasks
*************** where @var{task} is the VxWorks hexadeci
*** 9993,9999 ****
or suspended when you attach to it. Running tasks are suspended at
the time of attachment.
! @node Embedded Processors, Architectures, Embedded OS, Configurations
@section Embedded Processors
This section goes into details specific to particular embedded
--- 10077,10083 ----
or suspended when you attach to it. Running tasks are suspended at
the time of attachment.
! @node Embedded Processors
@section Embedded Processors
This section goes into details specific to particular embedded
*************** configurations.
*** 10018,10024 ****
* Z8000:: Zilog Z8000
@end menu
! @node A29K Embedded, ARM, Embedded Processors, Embedded Processors
@subsection AMD A29K Embedded
@menu
--- 10102,10108 ----
* Z8000:: Zilog Z8000
@end menu
! @node A29K Embedded
@subsection AMD A29K Embedded
@menu
*************** name of the program to be debugged, as i
*** 10046,10052 ****
@end table
! @node A29K UDI, A29K EB29K, A29K Embedded, A29K Embedded
@subsubsection A29K UDI
@cindex UDI
--- 10130,10136 ----
@end table
! @node A29K UDI
@subsubsection A29K UDI
@cindex UDI
*************** working directory, you must set the envi
*** 10070,10076 ****
to its pathname.
@end table
! @node A29K EB29K, Comms (EB29K), A29K UDI, A29K Embedded
@subsubsection EBMON protocol for AMD29K
@cindex EB29K board
--- 10154,10160 ----
to its pathname.
@end table
! @node A29K EB29K
@subsubsection EBMON protocol for AMD29K
@cindex EB29K board
*************** board) and a serial port on the Unix sys
*** 10085,10091 ****
assume you've hooked the cable between the PC's @file{COM1} port and
@file{/dev/ttya} on the Unix system.
! @node Comms (EB29K), gdb-EB29K, A29K EB29K, A29K Embedded
@subsubsection Communications setup
The next step is to set up the PC's port, by doing something like this
--- 10169,10175 ----
assume you've hooked the cable between the PC's @file{COM1} port and
@file{/dev/ttya} on the Unix system.
! @node Comms (EB29K)
@subsubsection Communications setup
The next step is to set up the PC's port, by doing something like this
*************** other way---perhaps floppy-disk transfer
*** 10207,10213 ****
from the Unix system to the PC; @value{GDBN} does @emph{not} download it over the
serial line.
! @node gdb-EB29K, Remote Log, Comms (EB29K), A29K Embedded
@subsubsection EB29K cross-debugging
Finally, @code{cd} to the directory containing an image of your 29K
--- 10291,10297 ----
from the Unix system to the PC; @value{GDBN} does @emph{not} download it over the
serial line.
! @node gdb-EB29K
@subsubsection EB29K cross-debugging
Finally, @code{cd} to the directory containing an image of your 29K
*************** once again, after your @value{GDBN} sess
*** 10251,10257 ****
Type @kbd{CTTY con} to return command input to the main DOS console,
and type @kbd{~.} to leave @code{tip} or @code{cu}.
! @node Remote Log, , gdb-EB29K, A29K Embedded
@subsubsection Remote log
@kindex eb.log
@cindex log file for EB29K
--- 10335,10341 ----
Type @kbd{CTTY con} to return command input to the main DOS console,
and type @kbd{~.} to leave @code{tip} or @code{cu}.
! @node Remote Log
@subsubsection Remote log
@kindex eb.log
@cindex log file for EB29K
*************** of the commands sent to it. Running @sa
*** 10263,10269 ****
another window often helps to understand trouble with @code{EBMON}, or
unexpected events on the PC side of the connection.
! @node ARM, H8/300, A29K Embedded, Embedded Processors
@subsection ARM
@table @code
--- 10347,10353 ----
another window often helps to understand trouble with @code{EBMON}, or
unexpected events on the PC side of the connection.
! @node ARM
@subsection ARM
@table @code
*************** ARM Demon monitor.
*** 10280,10286 ****
@end table
! @node H8/300, H8/500, ARM, Embedded Processors
@subsection Hitachi H8/300
@table @code
--- 10364,10370 ----
@end table
! @node H8/300
@subsection Hitachi H8/300
@table @code
*************** what speed to use over the serial device
*** 10337,10343 ****
* Hitachi Special:: Special @value{GDBN} commands for Hitachi micros.
@end menu
! @node Hitachi Boards, Hitachi ICE, H8/300, H8/300
@subsubsection Connecting to Hitachi boards
@c only for Unix hosts
--- 10421,10427 ----
* Hitachi Special:: Special @value{GDBN} commands for Hitachi micros.
@end menu
! @node Hitachi Boards
@subsubsection Connecting to Hitachi boards
@c only for Unix hosts
*************** to detect program completion.
*** 10450,10456 ****
In either case, @value{GDBN} sees the effect of a @sc{reset} on the
development board as a ``normal exit'' of your program.
! @node Hitachi ICE, Hitachi Special, Hitachi Boards, H8/300
@subsubsection Using the E7000 in-circuit emulator
@kindex target e7000@r{, with Hitachi ICE}
--- 10534,10540 ----
In either case, @value{GDBN} sees the effect of a @sc{reset} on the
development board as a ``normal exit'' of your program.
! @node Hitachi ICE
@subsubsection Using the E7000 in-circuit emulator
@kindex target e7000@r{, with Hitachi ICE}
*************** If your E7000 is installed as a host on
*** 10470,10476 ****
specify its hostname; @value{GDBN} uses @code{telnet} to connect.
@end table
! @node Hitachi Special, , Hitachi ICE, H8/300
@subsubsection Special @value{GDBN} commands for Hitachi micros
Some @value{GDBN} commands are available only for the H8/300:
--- 10554,10560 ----
specify its hostname; @value{GDBN} uses @code{telnet} to connect.
@end table
! @node Hitachi Special
@subsubsection Special @value{GDBN} commands for Hitachi micros
Some @value{GDBN} commands are available only for the H8/300:
*************** to check which variant is currently in e
*** 10487,10493 ****
@end table
! @node H8/500, i960, H8/300, Embedded Processors
@subsection H8/500
@table @code
--- 10571,10577 ----
@end table
! @node H8/500
@subsection H8/500
@table @code
*************** memory}. The accepted values for @var{m
*** 10503,10509 ****
@end table
! @node i960, M32R/D, H8/500, Embedded Processors
@subsection Intel i960
@table @code
--- 10587,10593 ----
@end table
! @node i960
@subsection Intel i960
@table @code
*************** downloads @var{filename} to the 960 as w
*** 10556,10562 ****
* Nindy Reset:: Nindy reset command
@end menu
! @node Nindy Startup, Nindy Options, i960, i960
@subsubsection Startup with Nindy
If you simply start @code{@value{GDBP}} without using any command-line
--- 10640,10646 ----
* Nindy Reset:: Nindy reset command
@end menu
! @node Nindy Startup
@subsubsection Startup with Nindy
If you simply start @code{@value{GDBP}} without using any command-line
*************** simply start up with no Nindy connection
*** 10574,10580 ****
with an empty line. If you do this and later wish to attach to Nindy,
use @code{target} (@pxref{Target Commands, ,Commands for managing targets}).
! @node Nindy Options, Nindy Reset, Nindy Startup, i960
@subsubsection Options for Nindy
These are the startup options for beginning your @value{GDBN} session with a
--- 10658,10664 ----
with an empty line. If you do this and later wish to attach to Nindy,
use @code{target} (@pxref{Target Commands, ,Commands for managing targets}).
! @node Nindy Options
@subsubsection Options for Nindy
These are the startup options for beginning your @value{GDBN} session with a
*************** The standard @samp{-b} option controls t
*** 10617,10623 ****
port.
@c @group
! @node Nindy Reset, , Nindy Options, i960
@subsubsection Nindy reset command
@table @code
--- 10701,10707 ----
port.
@c @group
! @node Nindy Reset
@subsubsection Nindy reset command
@table @code
*************** a break is detected.
*** 10630,10636 ****
@end table
@c @end group
! @node M32R/D, M68K, i960, Embedded Processors
@subsection Mitsubishi M32R/D
@table @code
--- 10714,10720 ----
@end table
@c @end group
! @node M32R/D
@subsection Mitsubishi M32R/D
@table @code
*************** Mitsubishi M32R/D ROM monitor.
*** 10641,10647 ****
@end table
! @node M68K, M88K, M32R/D, Embedded Processors
@subsection M68k
The Motorola m68k configuration includes ColdFire support, and
--- 10725,10731 ----
@end table
! @node M68K
@subsection M68k
The Motorola m68k configuration includes ColdFire support, and
*************** ROMBUG ROM monitor for OS/9000.
*** 10692,10698 ****
@end table
! @node M88K, MIPS Embedded, M68K, Embedded Processors
@subsection M88K
@table @code
--- 10776,10782 ----
@end table
! @node M88K
@subsection M88K
@table @code
*************** BUG monitor, running on a MVME187 (m88k)
*** 10703,10709 ****
@end table
! @node MIPS Embedded, PowerPC, M88K, Embedded Processors
@subsection MIPS Embedded
@cindex MIPS boards
--- 10787,10793 ----
@end table
! @node MIPS Embedded
@subsection MIPS Embedded
@cindex MIPS boards
*************** forever because it has no way of knowing
*** 10847,10853 ****
to run before stopping.
@end table
! @node PowerPC, PA, MIPS Embedded, Embedded Processors
@subsection PowerPC
@table @code
--- 10931,10937 ----
to run before stopping.
@end table
! @node PowerPC
@subsection PowerPC
@table @code
*************** SDS monitor, running on a PowerPC board
*** 10868,10874 ****
@end table
! @node PA, SH, PowerPC, Embedded Processors
@subsection HP PA Embedded
@table @code
--- 10952,10958 ----
@end table
! @node PA
@subsection HP PA Embedded
@table @code
*************** W89K monitor, running on a Winbond HPPA
*** 10883,10889 ****
@end table
! @node SH, Sparclet, PA, Embedded Processors
@subsection Hitachi SH
@table @code
--- 10967,10973 ----
@end table
! @node SH
@subsection Hitachi SH
@table @code
*************** Hitachi SH-3 and SH-3E target systems.
*** 10906,10912 ****
@end table
! @node Sparclet, Sparclite, SH, Embedded Processors
@subsection Tsqware Sparclet
@cindex Sparclet
--- 10990,10996 ----
@end table
! @node Sparclet
@subsection Tsqware Sparclet
@cindex Sparclet
*************** run @value{GDBN}. From your Unix host,
*** 10960,10966 ****
* Sparclet Execution:: Running and debugging
@end menu
! @node Sparclet File, Sparclet Connection, Sparclet, Sparclet
@subsubsection Setting file to debug
The @value{GDBN} command @code{file} lets you choose with program to debug.
--- 11044,11050 ----
* Sparclet Execution:: Running and debugging
@end menu
! @node Sparclet File
@subsubsection Setting file to debug
The @value{GDBN} command @code{file} lets you choose with program to debug.
*************** When this happens, add the appropriate d
*** 10990,10996 ****
the @value{GDBN} commands @code{path} and @code{dir}, and execute the
@code{target} command again.
! @node Sparclet Connection, Sparclet Download, Sparclet File, Sparclet
@subsubsection Connecting to Sparclet
The @value{GDBN} command @code{target} lets you connect to a Sparclet target.
--- 11074,11080 ----
the @value{GDBN} commands @code{path} and @code{dir}, and execute the
@code{target} command again.
! @node Sparclet Connection
@subsubsection Connecting to Sparclet
The @value{GDBN} command @code{target} lets you connect to a Sparclet target.
*************** main () at ../prog.c:3
*** 11009,11015 ****
Connected to ttya.
@end example
! @node Sparclet Download, Sparclet Execution, Sparclet Connection, Sparclet
@subsubsection Sparclet download
@cindex download to Sparclet
--- 11093,11099 ----
Connected to ttya.
@end example
! @node Sparclet Download
@subsubsection Sparclet download
@cindex download to Sparclet
*************** If the code is loaded at a different add
*** 11035,11041 ****
to, you may need to use the @code{section} and @code{add-symbol-file} commands
to tell @value{GDBN} where to map the symbol table.
! @node Sparclet Execution, , Sparclet Download, Sparclet
@subsubsection Running and debugging
@cindex running and debugging Sparclet programs
--- 11119,11125 ----
to, you may need to use the @code{section} and @code{add-symbol-file} commands
to tell @value{GDBN} where to map the symbol table.
! @node Sparclet Execution
@subsubsection Running and debugging
@cindex running and debugging Sparclet programs
*************** Breakpoint 1, main (argc=1, argv=0xeffff
*** 11055,11061 ****
(gdbslet)
@end example
! @node Sparclite, ST2000, Sparclet, Embedded Processors
@subsection Fujitsu Sparclite
@table @code
--- 11139,11145 ----
(gdbslet)
@end example
! @node Sparclite
@subsection Fujitsu Sparclite
@table @code
*************** remote protocol.
*** 11069,11075 ****
@end table
! @node ST2000, Z8000, Sparclite, Embedded Processors
@subsection Tandem ST2000
@value{GDBN} may be used with a Tandem ST2000 phone switch, running Tandem's
--- 11153,11159 ----
@end table
! @node ST2000
@subsection Tandem ST2000
@value{GDBN} may be used with a Tandem ST2000 phone switch, running Tandem's
*************** sequences gets you back to the @value{GD
*** 11118,11124 ****
@kbd{@key{RET}~@key{C-d}} (Return, followed by tilde and control-D).
@end table
! @node Z8000, , ST2000, Embedded Processors
@subsection Zilog Z8000
@cindex Z8000
--- 11202,11208 ----
@kbd{@key{RET}~@key{C-d}} (Return, followed by tilde and control-D).
@end table
! @node Z8000
@subsection Zilog Z8000
@cindex Z8000
*************** conventions; for example, @w{@samp{b fpu
*** 11169,11175 ****
conditional breakpoint that suspends only after at least 5000
simulated clock ticks.
! @node Architectures, , Embedded Processors, Configurations
@section Architectures
This section describes characteristics of architectures that affect
--- 11253,11259 ----
conditional breakpoint that suspends only after at least 5000
simulated clock ticks.
! @node Architectures
@section Architectures
This section describes characteristics of architectures that affect
*************** all uses of @value{GDBN} with the archit
*** 11181,11187 ****
* MIPS::
@end menu
! @node A29K, Alpha, Architectures, Architectures
@subsection A29K
@table @code
--- 11265,11271 ----
* MIPS::
@end menu
! @node A29K
@subsection A29K
@table @code
*************** processors.
*** 11207,11218 ****
@end table
! @node Alpha, MIPS, A29K, Architectures
@subsection Alpha
See the following section.
! @node MIPS, , Alpha, Architectures
@subsection MIPS
@cindex stack on Alpha
--- 11291,11302 ----
@end table
! @node Alpha
@subsection Alpha
See the following section.
! @node MIPS
@subsection MIPS
@cindex stack on Alpha
*************** These commands are available @emph{only}
*** 11247,11253 ****
for debugging programs on Alpha or MIPS processors.
! @node Controlling GDB, Sequences, Configurations, Top
@chapter Controlling @value{GDBN}
You can alter the way @value{GDBN} interacts with you by using the
--- 11331,11337 ----
for debugging programs on Alpha or MIPS processors.
! @node Controlling GDB
@chapter Controlling @value{GDBN}
You can alter the way @value{GDBN} interacts with you by using the
*************** described here.
*** 11265,11271 ****
* Debugging Output:: Optional messages about internal happenings
@end menu
! @node Prompt, Editing, Controlling GDB, Controlling GDB
@section Prompt
@cindex prompt
--- 11349,11355 ----
* Debugging Output:: Optional messages about internal happenings
@end menu
! @node Prompt
@section Prompt
@cindex prompt
*************** Directs @value{GDBN} to use @var{newprom
*** 11291,11297 ****
Prints a line of the form: @samp{Gdb's prompt is: @var{your-prompt}}
@end table
! @node Editing, History, Prompt, Controlling GDB
@section Command editing
@cindex readline
@cindex command line editing
--- 11375,11381 ----
Prints a line of the form: @samp{Gdb's prompt is: @var{your-prompt}}
@end table
! @node Editing
@section Command editing
@cindex readline
@cindex command line editing
*************** Disable command line editing.
*** 11321,11327 ****
Show whether command line editing is enabled.
@end table
! @node History, Screen Size, Editing, Controlling GDB
@section Command history
@value{GDBN} can keep track of the commands you type during your
--- 11405,11411 ----
Show whether command line editing is enabled.
@end table
! @node History
@section Command history
@value{GDBN} can keep track of the commands you type during your
*************** Print ten commands centered on command n
*** 11418,11424 ****
Print ten commands just after the commands last printed.
@end table
! @node Screen Size, Numbers, History, Controlling GDB
@section Screen size
@cindex size of screen
@cindex pauses in output
--- 11502,11508 ----
Print ten commands just after the commands last printed.
@end table
! @node Screen Size
@section Screen size
@cindex size of screen
@cindex pauses in output
*************** Likewise, you can specify @samp{set widt
*** 11460,11466 ****
from wrapping its output.
@end table
! @node Numbers, Messages/Warnings, Screen Size, Controlling GDB
@section Numbers
@cindex number representation
@cindex entering numbers
--- 11544,11550 ----
from wrapping its output.
@end table
! @node Numbers
@section Numbers
@cindex number representation
@cindex entering numbers
*************** Display the current default base for num
*** 11507,11513 ****
Display the current default base for numeric display.
@end table
! @node Messages/Warnings, Debugging Output , Numbers, Controlling GDB
@section Optional warnings and messages
By default, @value{GDBN} is silent about its inner workings. If you are
--- 11591,11597 ----
Display the current default base for numeric display.
@end table
! @node Messages/Warnings
@section Optional warnings and messages
By default, @value{GDBN} is silent about its inner workings. If you are
*************** Displays state of confirmation requests.
*** 11583,11589 ****
@end table
! @node Debugging Output, ,Messages/Warnings, Controlling GDB
@section Optional messages about internal happenings
@table @code
@kindex set debug arch
--- 11667,11673 ----
@end table
! @node Debugging Output
@section Optional messages about internal happenings
@table @code
@kindex set debug arch
*************** Displays the current state of displaying
*** 11654,11660 ****
debugging info.
@end table
! @node Sequences, Emacs, Controlling GDB, Top
@chapter Canned Sequences of Commands
Aside from breakpoint commands (@pxref{Break Commands, ,Breakpoint
--- 11738,11744 ----
debugging info.
@end table
! @node Sequences
@chapter Canned Sequences of Commands
Aside from breakpoint commands (@pxref{Break Commands, ,Breakpoint
*************** files.
*** 11669,11675 ****
* Output:: Commands for controlled output
@end menu
! @node Define, Hooks, Sequences, Sequences
@section User-defined commands
@cindex user-defined command
--- 11753,11759 ----
* Output:: Commands for controlled output
@end menu
! @node Define
@section User-defined commands
@cindex user-defined command
*************** without asking when used inside a user-d
*** 11762,11768 ****
commands that normally print messages to say what they are doing omit the
messages when used in a user-defined command.
! @node Hooks, Command Files, Define, Sequences
@section User-defined command hooks
@cindex command hooks
@cindex hooks, for commands
--- 11846,11852 ----
commands that normally print messages to say what they are doing omit the
messages when used in a user-defined command.
! @node Hooks
@section User-defined command hooks
@cindex command hooks
@cindex hooks, for commands
*************** If an error occurs during the execution
*** 11808,11814 ****
If you try to define a hook which does not match any known command, you
get a warning from the @code{define} command.
! @node Command Files, Output, Hooks, Sequences
@section Command files
@cindex command files
--- 11892,11898 ----
If you try to define a hook which does not match any known command, you
get a warning from the @code{define} command.
! @node Command Files
@section Command files
@cindex command files
*************** without asking when used in a command fi
*** 11871,11877 ****
normally print messages to say what they are doing omit the messages
when called from command files.
! @node Output, , Command Files, Sequences
@section Commands for controlled output
During the execution of a command file or a user-defined command, normal
--- 11955,11961 ----
normally print messages to say what they are doing omit the messages
when called from command files.
! @node Output
@section Commands for controlled output
During the execution of a command file or a user-defined command, normal
*************** string are the simple ones that consist
*** 11951,11957 ****
letter.
@end table
! @node Emacs, Annotations, Sequences, Top
@chapter Using @value{GDBN} under @sc{gnu} Emacs
@cindex Emacs
--- 12035,12041 ----
letter.
@end table
! @node Emacs
@chapter Using @value{GDBN} under @sc{gnu} Emacs
@cindex Emacs
*************** environment. Users of this environment
*** 12125,12135 ****
each value is printed in its own window.
@end ignore
! @node Annotations, GDB Bugs, Emacs, Top
@chapter @value{GDBN} Annotations
@include annotate.texi
! @node GDB Bugs, Command Line Editing, Annotations, Top
@chapter Reporting Bugs in @value{GDBN}
@cindex bugs in @value{GDBN}
@cindex reporting bugs in @value{GDBN}
--- 12209,12219 ----
each value is printed in its own window.
@end ignore
! @node Annotations
@chapter @value{GDBN} Annotations
@include annotate.texi
! @node GDB Bugs
@chapter Reporting Bugs in @value{GDBN}
@cindex bugs in @value{GDBN}
@cindex reporting bugs in @value{GDBN}
*************** information that enables us to fix the b
*** 12149,12155 ****
* Bug Reporting:: How to report bugs
@end menu
! @node Bug Criteria, Bug Reporting, GDB Bugs, GDB Bugs
@section Have you found a bug?
@cindex bug criteria
--- 12233,12239 ----
* Bug Reporting:: How to report bugs
@end menu
! @node Bug Criteria
@section Have you found a bug?
@cindex bug criteria
*************** If you are an experienced user of debugg
*** 12181,12187 ****
for improvement of @value{GDBN} are welcome in any case.
@end itemize
! @node Bug Reporting, , Bug Criteria, GDB Bugs
@section How to report bugs
@cindex bug reports
@cindex @value{GDBN} bugs, reporting
--- 12265,12271 ----
for improvement of @value{GDBN} are welcome in any case.
@end itemize
! @node Bug Reporting
@section How to report bugs
@cindex bug reports
@cindex @value{GDBN} bugs, reporting
*************** things without first using the debugger
*** 12371,12387 ****
@c Use -I with makeinfo to point to the appropriate directory,
@c environment var TEXINPUTS with TeX.
! @node Command Line Editing, Using History Interactively, GDB Bugs, Top
@chapter Command Line Editing
@include rluser.texinfo
! @node Using History Interactively, Formatting Documentation, Command Line Editing, Top
@chapter Using History Interactively
@include inc-hist.texinfo
! @node Formatting Documentation, Installing GDB, Using History Interactively, Top
@appendix Formatting Documentation
@cindex @value{GDBN} reference card
--- 12455,12471 ----
@c Use -I with makeinfo to point to the appropriate directory,
@c environment var TEXINPUTS with TeX.
! @node Command Line Editing
@chapter Command Line Editing
@include rluser.texinfo
! @node Using History Interactively
@chapter Using History Interactively
@include inc-hist.texinfo
! @node Formatting Documentation
@appendix Formatting Documentation
@cindex @value{GDBN} reference card
*************** make gdb.dvi
*** 12467,12473 ****
Then give @file{gdb.dvi} to your @sc{dvi} printing program.
! @node Installing GDB, Index, Formatting Documentation, Top
@appendix Installing @value{GDBN}
@cindex configuring @value{GDBN}
@cindex installation
--- 12551,12557 ----
Then give @file{gdb.dvi} to your @sc{dvi} printing program.
! @node Installing GDB
@appendix Installing @value{GDBN}
@cindex configuring @value{GDBN}
@cindex installation
*************** let @value{GDBN} debug child processes w
*** 12587,12593 ****
* Configure Options:: Summary of options for configure
@end menu
! @node Separate Objdir, Config Names, Installing GDB, Installing GDB
@section Compiling @value{GDBN} in another directory
If you want to run @value{GDBN} versions for several host or target machines,
--- 12671,12677 ----
* Configure Options:: Summary of options for configure
@end menu
! @node Separate Objdir
@section Compiling @value{GDBN} in another directory
If you want to run @value{GDBN} versions for several host or target machines,
*************** directories, you can run @code{make} on
*** 12648,12654 ****
if they are NFS-mounted on each of the hosts); they will not interfere
with each other.
! @node Config Names, Configure Options, Separate Objdir, Installing GDB
@section Specifying names for hosts and targets
The specifications used for hosts and targets in the @code{configure}
--- 12732,12738 ----
if they are NFS-mounted on each of the hosts); they will not interfere
with each other.
! @node Config Names
@section Specifying names for hosts and targets
The specifications used for hosts and targets in the @code{configure}
*************** Invalid configuration `i986v': machine `
*** 12690,12696 ****
@code{config.sub} is also distributed in the @value{GDBN} source
directory (@file{gdb-@value{GDBVN}}, for version @value{GDBVN}).
! @node Configure Options, , Config Names, Installing GDB
@section @code{configure} options
Here is a summary of the @code{configure} options and arguments that
--- 12774,12780 ----
@code{config.sub} is also distributed in the @value{GDBN} source
directory (@file{gdb-@value{GDBVN}}, for version @value{GDBVN}).
! @node Configure Options
@section @code{configure} options
Here is a summary of the @code{configure} options and arguments that
*************** There is no convenient way to generate a
*** 12759,12765 ****
There are many other options available as well, but they are generally
needed for special purposes only.
! @node Index, , Installing GDB, Top
@unnumbered Index
@printindex cp
--- 12843,12849 ----
There are many other options available as well, but they are generally
needed for special purposes only.
! @node Index
@unnumbered Index
@printindex cp
From msnyder@cygnus.com Tue Mar 28 10:32:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Chris Faylor <cgf@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFA] Avoid core dumping on corrupt stabs entry
Date: Tue, 28 Mar 2000 10:32:00 -0000
Message-id: <38E0FAD3.60B7@cygnus.com>
References: <20000327204057.A24783@cygnus.com>
X-SW-Source: 2000-03/msg00649.html
Content-length: 907
Chris Faylor wrote:
>
> Any objections to this patch? It seems to be in the spirit of the rest
> of the file.
Looks good to me. JimB?
> 2000-03-27 Christopher Faylor <cgf@cygnus.com>
>
> * partial-stab.h: Add one more check against corrupted or irregular
> stabs entry.
>
> Index: partial-stab.h
> ===================================================================
> RCS file: /cvs/cvsfiles/devo/gdb/partial-stab.h,v
> retrieving revision 2.68
> diff -u -p -r2.68 partial-stab.h
> --- partial-stab.h 1999/09/14 22:50:39 2.68
> +++ partial-stab.h 2000/03/28 01:37:53
> @@ -393,7 +393,7 @@ switch (CUR_SYMBOL_TYPE)
>
> #ifdef DBXREAD_ONLY
> /* See if this is an end of function stab. */
> - if (CUR_SYMBOL_TYPE == N_FUN && *namestring == '\000')
> + if (pst && CUR_SYMBOL_TYPE == N_FUN && *namestring == '\000')
> {
> unsigned long valu;
>
From msnyder@cygnus.com Tue Mar 28 11:15:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: procfs.c:proc_set_watchpoint bug fix
Date: Tue, 28 Mar 2000 11:15:00 -0000
Message-id: <38E1023A.7A8E@cygnus.com>
References: <200003072114.WAA26143@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-03/msg00650.html
Content-length: 1093
Peter.Schauer wrote:
>
> procfs.c:proc_set_watchpoint currently declares its addr parameter as
> void *, but it is called from procfs_set_watchpoint with a CORE_ADDR addr.
> This causes problems if sizeof(CORE_ADDR) > sizeof(void *), e.g on
> Solaris 2.7 sparc.
Approved and committed.
> 2000-03-07 Peter Schauer <pes@regent.e-technik.tu-muenchen.de>
>
> * procfs.c (proc_set_watchpoint): Declare addr parameter as
> CORE_ADDR, to match call from procfs_set_watchpoint.
>
> *** gdb/procfs.c.orig Wed Mar 1 21:54:05 2000
> --- gdb/procfs.c Sun Mar 5 12:05:33 2000
> ***************
> *** 2580,2586 ****
> int
> proc_set_watchpoint (pi, addr, len, wflags)
> procinfo *pi;
> ! void *addr;
> int len;
> int wflags;
> {
> --- 2580,2586 ----
> int
> proc_set_watchpoint (pi, addr, len, wflags)
> procinfo *pi;
> ! CORE_ADDR addr;
> int len;
> int wflags;
> {
>
> --
> Peter Schauer pes@regent.e-technik.tu-muenchen.de
From msnyder@cygnus.com Tue Mar 28 11:30:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: breakpoint.c: Minor output fixes for hardware watchpoints
Date: Tue, 28 Mar 2000 11:30:00 -0000
Message-id: <38E1067A.119C@cygnus.com>
References: <200003072114.WAA26280@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-03/msg00651.html
Content-length: 5447
Peter.Schauer wrote:
>
> During implementation of hardware watchpoints on Solaris, I noticed the
> following inconsistencies in breakpoint.c output between software and
> hardware breakpoints.
>
> 1) insert_breakpoints and do_enable_breakpoint now use select_and_print_frame
> to reselect frames after frame selection for watchpoint evaluation.
> Up to gdb-4.18 GDB used select_frame to reselect frames.
> I have no idea why this was done (I am unable to find a ChangeLog entry,
> perhaps this was a side effect of the HP merge), and it causes the following
> confusing output from the recurse.exp testcase:
This change did indeed come in with the HP merge, which was so
massive that we did not get justifications for every little
change. I'm going to approve backing this change out. If
the folks at HP really need it, let's get a justification
and a change that doesn't have unpleasant side effects.
Checking in this patch.
> continue
> Continuing.
> #0 recurse (a=10) at /users/pes/gdbnd/devo/gdb/testsuite/gdb.base/recurse.c:15
> 15 if (a == 1)
> Hardware watchpoint 2: b
>
> Old value = 0
> New value = 10
> recurse (a=10) at /users/pes/gdbnd/devo/gdb/testsuite/gdb.base/recurse.c:19
> 19 b *= recurse (a - 1);
> (gdb) PASS: gdb.base/recurse.exp: continue to first instance watchpoint, first time
>
> Note the extra frame output before the watchpoint trigger. This is still
> worse in other cases, where we have even more frame output (see below).
>
> 2) insert_breakpoints tries to reinsert watchpoints even if they are already
> marked for deletion at next stop, causing the following redundant output,
> again from the recurse.exp testcase:
>
> continue
> Continuing.
> #0 recurse (a=5) at /users/pes/gdbnd/devo/gdb/testsuite/gdb.base/recurse.c:20
> 20 return b;
> #0 recurse (a=5) at /users/pes/gdbnd/devo/gdb/testsuite/gdb.base/recurse.c:20
> 20 return b;
> Watchpoint 4 deleted because the program has left the block in
> which its expression is valid.
> #0 0x8048a71 in recurse (a=6) at /users/pes/gdbnd/devo/gdb/testsuite/gdb.base/recurse.c:19
> 19 b *= recurse (a - 1);
> Hardware watchpoint 4 deletedbecause the program has left the block
> in which its expression is valid.
> 0x8048a70 in recurse (a=6) at /users/pes/gdbnd/devo/gdb/testsuite/gdb.base/recurse.c:19
> 19 b *= recurse (a - 1);
> (gdb) PASS: gdb.base/recurse.exp: second instance watchpoint deleted when leaving scope
>
> Here is a patch for both problems:
>
> 2000-03-07 Peter Schauer <pes@regent.e-technik.tu-muenchen.de>
>
> * breakpoint.c (insert_breakpoints, do_enable_breakpoint): Reselect
> the saved frame silently after frame selection for watchpoint
> evaluation.
> (insert_breakpoints): Add missing space in `Hardware watchpoint
> deleted' message. Do not reinsert hardware watchpoint if it is
> already marked for deletion at next stop.
>
> *** gdb/breakpoint.c.orig Thu Feb 24 13:41:33 2000
> --- gdb/breakpoint.c Sat Mar 4 11:42:48 2000
> ***************
> *** 918,923 ****
> --- 918,924 ----
> b->type == bp_read_watchpoint ||
> b->type == bp_access_watchpoint)
> && b->enable == enabled
> + && b->disposition != del_at_next_stop
> && !b->inserted
> && !b->duplicate)
> {
> ***************
> *** 1005,1011 ****
> }
> else
> {
> ! printf_filtered ("Hardware watchpoint %d deleted", b->number);
> printf_filtered ("because the program has left the block \n");
> printf_filtered ("in which its expression is valid.\n");
> if (b->related_breakpoint)
> --- 1006,1012 ----
> }
> else
> {
> ! printf_filtered ("Hardware watchpoint %d deleted ", b->number);
> printf_filtered ("because the program has left the block \n");
> printf_filtered ("in which its expression is valid.\n");
> if (b->related_breakpoint)
> ***************
> *** 1016,1022 ****
> /* Restore the frame and level. */
> if ((saved_frame != selected_frame) ||
> (saved_level != selected_frame_level))
> ! select_and_print_frame (saved_frame, saved_level);
>
> if (val)
> return_val = val; /* remember failure */
> --- 1017,1023 ----
> /* Restore the frame and level. */
> if ((saved_frame != selected_frame) ||
> (saved_level != selected_frame_level))
> ! select_frame (saved_frame, saved_level);
>
> if (val)
> return_val = val; /* remember failure */
> ***************
> *** 7536,7543 ****
> }
>
> if (save_selected_frame_level >= 0)
> ! select_and_print_frame (save_selected_frame,
> ! save_selected_frame_level);
> value_free_to_mark (mark);
> }
> if (modify_breakpoint_hook)
> --- 7558,7564 ----
> }
>
> if (save_selected_frame_level >= 0)
> ! select_frame (save_selected_frame, save_selected_frame_level);
> value_free_to_mark (mark);
> }
> if (modify_breakpoint_hook)
>
> --
> Peter Schauer pes@regent.e-technik.tu-muenchen.de
From shebs@apple.com Tue Mar 28 12:33:00 2000
From: Stan Shebs <shebs@apple.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Eli Zaretskii <eliz@is.elta.co.il>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Fix texinfo problems...
Date: Tue, 28 Mar 2000 12:33:00 -0000
Message-id: <38E1171F.7651C329@apple.com>
References: <38DB1875.4B504618@cygnus.com> <38DBB937.126C95E@apple.com> <38DC6763.563424A2@cygnus.com> <200003260443.XAA26499@mescaline.gnu.org> <38E05161.9707ED26@cygnus.com>
X-SW-Source: 2000-03/msg00652.html
Content-length: 462
Andrew Cagney wrote:
> The attatched converts my botch into your patch.
> I've also dropped a copy of texinfo-3.12 into the snapshots directory.
>
> sorry,
> Andrew
>
> Stan, ok?
I didn't see your message before doing my big commit this morning,
so some of the changes are redundant. I would suggest updating
from cvs over your patched file and seeing what's left over after
the merge - the remainder should be much smaller...
Stan
From msnyder@cygnus.com Tue Mar 28 13:18:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH]: minor Makefile.in tweak
Date: Tue, 28 Mar 2000 13:18:00 -0000
Message-id: <200003282118.NAA29340@cleaver.cygnus.com>
X-SW-Source: 2000-03/msg00653.html
Content-length: 1671
Sun's 'make' on Solaris-x86 seems to work better if this
dependency is made explicitly relative to $(srcdir).
I don't know if that is a bug in VPATH handling, or what...
2000-03-28 Michael Snyder <msnyder@cleaver.cygnus.com>
* Makefile.in: anchor tui-file.h dependency to $srcdir.
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.199
diff -c -r1.199 ChangeLog
*** ChangeLog 2000/03/28 19:29:56 1.199
--- ChangeLog 2000/03/28 21:15:16
***************
*** 1,3 ****
--- 1,7 ----
+ 2000-03-28 Michael Snyder <msnyder@cleaver.cygnus.com>
+
+ * Makefile.in: anchor tui-file.h dependency to $srcdir.
+
2000-03-28 Peter Schauer <pes@regent.e-technik.tu-muenchen.de>
* procfs.c (proc_set_watchpoint): Declare addr parameter as
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.16
diff -c -r1.16 Makefile.in
*** Makefile.in 2000/03/27 06:51:30 1.16
--- Makefile.in 2000/03/28 21:15:17
***************
*** 1492,1498 ****
mac-nat.o: mac-nat.c $(defs_h) gdb_string.h
! main.o: main.c top.h $(defs_h) gdb_string.h $(event_loop_h) tui/tui-file.h
maint.o: maint.c $(defs_h) $(gdbcmd_h) $(gdbtypes_h) $(symtab_h) language.h \
$(expression_h) objfiles.h symfile.h
--- 1492,1498 ----
mac-nat.o: mac-nat.c $(defs_h) gdb_string.h
! main.o: main.c top.h $(defs_h) gdb_string.h $(event_loop_h) $(srcdir)/tui/tui-file.h
maint.o: maint.c $(defs_h) $(gdbcmd_h) $(gdbtypes_h) $(symtab_h) language.h \
$(expression_h) objfiles.h symfile.h
From tromey@cygnus.com Tue Mar 28 13:30:00 2000
From: Tom Tromey <tromey@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: minor Makefile.in tweak
Date: Tue, 28 Mar 2000 13:30:00 -0000
Message-id: <87snxaok7a.fsf@cygnus.com>
References: <200003282118.NAA29340@cleaver.cygnus.com>
X-SW-Source: 2000-03/msg00654.html
Content-length: 637
Michael> Sun's 'make' on Solaris-x86 seems to work better if this
Michael> dependency is made explicitly relative to $(srcdir). I don't
Michael> know if that is a bug in VPATH handling, or what...
FYI, generally speaking vendor makes do not implement VPATH correctly.
For automake we decided to only support this feature with GNU make.
Some makes are almost good enough to use, if you add tweaks of one
sort or another. Sun's make is one of these, but I forget what tweaks
are required.
Anyway, I don't think gdb is required (i.e., per GNU coding standards)
to support VPATH for non-GNU makes. In case you care.
Tom
From ac131313@cygnus.com Tue Mar 28 14:03:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Don't trim addresses in Dwarf debug info
Date: Tue, 28 Mar 2000 14:03:00 -0000
Message-id: <38E12BD6.E6E357A4@cygnus.com>
References: <200003281624.LAA23161@zwingli.cygnus.com>
X-SW-Source: 2000-03/msg00655.html
Content-length: 712
Jim Blandy wrote:
>
> I've committed this:
>
> 2000-03-27 Jim Blandy <jimb@redhat.com>
>
> * dwarf2read.c: Revert Andrew Cagney's change of Dec 15, 1997.
> Don't include "bfd-elf.h".
> (address_significant_size): Delete variable.
> (dwarf2_build_psymtabs_hard): Don't set it, or check for
> consistency between it and the Dwarf 2 compilation unit header
> address size.
> (read_address): Don't mask off bits above
> address_significant_size.
> * Makefile.in (dwarf2read.o): Don't depend on $(elf_bfd_h).
> (elf_bfd_h): Remove variable; it's no longer used.
Jim, have you confirmed this doesn't cause any regressions?
Andrew
From ac131313@cygnus.com Tue Mar 28 14:17:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Jim Kingdon <kingdon@redhat.com>, Stephane Carrez <Stephane.Carrez@worldnet.fr>, gdb-patches@sourceware.cygnus.com
Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
Date: Tue, 28 Mar 2000 14:17:00 -0000
Message-id: <38E12EDA.386F148A@cygnus.com>
References: <38B2F3D3.54CF0AF0@worldnet.fr> <38BB5463.D6E5B75C@cygnus.com> <38C0D9D9.70987863@worldnet.fr> <38C225F3.9E236A55@cygnus.com> <bput8j8vi.fsf@rtl.cygnus.com> <38C737EE.513259B9@cygnus.com> <npk8in2h8y.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-03/msg00656.html
Content-length: 1556
Jim Blandy wrote:
>
> > > The whole address_significant_size code in dwarf2read.c strikes me as
> > > a rather ugly kludge to work around bugs elsewhere in the tool chain.
> > > If someone is supplying a 32 bit pointer to GDB on a 16 bit target,
> > > shouldn't the rest of the tool chain be responsible for making sure
> > > the high bits are zero rather than expecting GDB to mask it off?
> > > Granted there might be complications here, like there are cases on
> > > MIPS where we treat an address as signed rather than unsigned, but I'm
> > > also pretty clear on whether that is actually design or just a bug. I
> > > could be wrong/persuadable, of course, and perhaps someone has a
> > > better idea of all this (in which case I'd suggest commenting
> > > arch_size at bfd/elf-bfd.h and/or expanding comments at
> > > bfd_arch_bits_per_address in bfd/archures.c).
> >
> > FYI, in the MIPS case it is a feature of the hardware. GDB has little
> > choice in the matter.
>
> Can you explain why, in the MIPS case, GCC/GAS/LD are unable to place
> correct information in the upper bits of the Dwarf addresses?
>
> (That sounds like a rhetorical question, but it's not. I'm having a
> hard time imagining why address_significant_bits was the right
> solution.)
From memory, it isn't just the dwarf address. The information comes
from two places:
o the debug info
o the raw symbol table
the former has 64 bit information. The latter (elf32) has only 32 bit
information. 64bits don't fit into a 32 bit table. GDB uses both.
enjoy,
Andrew
From msnyder@cygnus.com Tue Mar 28 14:45:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: infrun.c, breakpoint.c: Kludge for Solaris x86 hardware watchpoint support
Date: Tue, 28 Mar 2000 14:45:00 -0000
Message-id: <38E132C8.454C@cygnus.com>
References: <200003130947.KAA07528@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-03/msg00657.html
Content-length: 3545
Peter.Schauer wrote:
>
> Unfortunately I'd need the following kludge to work around a Solaris x86
> kernel problem with hardware watchpoint support.
> See the comment in the patches for a description of the problem.
OK, committed (although doesn't this sort of defeat the advantage
of a hardware watchpoint?)
BTW, next time could you also include the ChangeLog entry in the diffs?
Thanks,
Michael
> 2000-03-12 Peter Schauer <pes@regent.e-technik.tu-muenchen.de>
>
> breakpoint.c, breakpoint.h (remove_hw_watchpoints): New function.
> infrun.c (resume): Remove hardware watchpoints before stepping
> when CANNOT_STEP_HW_WATCHPOINTS is nonzero.
>
> *** gdb/breakpoint.c.orig Thu Feb 24 13:41:33 2000
> --- gdb/breakpoint.c Sat Mar 4 11:42:48 2000
> ***************
> *** 1080,1085 ****
> --- 1081,1107 ----
> }
>
> int
> + remove_hw_watchpoints ()
> + {
> + register struct breakpoint *b;
> + int val;
> +
> + ALL_BREAKPOINTS (b)
> + {
> + if (b->inserted
> + && (b->type == bp_hardware_watchpoint
> + || b->type == bp_read_watchpoint
> + || b->type == bp_access_watchpoint))
> + {
> + val = remove_breakpoint (b, mark_uninserted);
> + if (val != 0)
> + return val;
> + }
> + }
> + return 0;
> + }
> +
> + int
> reattach_breakpoints (pid)
> int pid;
> {
> *** ./gdb/breakpoint.h.orig Thu Feb 3 05:14:27 2000
> --- ./gdb/breakpoint.h Sat Mar 4 11:42:48 2000
> ***************
> *** 562,567 ****
> --- 562,568 ----
> extern int insert_breakpoints PARAMS ((void));
>
> extern int remove_breakpoints PARAMS ((void));
> + extern int remove_hw_watchpoints PARAMS ((void));
>
> /* This function can be used to physically insert eventpoints from the
> specified traced inferior process, without modifying the breakpoint
> *** gdb/infrun.c.orig Thu Feb 24 13:41:46 2000
> --- gdb/infrun.c Mon Mar 13 09:35:54 2000
> ***************
> *** 296,301 ****
> --- 296,308 ----
> #define HAVE_CONTINUABLE_WATCHPOINT 1
> #endif
>
> + #ifndef CANNOT_STEP_HW_WATCHPOINTS
> + #define CANNOT_STEP_HW_WATCHPOINTS 0
> + #else
> + #undef CANNOT_STEP_HW_WATCHPOINTS
> + #define CANNOT_STEP_HW_WATCHPOINTS 1
> + #endif
> +
> /* Tables of how to react to signals; the user sets them. */
>
> static unsigned char *signal_stop;
> ***************
> *** 796,801 ****
> --- 803,820 ----
> if (step && breakpoints_inserted && breakpoint_here_p (read_pc ()))
> step = 0;
> #endif
> +
> + /* Some targets (e.g. Solaris x86) have a kernel bug when stepping
> + over an instruction that causes a page fault without triggering
> + a hardware watchpoint. The kernel properly notices that it shouldn't
> + stop, because the hardware watchpoint is not triggered, but it forgets
> + the step request and continues the program normally.
> + Work around the problem by removing hardware watchpoints if a step is
> + requested, GDB will check for a hardware watchpoint trigger after the
> + step anyway. */
> + if (CANNOT_STEP_HW_WATCHPOINTS && step && breakpoints_inserted)
> + remove_hw_watchpoints ();
> +
>
> /* Normally, by the time we reach `resume', the breakpoints are either
> removed or inserted, as appropriate. The exception is if we're sitting
>
> --
> Peter Schauer pes@regent.e-technik.tu-muenchen.de
From msnyder@cygnus.com Tue Mar 28 15:27:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Cc: pes@regent.e-technik.tu-muenchen.de
Subject: Re: RFA: infrun.c, breakpoint.c: Kludge for Solaris x86 hardware watchpoint support
Date: Tue, 28 Mar 2000 15:27:00 -0000
Message-id: <38E13FD7.38E@cygnus.com>
References: <200003130947.KAA07528@reisser.regent.e-technik.tu-muenchen.de> <38E132C8.454C@cygnus.com>
X-SW-Source: 2000-03/msg00658.html
Content-length: 215
Michael Snyder wrote:
> BTW, next time could you also include the ChangeLog entry
> in the diffs?
Oops, I stand corrected. I guess omitting the ChangeLog
from the diffs is the policy. Sorry for the confusion.
From ac131313@cygnus.com Tue Mar 28 16:53:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [RFC] maint.c, move assignment to outside of IF expr
Date: Tue, 28 Mar 2000 16:53:00 -0000
Message-id: <38E153C6.C75B057@cygnus.com>
References: <38E04452.2D1EBEC5@cygnus.com>
X-SW-Source: 2000-03/msg00659.html
Content-length: 2628
Andrew Cagney wrote:
>
> OK?
>
> The attatched moves an assignment out of an if conditional. GCC was
> complaining about it.
> I'm guessing that the coder didn't intend to write ``=='' :-)
Oops, the GCC warnings have been quitely breeding in a corner. I've
accumulated/applied the attatched.
Andrew
Wed Mar 29 10:16:35 2000 Andrew Cagney <cagney@b1.cygnus.com>
+
+ * breakpoint.h (remove_hw_watchpoints): Add declaration.
+ * breakpoints.c (remove_hw_watchpoints): Update.
+ * maint.c (maintenance_do_deprecate): Avoid assignment within IF
+ condition.
+
Index: breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.6
diff -p -r1.6 breakpoint.c
*** breakpoint.c 2000/03/28 22:30:19 1.6
--- breakpoint.c 2000/03/29 00:47:47
*************** remove_breakpoints ()
*** 1096,1102 ****
}
int
! remove_hw_watchpoints ()
{
register struct breakpoint *b;
int val;
--- 1096,1102 ----
}
int
! remove_hw_watchpoints (void)
{
register struct breakpoint *b;
int val;
Index: breakpoint.h
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.h,v
retrieving revision 1.1.1.11
diff -p -r1.1.1.11 breakpoint.h
*** breakpoint.h 2000/02/03 04:14:27 1.1.1.11
--- breakpoint.h 2000/03/29 00:47:50
*************** extern struct breakpoint *set_breakpoint
*** 693,696 ****
--- 693,700 ----
deletes all breakpoints. */
extern void delete_command (char *arg, int from_tty);
+ /* Pull all H/W watchpoints from the target. Return non-zero if the
+ remove fails. */
+ extern int remove_hw_watchpoints (void);
+
#endif /* !defined (BREAKPOINT_H) */
Index: maint.c
===================================================================
RCS file: /cvs/src/src/gdb/maint.c,v
retrieving revision 1.6
diff -p -r1.6 maint.c
*** maint.c 2000/03/25 15:32:18 1.6
--- maint.c 2000/03/29 00:47:54
*************** maintenance_do_deprecate (char *text, in
*** 425,434 ****
if (deprecate)
{
/* look for a replacement command */
! if (start_ptr = strchr (text, '\"'))
{
start_ptr++;
! if (end_ptr = strrchr (start_ptr, '\"'))
{
len = end_ptr - start_ptr;
start_ptr[len] = '\0';
--- 425,436 ----
if (deprecate)
{
/* look for a replacement command */
! start_ptr = strchr (text, '\"');
! if (start_ptr != NULL)
{
start_ptr++;
! end_ptr = strrchr (start_ptr, '\"');
! if (end_ptr != NULL)
{
len = end_ptr - start_ptr;
start_ptr[len] = '\0';
From ac131313@cygnus.com Tue Mar 28 17:17:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [RFC] qfThreadExtraInfo -> qThreadExtraInfo
Date: Tue, 28 Mar 2000 17:17:00 -0000
Message-id: <38E15968.BE3BC597@cygnus.com>
X-SW-Source: 2000-03/msg00660.html
Content-length: 1905
This is just part one of the cleanups to the thread code. It brings
this specific query into line with the spec. Given it isn't deployed in
the field the change is ok.
I've other fixes but they aren't as urgent.
Andrew
Index: gdb/ChangeLog
Tue Mar 28 18:28:40 2000 Andrew Cagney <cagney@b1.cygnus.com>
* remote.c (remote_threads_extra_info): Replace qfThreadExtraInfo
with qThreadInfo.
Index: gdb/doc/ChangeLog
Tue Mar 28 18:28:45 2000 Andrew Cagney <cagney@b1.cygnus.com>
* gdb.texinfo (Protocol): Replace ``qfThreadExtraInfo'' with
qThreadInfo.
Index: gdb/remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.6
diff -p -r1.6 remote.c
*** remote.c 2000/03/21 01:22:05 1.6
--- remote.c 2000/03/28 23:57:53
*************** remote_threads_extra_info (struct thread
*** 1654,1660 ****
if (use_threadextra_query)
{
! sprintf (bufp, "qfThreadExtraInfo,%x", tp->pid);
putpkt (bufp);
getpkt (bufp, PBUFSIZ, 0);
if (bufp[0] != 0)
--- 1654,1660 ----
if (use_threadextra_query)
{
! sprintf (bufp, "qThreadExtraInfo,%x", tp->pid);
putpkt (bufp);
getpkt (bufp, PBUFSIZ, 0);
if (bufp[0] != 0)
Index: gdb/doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.9
diff -p -r1.9 gdb.texinfo
*** gdb.texinfo 2000/03/28 16:46:24 1.9
--- gdb.texinfo 2000/03/28 23:58:40
*************** respond to each reply with a request for
*** 9461,9467 ****
(lower-case el, for @code{'last'}).
@item extra thread info
! @tab @code{qfThreadExtraInfo,}@var{<id>}
@tab
@item
@tab
--- 9461,9467 ----
(lower-case el, for @code{'last'}).
@item extra thread info
! @tab @code{q}@code{ThreadExtraInfo}@code{,}@var{id}
@tab
@item
@tab
From ac131313@cygnus.com Tue Mar 28 18:32:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: shebs@apple.com
Cc: Eli Zaretskii <eliz@is.elta.co.il>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Fix texinfo problems...
Date: Tue, 28 Mar 2000 18:32:00 -0000
Message-id: <38E16AB4.F6081625@cygnus.com>
References: <38DB1875.4B504618@cygnus.com> <38DBB937.126C95E@apple.com> <38DC6763.563424A2@cygnus.com> <200003260443.XAA26499@mescaline.gnu.org> <38E05161.9707ED26@cygnus.com> <38E1171F.7651C329@apple.com>
X-SW-Source: 2000-03/msg00661.html
Content-length: 4046
Stan Shebs wrote:
>
> Andrew Cagney wrote:
>
> > The attatched converts my botch into your patch.
> > I've also dropped a copy of texinfo-3.12 into the snapshots directory.
> >
> > sorry,
> > Andrew
> >
> > Stan, ok?
>
> I didn't see your message before doing my big commit this morning,
> so some of the changes are redundant. I would suggest updating
> from cvs over your patched file and seeing what's left over after
> the merge - the remainder should be much smaller...
A patch to revert the remainder is attached.
Andrew
Index: gdb/doc/ChangeLog
Tue Mar 28 16:06:22 2000 Andrew Cagney <cagney@b1.cygnus.com>
* gdb.texinfo: Revert remainder of Fri Mar 24 18:06:34 2000 Andrew
Cagney <cagney@b1.cygnus.com>. Move @chapter and @node entries
back to annotate.texi, rluser.texinfo and inc-hist.texinfo.
* annotate.texi: Update.
Index: readline/doc/ChangeLog
Tue Mar 28 16:06:22 2000 Andrew Cagney <cagney@b1.cygnus.com>
* inc-hist.texinfo, rluser.texinfo: Revert change Fri Mar 24
18:04:32 2000 Andrew Cagney <cagney@b1.cygnus.com>.
Unconditionally provide @chapter and @node.
Index: gdb/doc/annotate.texi
===================================================================
RCS file: /cvs/src/src/gdb/doc/annotate.texi,v
retrieving revision 1.4
diff -p -r1.4 annotate.texi
*** annotate.texi 2000/03/28 16:46:24 1.4
--- annotate.texi 2000/03/29 01:29:17
***************
*** 55,64 ****
@syncodeindex fn cp
- @ifclear GDBN
@node Annotations
@chapter @value{GDBN} Annotations
- @end ifclear
This chapter describes annotations in @value{GDBN}. Annotations are
designed to interface @value{GDBN} to graphical user interfaces or other
--- 55,62 ----
Index: gdb/doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.9
diff -p -r1.9 gdb.texinfo
*** gdb.texinfo 2000/03/28 16:46:24 1.9
--- gdb.texinfo 2000/03/29 01:29:56
*************** environment. Users of this environment
*** 12209,12216 ****
each value is printed in its own window.
@end ignore
- @node Annotations
- @chapter @value{GDBN} Annotations
@include annotate.texi
@node GDB Bugs
--- 12209,12214 ----
*************** things without first using the debugger
*** 12454,12467 ****
@c inc-hist.texinfo
@c Use -I with makeinfo to point to the appropriate directory,
@c environment var TEXINPUTS with TeX.
-
- @node Command Line Editing
- @chapter Command Line Editing
@include rluser.texinfo
-
-
- @node Using History Interactively
- @chapter Using History Interactively
@include inc-hist.texinfo
--- 12452,12458 ----
Index: readline/doc/inc-hist.texinfo
===================================================================
RCS file: /cvs/src/src/readline/doc/inc-hist.texinfo,v
retrieving revision 1.2
diff -p -r1.2 inc-hist.texinfo
*** inc-hist.texinfo 2000/03/24 07:30:07 1.2
--- inc-hist.texinfo 2000/03/29 01:30:01
*************** Permission is granted to copy and distri
*** 23,32 ****
into another language, under the above conditions for modified versions.
@end ignore
- @ifclear GDBN
@node Using History Interactively
@chapter Using History Interactively
- @end ifclear
@ifset BashFeatures
This chapter describes how to use the GNU History Library interactively,
--- 23,30 ----
Index: readline/doc/rluser.texinfo
===================================================================
RCS file: /cvs/src/src/readline/doc/rluser.texinfo,v
retrieving revision 1.2
diff -p -r1.2 rluser.texinfo
*** rluser.texinfo 2000/03/24 07:30:07 1.2
--- rluser.texinfo 2000/03/29 01:30:05
*************** into another language, under the above c
*** 36,45 ****
@comment If you are including this manual as an appendix, then set the
@comment variable readline-appendix.
- @ifclear GDBN
@node Command Line Editing
@chapter Command Line Editing
- @end ifclear
This chapter describes the basic features of the @sc{GNU}
command line editing interface.
--- 36,43 ----
From shebs@apple.com Tue Mar 28 19:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Eli Zaretskii <eliz@is.elta.co.il>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Fix texinfo problems...
Date: Tue, 28 Mar 2000 19:00:00 -0000
Message-id: <38E171AC.AB1B5AD0@apple.com>
References: <38DB1875.4B504618@cygnus.com> <38DBB937.126C95E@apple.com> <38DC6763.563424A2@cygnus.com> <200003260443.XAA26499@mescaline.gnu.org> <38E05161.9707ED26@cygnus.com> <38E1171F.7651C329@apple.com> <38E16AB4.F6081625@cygnus.com>
X-SW-Source: 2000-03/msg00662.html
Content-length: 876
Andrew Cagney wrote:
>
> Stan Shebs wrote:
> >
> > I didn't see your message before doing my big commit this morning,
> > so some of the changes are redundant. I would suggest updating
> > from cvs over your patched file and seeing what's left over after
> > the merge - the remainder should be much smaller...
>
> A patch to revert the remainder is attached.
If you could go ahead and commit these, that would be great. Seeing
them reminds me of why I had to take out the explicit links in the
first place - they didn't play nice with the inserted readline docs,
and would have required changes that couldn't have been accepted
into standard readline. So I slashed through the Gordian knot of
cross-links :-) by taking them all out...
(Clearly my next round of checkins should include a note to future
hackers about why the explicit links are not in there, eh?)
Stan
From ac131313@cygnus.com Tue Mar 28 19:50:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: GDB 5 2000-03-29
Date: Tue, 28 Mar 2000 19:50:00 -0000
Message-id: <38E17D2C.F7EB65B9@cygnus.com>
X-SW-Source: 2000-03/msg00663.html
Content-length: 6421
Below is my updated TODO list for GDB 5. I've also attatched the patch
I'm applying to TODO. You can see the gory details in the sources.
Looking at it. There are four ``must haves'' left.
For the watchpoint patches, if at least some have been addressed, I'd
like to put the rest off.
For Solaris/x86, what shape is it in?
The remainder look like must fix bugs.
Andrew
GDB 5.0: Must have
------------------
These are things that have been identifed as must-have for this
release of GDB.
--
Watch point related patches (Eli Zaretskii, Michael Snyder, ???)
Eli writes: This doesn't include the watchpoint-related patches I sent
beginning with August or September, and mentioned them again three
weeks ago. Here again are the pointers to the relevant messages:
Hardware breakpoints and watchpoints: patches
http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00173.html
Re: Hardware breakpoints and watchpoints: patches
http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00204.html
Re: Hardware breakpoints and watchpoints: patches
http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00200.html
Hardware watchpoints for bitfields
http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00201.html
--
Tom's speedups to GDB (Tom Tromey, Jim Blandy)
I believe that there was a late breaking fix that stopped a coredump.
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00869.html
--
Solaris/x86 - which? (Nick Duffek, Peter Schauer, Michael Snyder?)
Nick D's working through patches from Michael Snyder and Peter S.
--
RFA: procfs.c: init_procfs_ops should set
procfs_ops.to_has_[all]_memory (Peter Schauer, Andrew Cagney?)
I am pretty sure that this is caused by some accidental deletion, but
procfs.c:init_procfs_ops no longer sets procfs_ops.to_has_memory and
procfs_ops.to_has_all_memory.
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg01057.html
Wed Mar 29 13:40:40 2000 Andrew Cagney <cagney@b1.cygnus.com>
* TODO: Update GDB 5 status.
Index: TODO
===================================================================
RCS file: /cvs/src/src/gdb/TODO,v
retrieving revision 1.2
diff -u -r1.2 TODO
--- TODO 2000/03/27 10:24:58 1.2
+++ TODO 2000/03/29 03:43:21
@@ -62,26 +62,18 @@
--
-Texinfo broken/builds (Andrew Cagney, Stan Shebs)
-Cagney probably botched a fix to a botch.
+RFA: procfs.c: init_procfs_ops should set
+procfs_ops.to_has_[all]_memory (Peter Schauer, Andrew Cagney?)
---
+I am pretty sure that this is caused by some accidental deletion, but
+procfs.c:init_procfs_ops no longer sets procfs_ops.to_has_memory and
+procfs_ops.to_has_all_memory.
-x86 linux GDB and SIGALRM
- http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg01057.html
--
-RFA: breakpoint.c: Minor output fixes for hardware watchpoints
- http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00558.html
-
-During implementation of hardware watchpoints on Solaris, I noticed the
-following inconsistencies in breakpoint.c output between software and
-hardware breakpoints.
-
---
-
GDB 5.0: Nice to have
---------------------
@@ -126,6 +118,12 @@
The pascal support patches nave been added to the patch data base. I
[cagney] strongly suspect that they are better suited for 5.1.
+Indent -gnu ?
+ http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00496.html
+
+2 pascal language patches inserted in database
+ http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00521.html
+
--
Programs run under GDB have SIGCHLD masked.
@@ -198,6 +196,39 @@
--
+x86 linux GDB and SIGALRM (???)
+ http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html
+
+--
+
+Migrate qfThreadInfo packet -> qThreadInfo. (Andrew Cagney)
+
+Add support for packet enable/disable commands with these thread
+packets. General cleanup.
+
+[PATCH] Document the ThreadInfo remote protocol queries
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00832.html
+
+[PATCH] "info threads" queries for remote.c
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00831.html
+
+--
+
+MI documentation in GDB user guide. (Andrew Cagney, Elena Zannoni,
+Stan Shebs, anyone else?)
+
+> (Are there plans to make gdbmi.texi be part of the manual as well?)
+
+I'd like to see it go in there sooner rather than later too. Otherwise
+you're introducing discrepancies between the manual and the documentation,
+and everybody is confused - witness the lack of doc for the tracing
+commands still, some two years after they were added...
+
+[PATCH] GDB command-line switches and annotations docs
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00639.html
+
+--
+
GDB 5.0: Won't have
-------------------
@@ -232,6 +263,33 @@
--
+Elimination of make_cleanup_func. (Andrew Cagney)
+
+make_cleanup_func elimination
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00791.html
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00814.html
+
+--
+
+Allow GDB to use installed regex. Think about updating regex to more
+recent version (Andrew Cagney).
+
+Re: A new patch for regex
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00635.html
+
+A patch for gnu-regex
+ http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00568.html
+
+--
+
+ChangeLog.mi vs ChangeLog-mi (Andrew Cagney)
+Needs further debate.
+
+Re: [PATCH] Add change-log variables to more MI files
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00811.html
+
+--
+
GDB 5.0: Test results
---------------------
@@ -329,6 +387,30 @@
General Wish List
=================
+
+--
+
+GDBARCH cleanup (Andrew Cagney)
+
+The non-generated parts of gdbarch.{sh,h,c} should be separated out
+into gdbarch-utils.[hc] (Name ok).
+
+The ``info architecture'' command should be replaced with a fixed
+``set architecture'' (implemented using the command.c enum code).
+
+Document that gdbarch_init_ftype could easily fail because it didn't
+identify an architecture.
+
+--
+
+Check that GDB can handle all BFD architectures (Andrew Cagney)
+
+There should be a test that checks that BFD/GDB are in sync with
+regard to architecture changes. Something like a test that first
+queries GDB for all supported architectures and then feeds each back
+to GDB.. Anyone interested in learning how to write tests? :-)
+
+--
This list is probably not up to date, and opinions vary about the
importance or even desirability of some of the items.
From dan@cgsoftware.com Tue Mar 28 20:00:00 2000
From: dan@cgsoftware.com (Daniel Berlin+list.gdb-patches)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: GDB 5 2000-03-29
Date: Tue, 28 Mar 2000 20:00:00 -0000
Message-id: <em8uqvcz.fsf@dan.resnet.rochester.edu>
References: <38E17D2C.F7EB65B9@cygnus.com>
X-SW-Source: 2000-03/msg00664.html
Content-length: 446
> Below is my updated TODO list for GDB 5. I've also attatched the patch
> I'm applying to TODO. You can see the gory details in the sources.
>
> Looking at it. There are four ``must haves'' left.
>
> For the watchpoint patches, if at least some have been addressed, I'd
> like to put the rest off.
>
> For Solaris/x86, what shape is it in?
>
> The remainder look like must fix bugs.
>
> Andrew
Maybe it's time to cut a branch then?
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2000-04-01 0:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <38D4DCB0.88313CB2@worldnet.fr>
[not found] ` <38D5B6E0.50FF6A5E@cygnus.com>
[not found] ` <38D68C56.856CB00C@worldnet.fr>
2000-04-01 0:00 ` path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2 Andrew Cagney
[not found] ` <38D7E6BC.79543EBA@worldnet.fr>
2000-03-27 12:23 ` Jim Blandy
[not found] ` <38E06721.6D3A08CD@cygnus.com>
[not found] ` <npsnx91szl.fsf@zwingli.cygnus.com>
2000-04-01 0:00 ` Andrew Cagney
[not found] ` <npem8w42bg.fsf@zwingli.cygnus.com>
2000-04-01 0:00 ` Fernando Nasser
2000-04-01 0:00 Stephane Carrez
[not found] ` <38BB5463.D6E5B75C@cygnus.com>
[not found] ` <38C0D9D9.70987863@worldnet.fr>
[not found] ` <38C225F3.9E236A55@cygnus.com>
2000-03-28 8:24 ` Jim Blandy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox