* Re: A revised patch for dlclose
[not found] ` <200003081441.JAA02876@devserv.devel.redhat.com>
@ 2000-03-08 14:35 ` Jim Blandy
0 siblings, 0 replies; 2+ messages in thread
From: Jim Blandy @ 2000-03-08 14:35 UTC (permalink / raw)
To: Jim Kingdon; +Cc: toddpw, hjl, kettenis, gdb-patches, gdb
> > If each DSO was given its own obstack, it would be pretty easy.
>
> This is largely a solved problem (via objfiles).
> [...]
> 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.
Yes, that's right.
I've pretty much come to the same conclusion as JimK --- I think there
are ways to repartition find_solib's responsibilities that will make
this logic a lot simpler.
From jimb@zwingli.cygnus.com Wed Mar 08 14:38:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A revised patch for dlclose
Date: Wed, 08 Mar 2000 14:38:00 -0000
Message-id: <npwvndaxzu.fsf@zwingli.cygnus.com>
References: <20000307120800.A27315@valinux.com> <200003080058.e280wga00453@delius.kettenis.local> <bzosakrpu.fsf@rtl.cygnus.com>
X-SW-Source: 2000-03/msg00165.html
Content-length: 537
> I do agree with HJ about one thing, though, which is that this issue
> is rather important. I'm trying to put my money where my mouth is by
> writing code but I'll have to admit that JimB's message left me a
> little unsure about where to turn.
You mean the vague "I don't understand the logic" comment? I concede
that it's not especially constructive criticism. But it was the
truth. :)
I think I've got some idea of how to fix this, but you know how these
things go --- don't let that stop you from thinking about it yourself.
From kettenis@wins.uva.nl Wed Mar 08 14:38: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: Wed, 08 Mar 2000 14:38:00 -0000
Message-id: <200003082237.e28Mbre06925@delius.kettenis.local>
X-SW-Source: 2000-03/msg00164.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 ac131313@cygnus.com Wed Mar 08 19:32:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [MAINT] Anthony Green - Java Maintainer
Date: Wed, 08 Mar 2000 19:32:00 -0000
Message-id: <38C71B06.94E21103@cygnus.com>
X-SW-Source: 2000-03/msg00166.html
Content-length: 2168
Hello,
I've made Anthony Green the Java maintainer.
enjoy,
Andrew
Thu Mar 9 14:21:07 2000 Andrew Cagney <cagney@b1.cygnus.com>
* MAINTAINERS (Core): Anthony Green is the Java - including
testsuite - maintainer. Reformat testsuite and language support
sections
Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.21
diff -p -r1.21 MAINTAINERS
*** MAINTAINERS 2000/03/05 08:46:56 1.21
--- MAINTAINERS 2000/03/09 03:26:56
*************** maintainers when resolving more generic
*** 56,62 ****
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
MS Windows (N.T., CE, '00) host & native
--- 56,61 ----
*************** tracing Michael Snyder msnyder@cygnus
*** 90,96 ****
threads Michael Snyder msnyder@cygnus.com
breakpoint.c Michael Snyder msnyder@cygnus.com
language support David Taylor taylor@cygnus.com
! C++ language support Daniel Berlin dan@cgsoftware.com
expression eval David Taylor taylor@cygnus.com
defs.h David Taylor taylor@cygnus.com
utils.c David Taylor taylor@cygnus.com
--- 89,96 ----
threads Michael Snyder msnyder@cygnus.com
breakpoint.c Michael Snyder msnyder@cygnus.com
language support David Taylor taylor@cygnus.com
! C++ support Daniel Berlin dan@cgsoftware.com
! Java support Anthony Green green@cygnus.com
expression eval David Taylor taylor@cygnus.com
defs.h David Taylor taylor@cygnus.com
utils.c David Taylor taylor@cygnus.com
*************** rdi/adp protocol Fernando Nasser fnasse
*** 108,113 ****
--- 108,115 ----
gdbserver Stan Shebs shebs@apple.com
documentation Stan Shebs shebs@apple.com
testsuite Stan Shebs shebs@apple.com
+ hp tests (gdb.hp) *Jimmy Guo adl-debugger-wdb-merge-guru@cup.hp.com
+ Java tests (gdb.java) Anthony Green green@cygnus.com
Kernel Object Display Fernando Nasser fnasser@cygnus.com
From ac131313@cygnus.com Wed Mar 08 21:11:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com, Elena Zannoni <ezannoni@cygnus.com>
Subject: Re: [Withdrawn] Re: RFA: Patch to blockframe.c, frame.h, arm-tdep.c and fr30-tdep.c (prologue cache)
Date: Wed, 08 Mar 2000 21:11:00 -0000
Message-id: <38C73268.9396081A@cygnus.com>
References: <38ACA4D6.993AFF74@cygnus.com> <38C3E596.F2D24DF6@cygnus.com>
X-SW-Source: 2000-03/msg00167.html
Content-length: 288
Fernando Nasser wrote:
>
> This patch is withdrawn.
>
> (Andrew, is this the right way of doing it (withdrawing a patch)?
There is no right wrong or in-different way :-)
Personally I'll reply to my original posting with the message withdrawn.
It really isn't that important.
Andrew
From ac131313@cygnus.com Wed Mar 08 21:36:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: 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: Wed, 08 Mar 2000 21:36:00 -0000
Message-id: <38C737EE.513259B9@cygnus.com>
References: <38B2F3D3.54CF0AF0@worldnet.fr> <38BB5463.D6E5B75C@cygnus.com> <38C0D9D9.70987863@worldnet.fr> <38C225F3.9E236A55@cygnus.com> <bput8j8vi.fsf@rtl.cygnus.com>
X-SW-Source: 2000-03/msg00168.html
Content-length: 1496
Jim Kingdon wrote:
>
> > 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.
I'm not sure that there is a GDB bug - GDB appears to have been given
wrong information.
> > Is there any reason why s->arch_size isn't 16 in your case?
> 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.
enjoy,
Andrew
From ac131313@cygnus.com Wed Mar 08 21:45:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Stephane Carrez <Stephane.Carrez@worldnet.fr>
Cc: Jim Kingdon <kingdon@redhat.com>, 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: Wed, 08 Mar 2000 21:45:00 -0000
Message-id: <38C73A0C.CE903D0@cygnus.com>
References: <38B2F3D3.54CF0AF0@worldnet.fr> <38BB5463.D6E5B75C@cygnus.com> <38C0D9D9.70987863@worldnet.fr> <38C225F3.9E236A55@cygnus.com> <bput8j8vi.fsf@rtl.cygnus.com> <38C41970.C9433BAD@worldnet.fr>
X-SW-Source: 2000-03/msg00169.html
Content-length: 626
Stephane Carrez wrote:
>
> > > Is there any reason why s->arch_size isn't 16 in your case?
> >
>
> Because I thought it was related to the ELF format (32/64). I also looked
> at the bfd/cpu-d10v.c that uses ELF32 and 16-bit addresses. It also looked
> to me that this was quite coherent: define the ELF format in 'elf_size_info'
> and define the CPU addresses in 'bfd_arch_info'.
FYI, the d10v isn't that simple and very unique. While the hardware PC
appears to be 16 bits it's actually 18 plus implied segment information
(the bottom two bits are zero). It was all mapped onto a 32 bit address
for convenience.
Andrew
From ac131313@cygnus.com Wed Mar 08 21:52:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: Prologue cache fix
Date: Wed, 08 Mar 2000 21:52:00 -0000
Message-id: <38C73B9C.F1299241@cygnus.com>
References: <38B4073E.281C4CE0@redhat.com> <38BB65F6.44D991A2@cygnus.com> <38C412AC.952A1FA4@cygnus.com>
X-SW-Source: 2000-03/msg00170.html
Content-length: 278
Fernando Nasser wrote:
> Seems more logical.
>
> I vote to eliminate the prologue cache (as it seems that it has at least two serious bugs) and cope with the performance
> penalty until a valid optimization is found.
>
> What do you think?
Given it is broken, yes.
Andrew
From Peter.Schauer@regent.e-technik.tu-muenchen.de Thu Mar 09 01:40:00 2000
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: kingdon@redhat.com (Jim Kingdon)
Cc: kevinb@cygnus.com, Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, gdb-patches@sourceware.cygnus.com
Subject: RFA: solib.c: Clean fix to get rid of severe Solaris 2.7 sparc regressions
Date: Thu, 09 Mar 2000 01:40:00 -0000
Message-id: <200003090940.KAA32291@reisser.regent.e-technik.tu-muenchen.de>
References: <200003080336.WAA00424@devserv.devel.redhat.com>
X-SW-Source: 2000-03/msg00171.html
Content-length: 18710
> > I think there must be a better solution than the one that Peter
> > proposes. However, I don't know what it is either.
>
> Something like "extract_address (&lm->field, sizeof (lm->field))" I
> think. I didn't suggest that at first because I thought it would
> require massive solib.c changes to use separate internal and external
> structures like in BFD. But I guess that isn't true, I guess you can
> just change the cast to a call to extract_address.
Good idea, thanks. Here is a revised patch which gets rid of all
CORE_ADDR pointer casts in solib.c.
Once again the rationale for the patch:
This change:
2000-02-25 Alexandre Oliva <oliva@lsd.ic.unicamp.br>
* config.bfd: Enable 64 bit support for GNU/Linux/sparc.
* config.bfd: Enable 64 bit support for Solaris7+/sparc.
causes a severe regression in corefile.exp on Solaris 2.7 sparc, which
should definitely be fixed before the 5.0 release.
Due to the BFD change, a CORE_ADDR is now an unsigned long long with 64 Bits.
When casting 32 bit pointers to a CORE_ADDR in solib.c, the sign bit of the
pointer gets extended, resulting in a very large adress. This is not a
problem when accessing the inferior via procfs (because the address gets
truncated back to 32 bits in the procfs interface), but it causes failures
when trying to retrieve the shared library info from corefile BFDs.
2000-03-09 Peter Schauer <pes@regent.e-technik.tu-muenchen.de>
* solib.c (SOLIB_EXTRACT_ADDRESS): New macro to extract addresses
from solib structures. Use it throughout solib.c, get rid of all
CORE_ADDR casts.
(struct so_list): Change type of lmaddr to CORE_ADDR.
(first_link_map_member): Change return value type to CORE_ADDR,
update callers.
(solib_add_common_symbols): Change parameter type to CORE_ADDR,
update callers.
(open_symbol_file_object, find_solib): Change type of lm variable
to CORE_ADDR.
*** gdb/solib.c.orig Wed Nov 17 03:30:28 1999
--- gdb/solib.c Wed Mar 8 14:06:40 2000
***************
*** 109,121 ****
/* local data declarations */
#ifndef SVR4_SHARED_LIBS
! #define LM_ADDR(so) ((so) -> lm.lm_addr)
! #define LM_NEXT(so) ((so) -> lm.lm_next)
! #define LM_NAME(so) ((so) -> lm.lm_name)
/* Test for first link map entry; first entry is a shared library. */
! #define IGNORE_FIRST_LINK_MAP_ENTRY(x) (0)
static struct link_dynamic dynamic_copy;
static struct link_dynamic_2 ld_2_copy;
static struct ld_debug debug_copy;
--- 109,130 ----
/* local data declarations */
+ /* Macro to extract an address from a solib structure.
+ When GDB is configured for some 32-bit targets (e.g. Solaris 2.7
+ sparc), BFD is configured to handle 64-bit targets, so CORE_ADDR is
+ 64 bits. We have to extract only the significant bits of addresses
+ to get the right address when accessing the core file BFD. */
+
+ #define SOLIB_EXTRACT_ADDRESS(member) \
+ extract_address (&member, sizeof (member))
+
#ifndef SVR4_SHARED_LIBS
! #define LM_ADDR(so) (SOLIB_EXTRACT_ADDRESS ((so) -> lm.lm_addr))
! #define LM_NEXT(so) (SOLIB_EXTRACT_ADDRESS ((so) -> lm.lm_next))
! #define LM_NAME(so) (SOLIB_EXTRACT_ADDRESS ((so) -> lm.lm_name))
/* Test for first link map entry; first entry is a shared library. */
! #define IGNORE_FIRST_LINK_MAP_ENTRY(so) (0)
static struct link_dynamic dynamic_copy;
static struct link_dynamic_2 ld_2_copy;
static struct ld_debug debug_copy;
***************
*** 124,134 ****
#else /* SVR4_SHARED_LIBS */
! #define LM_ADDR(so) ((so) -> lm.l_addr)
! #define LM_NEXT(so) ((so) -> lm.l_next)
! #define LM_NAME(so) ((so) -> lm.l_name)
/* Test for first link map entry; first entry is the exec-file. */
! #define IGNORE_FIRST_LINK_MAP_ENTRY(x) ((x).l_prev == NULL)
static struct r_debug debug_copy;
char shadow_contents[BREAKPOINT_MAX]; /* Stash old bkpt addr contents */
--- 133,144 ----
#else /* SVR4_SHARED_LIBS */
! #define LM_ADDR(so) (SOLIB_EXTRACT_ADDRESS ((so) -> lm.l_addr))
! #define LM_NEXT(so) (SOLIB_EXTRACT_ADDRESS ((so) -> lm.l_next))
! #define LM_NAME(so) (SOLIB_EXTRACT_ADDRESS ((so) -> lm.l_name))
/* Test for first link map entry; first entry is the exec-file. */
! #define IGNORE_FIRST_LINK_MAP_ENTRY(so) \
! (SOLIB_EXTRACT_ADDRESS ((so) -> lm.l_prev) == 0)
static struct r_debug debug_copy;
char shadow_contents[BREAKPOINT_MAX]; /* Stash old bkpt addr contents */
***************
*** 138,144 ****
{
struct so_list *next; /* next structure in linked list */
struct link_map lm; /* copy of link map from inferior */
! struct link_map *lmaddr; /* addr in inferior lm was read from */
CORE_ADDR lmend; /* upper addr bound of mapped object */
char so_name[MAX_PATH_SIZE]; /* shared object lib name (FIXME) */
char symbols_loaded; /* flag: symbols read in yet? */
--- 148,154 ----
{
struct so_list *next; /* next structure in linked list */
struct link_map lm; /* copy of link map from inferior */
! CORE_ADDR lmaddr; /* addr in inferior lm was read from */
CORE_ADDR lmend; /* upper addr bound of mapped object */
char so_name[MAX_PATH_SIZE]; /* shared object lib name (FIXME) */
char symbols_loaded; /* flag: symbols read in yet? */
***************
*** 184,190 ****
static struct so_list *
find_solib PARAMS ((struct so_list *));
! static struct link_map *
first_link_map_member PARAMS ((void));
static CORE_ADDR
--- 194,200 ----
static struct so_list *
find_solib PARAMS ((struct so_list *));
! static CORE_ADDR
first_link_map_member PARAMS ((void));
static CORE_ADDR
***************
*** 206,212 ****
allocate_rt_common_objfile PARAMS ((void));
static void
! solib_add_common_symbols PARAMS ((struct rtc_symb *));
#endif
--- 216,222 ----
allocate_rt_common_objfile PARAMS ((void));
static void
! solib_add_common_symbols PARAMS ((CORE_ADDR));
#endif
***************
*** 338,346 ****
/* Relocate the section binding addresses as recorded in the shared
object's file by the base address to which the object was actually
mapped. */
! p->addr += (CORE_ADDR) LM_ADDR (so);
! p->endaddr += (CORE_ADDR) LM_ADDR (so);
! so->lmend = (CORE_ADDR) max (p->endaddr, so->lmend);
if (STREQ (p->the_bfd_section->name, ".text"))
{
so->textsection = p;
--- 348,356 ----
/* Relocate the section binding addresses as recorded in the shared
object's file by the base address to which the object was actually
mapped. */
! p->addr += LM_ADDR (so);
! p->endaddr += LM_ADDR (so);
! so->lmend = max (p->endaddr, so->lmend);
if (STREQ (p->the_bfd_section->name, ".text"))
{
so->textsection = p;
***************
*** 398,404 ****
static void
solib_add_common_symbols (rtc_symp)
! struct rtc_symb *rtc_symp;
{
struct rtc_symb inferior_rtc_symb;
struct nlist inferior_rtc_nlist;
--- 408,414 ----
static void
solib_add_common_symbols (rtc_symp)
! CORE_ADDR rtc_symp;
{
struct rtc_symb inferior_rtc_symb;
struct nlist inferior_rtc_nlist;
***************
*** 421,430 ****
while (rtc_symp)
{
! read_memory ((CORE_ADDR) rtc_symp,
(char *) &inferior_rtc_symb,
sizeof (inferior_rtc_symb));
! read_memory ((CORE_ADDR) inferior_rtc_symb.rtc_sp,
(char *) &inferior_rtc_nlist,
sizeof (inferior_rtc_nlist));
if (inferior_rtc_nlist.n_type == N_COMM)
--- 431,440 ----
while (rtc_symp)
{
! read_memory (rtc_symp,
(char *) &inferior_rtc_symb,
sizeof (inferior_rtc_symb));
! read_memory (SOLIB_EXTRACT_ADDRESS (inferior_rtc_symb.rtc_sp),
(char *) &inferior_rtc_nlist,
sizeof (inferior_rtc_nlist));
if (inferior_rtc_nlist.n_type == N_COMM)
***************
*** 435,441 ****
len = inferior_rtc_nlist.n_value - inferior_rtc_nlist.n_un.n_strx;
name = xmalloc (len);
! read_memory ((CORE_ADDR) inferior_rtc_nlist.n_un.n_name, name, len);
/* Allocate the runtime common objfile if necessary. */
if (rt_common_objfile == NULL)
--- 445,452 ----
len = inferior_rtc_nlist.n_value - inferior_rtc_nlist.n_un.n_strx;
name = xmalloc (len);
! read_memory (SOLIB_EXTRACT_ADDRESS (inferior_rtc_nlist.n_un.n_name),
! name, len);
/* Allocate the runtime common objfile if necessary. */
if (rt_common_objfile == NULL)
***************
*** 445,451 ****
mst_bss, rt_common_objfile);
free (name);
}
! rtc_symp = inferior_rtc_symb.rtc_next;
}
/* Install any minimal symbols that have been collected as the current
--- 456,462 ----
mst_bss, rt_common_objfile);
free (name);
}
! rtc_symp = SOLIB_EXTRACT_ADDRESS (inferior_rtc_symb.rtc_next);
}
/* Install any minimal symbols that have been collected as the current
***************
*** 857,866 ****
a pointer to the copy in our address space.
*/
! static struct link_map *
first_link_map_member ()
{
! struct link_map *lm = NULL;
#ifndef SVR4_SHARED_LIBS
--- 868,877 ----
a pointer to the copy in our address space.
*/
! static CORE_ADDR
first_link_map_member ()
{
! CORE_ADDR lm = 0;
#ifndef SVR4_SHARED_LIBS
***************
*** 869,877 ****
{
/* It is a version that we can deal with, so read in the secondary
structure and find the address of the link map list from it. */
! read_memory ((CORE_ADDR) dynamic_copy.ld_un.ld_2, (char *) &ld_2_copy,
sizeof (struct link_dynamic_2));
! lm = ld_2_copy.ld_loaded;
}
#else /* SVR4_SHARED_LIBS */
--- 880,889 ----
{
/* It is a version that we can deal with, so read in the secondary
structure and find the address of the link map list from it. */
! read_memory (SOLIB_EXTRACT_ADDRESS (dynamic_copy.ld_un.ld_2),
! (char *) &ld_2_copy,
sizeof (struct link_dynamic_2));
! lm = SOLIB_EXTRACT_ADDRESS (ld_2_copy.ld_loaded);
}
#else /* SVR4_SHARED_LIBS */
***************
*** 880,886 ****
/* FIXME: Perhaps we should validate the info somehow, perhaps by
checking r_version for a known version number, or r_state for
RT_CONSISTENT. */
! lm = debug_copy.r_map;
#endif /* !SVR4_SHARED_LIBS */
--- 892,898 ----
/* FIXME: Perhaps we should validate the info somehow, perhaps by
checking r_version for a known version number, or r_state for
RT_CONSISTENT. */
! lm = SOLIB_EXTRACT_ADDRESS (debug_copy.r_map);
#endif /* !SVR4_SHARED_LIBS */
***************
*** 912,918 ****
PTR arg;
{
int from_tty = (int) arg; /* sneak past catch_errors */
! struct link_map *lm, lmcopy;
char *filename;
int errcode;
--- 924,931 ----
PTR arg;
{
int from_tty = (int) arg; /* sneak past catch_errors */
! CORE_ADDR lm;
! struct link_map lmcopy;
char *filename;
int errcode;
***************
*** 924,940 ****
return 0; /* failed somehow... */
/* First link map member should be the executable. */
! if ((lm = first_link_map_member ()) == NULL)
return 0; /* failed somehow... */
/* Read from target memory to GDB. */
! read_memory ((CORE_ADDR) lm, (void *) &lmcopy, sizeof (lmcopy));
if (lmcopy.l_name == 0)
return 0; /* no filename. */
/* Now fetch the filename from target memory. */
! target_read_string ((CORE_ADDR) lmcopy.l_name, &filename,
MAX_PATH_SIZE - 1, &errcode);
if (errcode)
{
--- 937,953 ----
return 0; /* failed somehow... */
/* First link map member should be the executable. */
! if ((lm = first_link_map_member ()) == 0)
return 0; /* failed somehow... */
/* Read from target memory to GDB. */
! read_memory (lm, (void *) &lmcopy, sizeof (lmcopy));
if (lmcopy.l_name == 0)
return 0; /* no filename. */
/* Now fetch the filename from target memory. */
! target_read_string (SOLIB_EXTRACT_ADDRESS (lmcopy.l_name), &filename,
MAX_PATH_SIZE - 1, &errcode);
if (errcode)
{
***************
*** 979,985 ****
struct so_list *so_list_ptr; /* Last lm or NULL for first one */
{
struct so_list *so_list_next = NULL;
! struct link_map *lm = NULL;
struct so_list *new;
if (so_list_ptr == NULL)
--- 992,998 ----
struct so_list *so_list_ptr; /* Last lm or NULL for first one */
{
struct so_list *so_list_next = NULL;
! CORE_ADDR lm = 0;
struct so_list *new;
if (so_list_ptr == NULL)
***************
*** 1002,1012 ****
{
/* We have been called before, and are in the process of walking
the shared library list. Advance to the next shared object. */
! if ((lm = LM_NEXT (so_list_ptr)) == NULL)
{
/* We have hit the end of the list, so check to see if any were
added, but be quiet if we can't read from the target any more. */
! int status = target_read_memory ((CORE_ADDR) so_list_ptr->lmaddr,
(char *) &(so_list_ptr->lm),
sizeof (struct link_map));
if (status == 0)
--- 1015,1025 ----
{
/* We have been called before, and are in the process of walking
the shared library list. Advance to the next shared object. */
! if ((lm = LM_NEXT (so_list_ptr)) == 0)
{
/* We have hit the end of the list, so check to see if any were
added, but be quiet if we can't read from the target any more. */
! int status = target_read_memory (so_list_ptr->lmaddr,
(char *) &(so_list_ptr->lm),
sizeof (struct link_map));
if (status == 0)
***************
*** 1015,1026 ****
}
else
{
! lm = NULL;
}
}
so_list_next = so_list_ptr->next;
}
! if ((so_list_next == NULL) && (lm != NULL))
{
/* Get next link map structure from inferior image and build a local
abbreviated load_map structure */
--- 1028,1039 ----
}
else
{
! lm = 0;
}
}
so_list_next = so_list_ptr->next;
}
! if ((so_list_next == NULL) && (lm != 0))
{
/* Get next link map structure from inferior image and build a local
abbreviated load_map structure */
***************
*** 1045,1063 ****
}
so_list_next = new;
! read_memory ((CORE_ADDR) lm, (char *) &(new->lm),
! sizeof (struct link_map));
/* For SVR4 versions, the first entry in the link map is for the
inferior executable, so we must ignore it. For some versions of
SVR4, it has no name. For others (Solaris 2.3 for example), it
does have a name, so we can no longer use a missing name to
decide when to ignore it. */
! if (!IGNORE_FIRST_LINK_MAP_ENTRY (new->lm))
{
int errcode;
char *buffer;
! target_read_string ((CORE_ADDR) LM_NAME (new), &buffer,
! MAX_PATH_SIZE - 1, &errcode);
if (errcode != 0)
{
warning ("find_solib: Can't read pathname for load map: %s\n",
--- 1058,1075 ----
}
so_list_next = new;
! read_memory (lm, (char *) &(new->lm), sizeof (struct link_map));
/* For SVR4 versions, the first entry in the link map is for the
inferior executable, so we must ignore it. For some versions of
SVR4, it has no name. For others (Solaris 2.3 for example), it
does have a name, so we can no longer use a missing name to
decide when to ignore it. */
! if (!IGNORE_FIRST_LINK_MAP_ENTRY (new))
{
int errcode;
char *buffer;
! target_read_string (LM_NAME (new),
! &buffer, MAX_PATH_SIZE - 1, &errcode);
if (errcode != 0)
{
warning ("find_solib: Can't read pathname for load map: %s\n",
***************
*** 1101,1107 ****
(PTR) &lowest_sect);
if (lowest_sect)
text_addr = bfd_section_vma (so->abfd, lowest_sect)
! + (CORE_ADDR) LM_ADDR (so);
}
ALL_OBJFILES (so->objfile)
--- 1113,1119 ----
(PTR) &lowest_sect);
if (lowest_sect)
text_addr = bfd_section_vma (so->abfd, lowest_sect)
! + LM_ADDR (so);
}
ALL_OBJFILES (so->objfile)
***************
*** 1351,1358 ****
{
if (so->so_name[0])
{
! if ((address >= (CORE_ADDR) LM_ADDR (so)) &&
! (address < (CORE_ADDR) so->lmend))
return (so->so_name);
}
}
--- 1363,1369 ----
{
if (so->so_name[0])
{
! if ((address >= LM_ADDR (so)) && (address < so->lmend))
return (so->so_name);
}
}
***************
*** 1484,1490 ****
write_memory (flag_addr, (char *) &in_debugger, sizeof (in_debugger));
! breakpoint_addr = (CORE_ADDR) debug_copy.ldd_bp_addr;
write_memory (breakpoint_addr, (char *) &debug_copy.ldd_bp_inst,
sizeof (debug_copy.ldd_bp_inst));
--- 1495,1501 ----
write_memory (flag_addr, (char *) &in_debugger, sizeof (in_debugger));
! breakpoint_addr = SOLIB_EXTRACT_ADDRESS (debug_copy.ldd_bp_addr);
write_memory (breakpoint_addr, (char *) &debug_copy.ldd_bp_inst,
sizeof (debug_copy.ldd_bp_inst));
***************
*** 1579,1585 ****
/* Calc address of debugger interface structure */
! debug_addr = (CORE_ADDR) dynamic_copy.ldd;
/* Calc address of `in_debugger' member of debugger interface structure */
--- 1590,1596 ----
/* Calc address of debugger interface structure */
! debug_addr = SOLIB_EXTRACT_ADDRESS (dynamic_copy.ldd);
/* Calc address of `in_debugger' member of debugger interface structure */
***************
*** 1881,1887 ****
/* FIXME, this needs work for cross-debugging of core files
(byteorder, size, alignment, etc). */
! debug_addr = (CORE_ADDR) dynamic_copy.ldd;
}
/* Read the debugger structure from the inferior, just to make sure
--- 1892,1898 ----
/* FIXME, this needs work for cross-debugging of core files
(byteorder, size, alignment, etc). */
! debug_addr = SOLIB_EXTRACT_ADDRESS (dynamic_copy.ldd);
}
/* Read the debugger structure from the inferior, just to make sure
***************
*** 1896,1902 ****
if (debug_copy.ldd_cp)
{
! solib_add_common_symbols (debug_copy.ldd_cp);
}
#endif /* !SVR4_SHARED_LIBS */
--- 1907,1913 ----
if (debug_copy.ldd_cp)
{
! solib_add_common_symbols (SOLIB_EXTRACT_ADDRESS (debug_copy.ldd_cp));
}
#endif /* !SVR4_SHARED_LIBS */
--
Peter Schauer pes@regent.e-technik.tu-muenchen.de
From Peter.Schauer@regent.e-technik.tu-muenchen.de Thu Mar 09 02:21:00 2000
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: gdb-patches@sourceware.cygnus.com
Subject: Withdrawn: Severe regression in corefile.exp with Solaris 2.7 sparc + hack
Date: Thu, 09 Mar 2000 02:21:00 -0000
Message-id: <200003091021.LAA32403@reisser.regent.e-technik.tu-muenchen.de>
References: <200003072113.WAA26253@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-03/msg00172.html
Content-length: 167
This hack is superseded by a clean patch in
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00610.html
--
Peter Schauer pes@regent.e-technik.tu-muenchen.de
From eliz@delorie.com Thu Mar 09 04:10:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: hjl@lucon.org
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Thu, 09 Mar 2000 04:10:00 -0000
Message-id: <200003091210.HAA19857@indy.delorie.com>
References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org>
X-SW-Source: 2000-03/msg00173.html
Content-length: 7737
Okay, to put my money where my mouth is, I'm posting patches to
correct two problems related to hardware breakpoints and watchpoints.
These were all found in the DJGPP (a.k.a. go32) version of GDB, but I
firmly believe that they can be seen on any x86 platform, at least in
native debugging, and possibly on other platforms as well.
Each one of the two messages, this and the next, handles a specific
problem.
Problem no.1: GDB cannot watch bit fields with hardware watchpoints.
Example:
$ cat bf.c
int main (int argc, char *argv[])
{
struct foo {
int iv;
double dv;
unsigned flag1:1;
unsigned flag2:2;
int jv;
} foo_var, *foo_ptr;
foo_var.flag1 = 1;
foo_var.flag2 = foo_var.flag1 + 1;
return 0;
}
$ gcc -g -o bf bf.c
$ gdb bf
(gdb) b main
Breakpoint 1 at 0x1573: file bf.c, line 11.
(gdb) r
Starting program: g:/gdbsnap/gdb-0222/gdb/bf
Breakpoint 1, main (argc=1, argv=0x8c6fc) at bf.c:11
11 foo_var.flag1 = 1;
(gdb) watch foo_var.flag1
Watchpoint 2: foo_var.flag1
Here are the patches, after which you can set hardware watchpoints on
bit fields. You will notice that these patches also augment the
lazy-value trick suggested by Jim Blandy as a means to watch struct
members; this is because that trick doesn't work for bit fields, and
because I regard it generally fragile as far as watchpoints are
considered (we depend on the assumption that GDB doesn't evaluate
parent structures, but nothing in GDB's code suggests that this
assumption will hold).
2000-03-08 Eli Zaretskii <eliz@is.elta.co.il>
* breakpoint.c (insert_breakpoints, remove_breakpoint)
(bpstat_stop_status, can_use_hardware_watchpoint): Don't insert,
remove, or check status of hardware watchpoints for entire structs
and arrays unless the user explicitly asked to watch that struct
or array.
(insert_breakpoints): Try to insert watchpoints for all the values
on the value chain, even if some of them fail to insert.
* values.c (value_primitive_field): Set the offset in struct value
we return when the field is a packed bitfield.
--- gdb/breakpoint.c~1 Wed Mar 8 18:16:00 2000
+++ gdb/breakpoint.c Wed Mar 8 19:20:28 2000
@@ -974,24 +974,39 @@ insert_breakpoints ()
if (VALUE_LVAL (v) == lval_memory
&& ! VALUE_LAZY (v))
{
- CORE_ADDR addr;
- int len, type;
+ struct type *vtype = check_typedef (VALUE_TYPE (v));
- addr = VALUE_ADDRESS (v) + VALUE_OFFSET (v);
- len = TYPE_LENGTH (VALUE_TYPE (v));
- type = hw_write;
- if (b->type == bp_read_watchpoint)
- type = hw_read;
- else if (b->type == bp_access_watchpoint)
- type = hw_access;
-
- val = target_insert_watchpoint (addr, len, type);
- if (val == -1)
+ /* We only watch structs and arrays if user asked
+ for it explicitly, never if they just happen to
+ appear in the middle of some value chain. */
+ if (v == b->val_chain
+ || (TYPE_CODE (vtype) != TYPE_CODE_STRUCT
+ && TYPE_CODE (vtype) != TYPE_CODE_ARRAY))
{
- b->inserted = 0;
- break;
+ CORE_ADDR addr;
+ int len, type;
+
+ addr = VALUE_ADDRESS (v) + VALUE_OFFSET (v);
+ len = TYPE_LENGTH (VALUE_TYPE (v));
+ type = hw_write;
+ if (b->type == bp_read_watchpoint)
+ type = hw_read;
+ else if (b->type == bp_access_watchpoint)
+ type = hw_access;
+
+ val = target_insert_watchpoint (addr, len, type);
+ if (val == -1)
+ {
+ /* Don't exit the loop, try to insert
+ every value on the value chain. That's
+ because we will be removing all the
+ watches below, and removing a
+ watchpoint we didn't insert could have
+ adverse effects. */
+ b->inserted = 0;
+ }
+ val = 0;
}
- val = 0;
}
}
/* Failure to insert a watchpoint on any memory value in the
@@ -1327,21 +1342,28 @@ remove_breakpoint (b, is)
if (VALUE_LVAL (v) == lval_memory
&& ! VALUE_LAZY (v))
{
- CORE_ADDR addr;
- int len, type;
+ struct type *vtype = check_typedef (VALUE_TYPE (v));
- addr = VALUE_ADDRESS (v) + VALUE_OFFSET (v);
- len = TYPE_LENGTH (VALUE_TYPE (v));
- type = hw_write;
- if (b->type == bp_read_watchpoint)
- type = hw_read;
- else if (b->type == bp_access_watchpoint)
- type = hw_access;
-
- val = target_remove_watchpoint (addr, len, type);
- if (val == -1)
- b->inserted = 1;
- val = 0;
+ if (v == b->val_chain
+ || (TYPE_CODE (vtype) != TYPE_CODE_STRUCT
+ && TYPE_CODE (vtype) != TYPE_CODE_ARRAY))
+ {
+ CORE_ADDR addr;
+ int len, type;
+
+ addr = VALUE_ADDRESS (v) + VALUE_OFFSET (v);
+ len = TYPE_LENGTH (VALUE_TYPE (v));
+ type = hw_write;
+ if (b->type == bp_read_watchpoint)
+ type = hw_read;
+ else if (b->type == bp_access_watchpoint)
+ type = hw_access;
+
+ val = target_remove_watchpoint (addr, len, type);
+ if (val == -1)
+ b->inserted = 1;
+ val = 0;
+ }
}
}
/* Failure to remove any of the hardware watchpoints comes here. */
@@ -2571,14 +2593,21 @@ bpstat_stop_status (pc, not_a_breakpoint
if (VALUE_LVAL (v) == lval_memory
&& ! VALUE_LAZY (v))
{
- CORE_ADDR vaddr;
+ struct type *vtype = check_typedef (VALUE_TYPE (v));
- vaddr = VALUE_ADDRESS (v) + VALUE_OFFSET (v);
- /* Exact match not required. Within range is sufficient.
- */
- if (addr >= vaddr &&
- addr < vaddr + TYPE_LENGTH (VALUE_TYPE (v)))
- found = 1;
+ if (v == b->val_chain
+ || (TYPE_CODE (vtype) != TYPE_CODE_STRUCT
+ && TYPE_CODE (vtype) != TYPE_CODE_ARRAY))
+ {
+ CORE_ADDR vaddr;
+
+ vaddr = VALUE_ADDRESS (v) + VALUE_OFFSET (v);
+ /* Exact match not required. Within range is
+ sufficient. */
+ if (addr >= vaddr &&
+ addr < vaddr + TYPE_LENGTH (VALUE_TYPE (v)))
+ found = 1;
+ }
}
}
if (found)
@@ -5515,6 +5544,7 @@ can_use_hardware_watchpoint (v)
struct value *v;
{
int found_memory_cnt = 0;
+ struct value *head = v;
/* Did the user specifically forbid us to use hardware watchpoints? */
if (!can_use_hw_watchpoints)
@@ -5552,13 +5582,23 @@ can_use_hardware_watchpoint (v)
{
/* Ahh, memory we actually used! Check if we can cover
it with hardware watchpoints. */
- CORE_ADDR vaddr = VALUE_ADDRESS (v) + VALUE_OFFSET (v);
- int len = TYPE_LENGTH (VALUE_TYPE (v));
+ struct type *vtype = check_typedef (VALUE_TYPE (v));
- if (!TARGET_REGION_OK_FOR_HW_WATCHPOINT (vaddr, len))
- return 0;
- else
- found_memory_cnt++;
+ /* We only watch structs and arrays if user asked for it
+ explicitly, never if they just happen to appear in a
+ middle of some value chain. */
+ if (v == head
+ || (TYPE_CODE (vtype) != TYPE_CODE_STRUCT
+ && TYPE_CODE (vtype) != TYPE_CODE_ARRAY))
+ {
+ CORE_ADDR vaddr = VALUE_ADDRESS (v) + VALUE_OFFSET (v);
+ int len = TYPE_LENGTH (VALUE_TYPE (v));
+
+ if (!TARGET_REGION_OK_FOR_HW_WATCHPOINT (vaddr, len))
+ return 0;
+ else
+ found_memory_cnt++;
+ }
}
}
else if (v->lval != not_lval && v->modifiable == 0)
--- gdb/values.c~0 Thu Sep 9 02:20:18 1999
+++ gdb/values.c Wed Mar 8 18:53:48 2000
@@ -802,6 +802,8 @@ value_primitive_field (arg1, offset, fie
fieldno));
VALUE_BITPOS (v) = TYPE_FIELD_BITPOS (arg_type, fieldno) % 8;
VALUE_BITSIZE (v) = TYPE_FIELD_BITSIZE (arg_type, fieldno);
+ VALUE_OFFSET (v) = VALUE_OFFSET (arg1) + offset
+ + TYPE_FIELD_BITPOS (arg_type, fieldno) / 8;
}
else if (fieldno < TYPE_N_BASECLASSES (arg_type))
{
From eliz@delorie.com Thu Mar 09 04:11:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: hjl@lucon.org
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Thu, 09 Mar 2000 04:11:00 -0000
Message-id: <200003091211.HAA19860@indy.delorie.com>
References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org>
X-SW-Source: 2000-03/msg00174.html
Content-length: 1704
Problem no.2: Read watchpoints break when they shouldn't.
Example (slightly modified test program posted by H.J. Lu):
$ cat wp.c
int a1;
int a2;
int a3;
int a4;
int a5;
int a6;
unsigned long long ulla1 = 0;
double da2 = 0;
int main (void)
{
a2 = 12;
a3 = 13;
a4 = 14;
a5 = 15;
a6 = 16;
a1 = 11;
a2 = a4;
ulla1 = 0x00000000ffffffffLL;
da2 = 12;
ulla1 = 0xffffffff00000000LL;
return 0;
}
$ gcc -g -o wp wp.c
$ gdb wp
(gdb) watch a5
Hardware watchpoint 2: a5
(gdb) rwatch a5
Hardware read watchpoint 3: a5
(gdb) run
Starting program g:/gdbsnap/gdb-0222/gdb/wp
Hardware watchpoint 2: a5
Old value = 0
New value = 15
Hardware read watchpoint 3: a5
Value = 15
main () at wp.c: 16
16 a5 = 15;
(gdb)
Now, it might seem like a strange idea to put two watchpoints on the
same variable, but it is a very useful feature when each watchpoint
has a different condition.
Here's the patch:
2000-03-08 Eli Zaretskii <eliz@is.elta.co.il>
* breakpoint.c (bpstat_stop_status): Don't stop if a read
watchpoint appears to break, but the watched value changed.
--- gdb/breakpoint.c~2 Wed Mar 8 19:20:28 2000
+++ gdb/breakpoint.c Wed Mar 8 20:02:20 2000
@@ -2620,6 +2620,17 @@ bpstat_stop_status (pc, not_a_breakpoint
/* Stop. */
break;
case WP_VALUE_CHANGED:
+ if (b->type == bp_read_watchpoint)
+ {
+ /* Don't stop: read watchpoints shouldn't fire if
+ the value has changed. This is for targets which
+ cannot set read-only watchpoints. */
+ bs->print_it = print_it_noop;
+ bs->stop = 0;
+ continue;
+ }
+ ++(b->hit_count);
+ break;
case WP_VALUE_NOT_CHANGED:
/* Stop. */
++(b->hit_count);
From ac131313@cygnus.com Thu Mar 09 05:20:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Charles-Antoine Gauthier <charles.gauthier@nrc.ca>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: GDB patch for 167Bug
Date: Thu, 09 Mar 2000 05:20:00 -0000
Message-id: <38C7A4F6.8CA859E6@cygnus.com>
References: <38C42988.2AE770D7@nrc.ca>
X-SW-Source: 2000-03/msg00175.html
Content-length: 3040
Charles-Antoine Gauthier wrote:
>
> Attached is a patch to allow GDB 4.18 to write to the MVME167 through
> 167Bug. The MS command does not work; the MW command must be used.
>
> The ChangeLog hunk has context from the RTEMS patches. It probably will
> not apply cleanly, but it is quite short.
As far as I know, GDB doesn't contain the file ``167bug-rom.c''. Could
this be a local version?
Andrew
PS, FYI, when submitting patches, they shouldn't include a diff to the
ChangeLog, see ``submitting a patch'' in:
http://sourceware.cygnus.com/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/CONTRIBUTE?content-type=text/x-cvsweb-markup&cvsroot=src
>
> ------------------------------------------------------------------------
> *** gdb-4.18/gdb/167bug-rom.c Mon Mar 6 14:20:50 2000
> --- ../gdb/gdb/167bug-rom.c Mon Mar 6 14:54:42 2000
> ***************
> *** 110,118 ****
> m167bug_cmds.clr_break = "nobr %x\r"; /* clear a breakpoint */
> m167bug_cmds.clr_all_break = "nobr\r"; /* clear all breakpoints */
> m167bug_cmds.fill = "bf %x:%x %x;b\r"; /* fill (start count val) */
> ! m167bug_cmds.setmem.cmdb = "ms %x %02x\r"; /* setmem.cmdb (addr, value) */
> ! m167bug_cmds.setmem.cmdw = "ms %x %04x\r"; /* setmem.cmdw (addr, value) */
> ! m167bug_cmds.setmem.cmdl = "ms %x %08x\r"; /* setmem.cmdl (addr, value) */
> m167bug_cmds.setmem.cmdll = NULL; /* setmem.cmdll (addr, value) */
> m167bug_cmds.setmem.resp_delim = NULL; /* setreg.resp_delim */
> m167bug_cmds.setmem.term = NULL; /* setreg.term */
> --- 110,118 ----
> m167bug_cmds.clr_break = "nobr %x\r"; /* clear a breakpoint */
> m167bug_cmds.clr_all_break = "nobr\r"; /* clear all breakpoints */
> m167bug_cmds.fill = "bf %x:%x %x;b\r"; /* fill (start count val) */
> ! m167bug_cmds.setmem.cmdb = "mw %x %02x;b\r"; /* setmem.cmdb (addr, value) */
> ! m167bug_cmds.setmem.cmdw = "mw %x %04x;w\r"; /* setmem.cmdw (addr, value) */
> ! m167bug_cmds.setmem.cmdl = "mw %x %08x;l\r"; /* setmem.cmdl (addr, value) */
> m167bug_cmds.setmem.cmdll = NULL; /* setmem.cmdll (addr, value) */
> m167bug_cmds.setmem.resp_delim = NULL; /* setreg.resp_delim */
> m167bug_cmds.setmem.term = NULL; /* setreg.term */
> *** gdb-4.18/gdb/ChangeLog Mon Mar 6 15:38:40 2000
> --- ../gdb/gdb/ChangeLog Mon Mar 6 16:33:39 2000
> ***************
> *** 1,3 ****
> --- 1,7 ----
> + 2000-03-06 Charles-Antoine Gauthier <charles.gauthier@nrc.ca>
> +
> + * 167bug-rom.c(init_m167bug_cmds): Change the write commands.
> +
> Fri Aug 6 165:41:15 EDT 1999 Charles-A. Gauthier <charles.gauthier@iit.nrc.ca>
>
> * config/m68k/monitor.mt (TDEPFILES): Add 167bug-rom.o.
From eliz@delorie.com Thu Mar 09 05:28:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: toddpw@windriver.com
Cc: jtc@redback.com, hjl@valinux.com, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A patch for ia32 hardware watchpoint.
Date: Thu, 09 Mar 2000 05:28:00 -0000
Message-id: <200003091328.IAA19934@indy.delorie.com>
References: <200003080845.AAA18410@alabama.wrs.com>
X-SW-Source: 2000-03/msg00176.html
Content-length: 1307
> As far as I'm concerned, passing the breakpoint pointer is the right way
> to go; we should get away from the assumption that a target side breakpoint
> is an address with some #define'd size, and push that stuff into a default
> implementation that can be invoked easily by people writing new target
> support.
I agree.
But if we do that, I'd also suggest to leave it to the target to
decide whether a particular watchpoint fired or not.
Right now, the API presented by GDB is based solely on the address:
bpstat_stop_status calls target_stopped_data_address and does all the
decision-making based solely on that address (and some info it keeps
internally about each watchpoint).
This API is extremely limited. Typically, the target knows much more
about the watchpoint which triggered than the generic GDB code does,
so it can make smarter decisions. But in order to do that, the target
needs more information about the watchpoint, and it needs to pass back
to GDB the result (whether the watchpoint triggered or not), not its
address.
Btw, if we let the target decide whether a given watchpoint triggered,
we can also resolve, once and for all, all the various conflicts
between target-specific limitations of hardware-assisted watchpoints,
which now need to be dealt with on the generic level.
From ac131313@cygnus.com Thu Mar 09 05:33:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: procfs.c:proc_set_watchpoint bug fix
Date: Thu, 09 Mar 2000 05:33:00 -0000
Message-id: <38C7A799.A06CF13B@cygnus.com>
References: <200003072114.WAA26143@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-03/msg00178.html
Content-length: 845
"Peter.Schauer" wrote:
> * procfs.c (proc_set_watchpoint): Declare addr parameter as
> CORE_ADDR, to match call from procfs_set_watchpoint.
Might as well get the knife out - convert the definition to ISO-C and
make it static. (Good find, outch!)
enjoy,
Andrew
> *** 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 eliz@delorie.com Thu Mar 09 05:33:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ezannoni@cygnus.com
Cc: shebs@apple.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Handle_inferior_event() problem
Date: Thu, 09 Mar 2000 05:33:00 -0000
Message-id: <200003091332.IAA19945@indy.delorie.com>
References: <14533.28395.325377.920332@kwikemart.cygnus.com>
X-SW-Source: 2000-03/msg00177.html
Content-length: 511
> Say you have stepped your way to the first instruction of the prologue
> of a function (using stepi, for instance) and now you do a 'nexti'.
> The programs runs away to the end of the function or somewhere else and
> gdb gets really confused.
Confirmed in the DJGPP version: the problem exists just like you
described.
> Anyway, long story short... How about this patch? It doesn't take
> care of everything, but it solves that immediate problem.
Confirmed again: problem solved with this patch. Thanks!
From eliz@delorie.com Thu Mar 09 05:37:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Peter.Schauer@regent.e-technik.tu-muenchen.de
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: breakpoint.c: Minor output fixes for hardware watchpoints
Date: Thu, 09 Mar 2000 05:37:00 -0000
Message-id: <200003091337.IAA19948@indy.delorie.com>
References: <200003072114.WAA26280@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-03/msg00179.html
Content-length: 884
> During implementation of hardware watchpoints on Solaris, I noticed the
> following inconsistencies in breakpoint.c output between software and
> hardware breakpoints.
Both problems confirmed on x86 using the DJGPP native version.
Actually, these two problems were on my todo list since last summer,
but since they are merely annoyances, they got pushed back ;-).
> 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.
Both problems are gone with these patches in the DJGPP version.
Thanks!
From scottb@netwinder.org Thu Mar 09 06:02:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Patch fallen through the cracks?
Date: Thu, 09 Mar 2000 06:02:00 -0000
Message-id: <38C7ADD4.A6697C36@netwinder.org>
X-SW-Source: 2000-03/msg00180.html
Content-length: 253
Can someone approve this patch please. It shouldn't be a problem.
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00367.html
Scott
--
Scott Bambrough - Software Engineer
REBEL.COM http://www.rebel.com
NetWinder http://www.netwinder.org
From ac131313@cygnus.com Thu Mar 09 06:51:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "H . J . Lu" <hjl@valinux.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: A patch for Solairis 2.7/x86.
Date: Thu, 09 Mar 2000 06:51:00 -0000
Message-id: <38C7BA33.C0BA455@cygnus.com>
References: <20000307135347.A20608@valinux.com>
X-SW-Source: 2000-03/msg00181.html
Content-length: 331
"H . J . Lu" wrote:
>
> I have reported it long time ago. I am resending my patch now.
> +/* On sol2.7, <curses.h> emits a bunch of 'macro redefined'
> + warnings, which makes autoconf think curses.h doesn't
> + exist. Compensate fot that here. */
> +#define HAVE_CURSES_H 1
This sounds more like an autoconf bug.
Andrew
From fnasser@redhat.com Thu Mar 09 07:03:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: Patch fallen through the cracks?
Date: Thu, 09 Mar 2000 07:03:00 -0000
Message-id: <38C7BD11.9A8188CF@redhat.com>
References: <38C7ADD4.A6697C36@netwinder.org>
X-SW-Source: 2000-03/msg00182.html
Content-length: 746
Scott Bambrough wrote:
>
> Can someone approve this patch please. It shouldn't be a problem.
>
> http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00367.html
>
I would rather have it xfail'ed. It means that we know this test won't
work on this platform but it is not ding what we want (this is what pass
would mean).
Could you please add a small comment before the "if" as well, explaining
why it won't work on ARM?
After these changes there is no need to resubmit the patch though, just
post what went in.
Thanks.
--
Fernando Nasser
Red Hat, Inc. - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From fnasser@redhat.com Thu Mar 09 07:13:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: store_floating() and arm-tdep.c
Date: Thu, 09 Mar 2000 07:13:00 -0000
Message-id: <38C7BF53.731F8CF6@redhat.com>
References: <1000229000345.ZM15006@ocotillo.lan> <38BCE46B.CD7889B5@cygnus.com> <1000302074643.ZM19182@ocotillo.lan>
X-SW-Source: 2000-03/msg00183.html
Content-length: 1142
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 won't be able to get to this until next week and I am afraid that
Andrew will cut a gdb 5 branch before that.
I wonder if anyone (Scott? Kevin?) could/would be willing to do that
sooner.
Please let me know if you can so I don't start to work on it as well.
Thanks.
Fernando
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" :-)
Kevin Buettner wrote:
>
> On Mar 1, 8:35pm, Andrew Cagney wrote:
>
> > > * findvar.c (extract_floating, store_floating): Use target
> > > floating point type sizes rather host sizes to determine
> [...]
> > Approved.
>
> Committed.
>
> Kevin
--
Fernando Nasser
Red Hat, Inc. - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From ac131313@cygnus.com Thu Mar 09 07:16:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "H . J . Lu" <hjl@valinux.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: A patch for ia32 hardware watchpoint.
Date: Thu, 09 Mar 2000 07:16:00 -0000
Message-id: <38C7C031.2F0F6D7A@cygnus.com>
References: <20000307132613.B20282@valinux.com>
X-SW-Source: 2000-03/msg00184.html
Content-length: 973
"H . J . Lu" wrote:
> +#ifdef NEED_WATCHPOINT_NUMBER
> + val = target_insert_watchpoint (b->number, addr,
> + len, type);
> +#else
> val = target_insert_watchpoint (addr, len, type);
> +#endif
> +#ifdef NEED_WATCHPOINT_NUMBER
> + val = target_remove_watchpoint (b->number, addr, len,
> + type);
> +#else
> val = target_remove_watchpoint (addr, len, type);
> +#endif
> +#ifdef NEED_WATCHPOINT_NUMBER
> + if (bpt->type == bp_hardware_watchpoint)
> + target_delete_watchpoint (bpt->number);
> +#endif
Just FYI, changes like this are no longer acceptable in generic parts of
GDB (they were once and I spent a good part of a year trying to purge
the worst of them).
Either, test the conditional before the call or (often better) always
make the call and provide a default NOP version of the function.
Andrew
From ac131313@cygnus.com Thu Mar 09 07:24:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: Scott Bambrough <scottb@netwinder.org>, GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: Patch fallen through the cracks?
Date: Thu, 09 Mar 2000 07:24:00 -0000
Message-id: <38C7C1C8.C4A8796A@cygnus.com>
References: <38C7ADD4.A6697C36@netwinder.org> <38C7BD11.9A8188CF@redhat.com>
X-SW-Source: 2000-03/msg00185.html
Content-length: 692
Fernando Nasser wrote:
>
> Scott Bambrough wrote:
> >
> > Can someone approve this patch please. It shouldn't be a problem.
> >
> > http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00367.html
> >
>
> I would rather have it xfail'ed. It means that we know this test won't
> work on this platform but it is not ding what we want (this is what pass
> would mean).
I thought the patch was basically correct - the arm has that brain dead
wacko swapped double format.
The only suggestion I've had made would be to test a more generic
attribute indicating the exact format of a double V long rather than
test the arm target. Other platforms can have the same problem.
enjoy,
Andrew
From fnasser@redhat.com Thu Mar 09 07:42:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Scott Bambrough <scottb@netwinder.org>, GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: Patch fallen through the cracks?
Date: Thu, 09 Mar 2000 07:42:00 -0000
Message-id: <38C7C5FF.FB73F0E2@redhat.com>
References: <38C7ADD4.A6697C36@netwinder.org> <38C7BD11.9A8188CF@redhat.com> <38C7C1C8.C4A8796A@cygnus.com>
X-SW-Source: 2000-03/msg00186.html
Content-length: 727
Andrew Cagney wrote:
>
> The only suggestion I've had made would be to test a more generic
> attribute indicating the exact format of a double V long rather than
> test the arm target. Other platforms can have the same problem.
>
This would be really nice. Maybe a previous test that would ascertain
how the doubles are stored and set a tcl variable accordingly. This
could then be tested to xfail or not the test that is currently failing.
But I am not sure how to do it (what to test).
Any suggestions?
--
Fernando Nasser
Red Hat, Inc. - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From ac131313@cygnus.com Thu Mar 09 07:49:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "H . J . Lu" <hjl@valinux.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: A new revised patch for dlclose
Date: Thu, 09 Mar 2000 07:49:00 -0000
Message-id: <38C7C7C7.CD90829D@cygnus.com>
References: <20000307120800.A27315@valinux.com> <20000307122129.A3568@valinux.com>
X-SW-Source: 2000-03/msg00187.html
Content-length: 841
"H . J . Lu" wrote:
>
> On Tue, Mar 07, 2000 at 12:08:00PM -0800, H . J . Lu wrote:
> > Here is a revised patch for dlclose. If you take a look at the
> > dynamic linker in glibc 2.1 or above, you will find that it informs
> > gdb about loading/unloading a shared library via an internal debug
> > function, _dl_debug_state (). gdb already handles the loading in
> > handle_inferior_event () with BPSTAT_WHAT_CHECK_SHLIBS and
> > BPSTAT_WHAT_CHECK_SHLIBS_RESUME_FROM_HOOK. However, we need also
> > check the unloading event. solib_verify () will be called only when the
> > dynamic linker calls _dl_debug_state (). It shouldn't introduce any
> > overhead. I believe it is on the right track although it may be further
> > optimized.
H.J., I'm curious. Who is Sam Lantinga, they don't show up in GDB's
copyright assignment file.
Andrew
From hjl@lucon.org Thu Mar 09 07:56:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: A new revised patch for dlclose
Date: Thu, 09 Mar 2000 07:56:00 -0000
Message-id: <20000309075645.A7175@lucon.org>
References: <20000307120800.A27315@valinux.com> <20000307122129.A3568@valinux.com> <38C7C7C7.CD90829D@cygnus.com>
X-SW-Source: 2000-03/msg00188.html
Content-length: 1096
On Fri, Mar 10, 2000 at 02:48:23AM +1100, Andrew Cagney wrote:
> "H . J . Lu" wrote:
> >
> > On Tue, Mar 07, 2000 at 12:08:00PM -0800, H . J . Lu wrote:
> > > Here is a revised patch for dlclose. If you take a look at the
> > > dynamic linker in glibc 2.1 or above, you will find that it informs
> > > gdb about loading/unloading a shared library via an internal debug
> > > function, _dl_debug_state (). gdb already handles the loading in
> > > handle_inferior_event () with BPSTAT_WHAT_CHECK_SHLIBS and
> > > BPSTAT_WHAT_CHECK_SHLIBS_RESUME_FROM_HOOK. However, we need also
> > > check the unloading event. solib_verify () will be called only when the
> > > dynamic linker calls _dl_debug_state (). It shouldn't introduce any
> > > overhead. I believe it is on the right track although it may be further
> > > optimized.
>
> H.J., I'm curious. Who is Sam Lantinga, they don't show up in GDB's
> copyright assignment file.
>
I think he works for Loki, the game company. They use thread and dlopen
a lot. In anycase, my latest dlclose fix is totally different from his
original patch.
H.J.
From hjl@valinux.com Thu Mar 09 07:59:00 2000
From: "H . J . Lu" <hjl@valinux.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: A patch for Solairis 2.7/x86.
Date: Thu, 09 Mar 2000 07:59:00 -0000
Message-id: <20000309075920.A15938@valinux.com>
References: <20000307135347.A20608@valinux.com> <38C7BA33.C0BA455@cygnus.com>
X-SW-Source: 2000-03/msg00189.html
Content-length: 592
On Fri, Mar 10, 2000 at 01:50:27AM +1100, Andrew Cagney wrote:
> "H . J . Lu" wrote:
> >
> > I have reported it long time ago. I am resending my patch now.
>
> > +/* On sol2.7, <curses.h> emits a bunch of 'macro redefined'
> > + warnings, which makes autoconf think curses.h doesn't
> > + exist. Compensate fot that here. */
> > +#define HAVE_CURSES_H 1
>
> This sounds more like an autoconf bug.
>
That may be true. I just copied the code from Solaris 2.7/Sparc when
I was puzzled by why I could build gdb on Solaris 2.7/Sparc, but not
Solairis 2.7/x86.
--
H.J. Lu (hjl@gnu.org)
From scottb@netwinder.org Thu Mar 09 08:01:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: Fernando Nasser <fnasser@redhat.com>
Cc: Kevin Buettner <kevinb@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: store_floating() and arm-tdep.c
Date: Thu, 09 Mar 2000 08:01:00 -0000
Message-id: <38C7C9A4.3566EC87@netwinder.org>
References: <1000229000345.ZM15006@ocotillo.lan> <38BCE46B.CD7889B5@cygnus.com> <1000302074643.ZM19182@ocotillo.lan> <38C7BF53.731F8CF6@redhat.com>
X-SW-Source: 2000-03/msg00190.html
Content-length: 1193
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.
=== gdb Summary ===
# of expected passes 6306
# of unexpected failures 46
# of unexpected successes 1
# of expected failures 195
# of unresolved testcases 1
# of untested testcases 18
--
Scott Bambrough - Software Engineer
REBEL.COM http://www.rebel.com
NetWinder http://www.netwinder.org
From msnyder@cygnus.com Thu Mar 09 10:49: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: Thu, 09 Mar 2000 10:49: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-03/msg00191.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 ezannoni@cygnus.com Thu Mar 09 10:51:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: PATCH: printing elements of typedef'ed arrays
Date: Thu, 09 Mar 2000 10:51:00 -0000
Message-id: <14535.62150.908914.943283@kwikemart.cygnus.com>
X-SW-Source: 2000-03/msg00192.html
Content-length: 1493
[Sorry, wrong list...]
When an array is typedeffed, like in this example:
typedef long ArrayLong [10];
ArrayLong a1;
typedef struct s
{
int a;
int b;
} structure;
long a2 [10];
structure s1;
int main (void)
{
return 0;
}
Gdb cannot print individual elements of the array a1:
(gdb) p a1
$1 = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
(gdb) p a1[0]
$2 = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0} <<<< is incorrect
(gdb) p a2
$3 = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
(gdb) p a2[0]
$4 = 0
(gdb)
The following patch takes care of this.
I tested it on solaris and showed no regressions.
OK to check in?
Elena
% cvs diff -c eval.c
Index: eval.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/eval.c,v
retrieving revision 1.107
diff -c -r1.107 eval.c
*** eval.c 1999/12/11 13:52:47 1.107
--- eval.c 2000/03/09 18:36:54
***************
*** 1875,1881 ****
val =
locate_var_value
(var, block_innermost_frame (exp->elts[pc + 1].block));
! return value_cast (lookup_pointer_type (TYPE_TARGET_TYPE (SYMBOL_TYPE (var))),
val);
}
/* FALLTHROUGH */
--- 1875,1881 ----
val =
locate_var_value
(var, block_innermost_frame (exp->elts[pc + 1].block));
! return value_cast (lookup_pointer_type (TYPE_TARGET_TYPE (check_typedef (SYMBOL_TYPE (var)))),
val);
}
/* FALLTHROUGH */
From shebs@apple.com Thu Mar 09 11:09:00 2000
From: Stan Shebs <shebs@apple.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: Patch fallen through the cracks?
Date: Thu, 09 Mar 2000 11:09:00 -0000
Message-id: <38C7F6D6.D49D9B04@apple.com>
References: <38C7ADD4.A6697C36@netwinder.org>
X-SW-Source: 2000-03/msg00193.html
Content-length: 477
Scott Bambrough wrote:
>
> Can someone approve this patch please. It shouldn't be a problem.
>
> http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00367.html
OK OK, I know I'm a slacker. :-) But so as to avoid confusing
future generations of hackers (scary thought, to imagine people
running the GDB testsuite in 2025...), you should put your basic
rationale for the different number in a comment for this test -
it's not obvious from the patch alone. Thanks!
Stan
From shebs@apple.com Thu Mar 09 11:18:00 2000
From: Stan Shebs <shebs@apple.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: "H . J . Lu" <hjl@valinux.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: A new revised patch for dlclose
Date: Thu, 09 Mar 2000 11:18:00 -0000
Message-id: <38C7F8F2.3C4AE23C@apple.com>
References: <20000307120800.A27315@valinux.com> <20000307122129.A3568@valinux.com> <38C7C7C7.CD90829D@cygnus.com>
X-SW-Source: 2000-03/msg00194.html
Content-length: 537
Andrew Cagney wrote:
> H.J., I'm curious. Who is Sam Lantinga, they don't show up in GDB's
> copyright assignment file.
Sam is the main genius behind all those commercial Linux games you
can see on store shelves these days. He also maintains the SDL
library, which is the LGPL cross-platform library that makes those
game ports possible. (Dig under lokigames.com's open source pages
to see more.) Sam thus qualifies as a key GDB user who should be
taken seriously, and who is clearly not afraid to hack GDB if it
needs it...
Stan
From hjl@lucon.org Thu Mar 09 13:58:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: gdb-patches@sourceware.cygnus.com
Subject: A new patch for regex
Date: Thu, 09 Mar 2000 13:58:00 -0000
Message-id: <20000309135848.A8287@lucon.org>
X-SW-Source: 2000-03/msg00195.html
Content-length: 7258
This patch overrides all the previous ones.
H.J.
----
2000-03-09 H.J. Lu <hjl@gnu.org>
* gdb_regex.h: New. Include "regex.h" if USE_INCLUDED_REGEX
is defined and <regex.h> otherwise.
* irix5-nat.c: Include "gdb_regex.h" instead of "gnu-regex.h".
* monitor.c: Likewise.
* osfsolib.c: Likewise.
* solib.c: Likewise.
* source.c: Likewise.
* symtab.c: Likewise.
* Makefile.in (REGEX): Changed to @REGEX@.
(REGEX_CFLAGS): New.
(REGEX1): Removed.
(ADD_DEPS): Use $(REGEX) instead of $(REGEX1).
(INTERNAL_WARN_CFLAGS): Add $(REGEX_CFLAGS).
* configure.in (--with-included-regex): New switch.
(REGEX): New. Subsstitue @REGEX@ in Makefile.in.
(REGEX_CFLAGS): New. Subsstitue @REGEX_CFLAGS@ in Makefile.in.
* configure: Regenerated.
Index: irix5-nat.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/irix5-nat.c,v
retrieving revision 1.1.1.3
retrieving revision 1.3
diff -u -p -r1.1.1.3 -r1.3
--- irix5-nat.c 1999/11/19 23:38:46 1.1.1.3
+++ irix5-nat.c 2000/03/08 00:36:03 1.3
@@ -278,7 +278,7 @@ fetch_core_registers (core_reg_sect, cor
#include "objfiles.h"
#include "command.h"
#include "frame.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "inferior.h"
#include "language.h"
#include "gdbcmd.h"
Index: monitor.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/monitor.c,v
retrieving revision 1.1.1.5
retrieving revision 1.3
diff -u -p -r1.1.1.5 -r1.3
--- monitor.c 2000/03/07 18:42:14 1.1.1.5
+++ monitor.c 2000/03/08 00:36:03 1.3
@@ -50,7 +50,7 @@
#include "monitor.h"
#include "gdbcmd.h"
#include "inferior.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "dcache.h"
#include "srec.h"
Index: osfsolib.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/osfsolib.c,v
retrieving revision 1.1.1.3
retrieving revision 1.3
diff -u -p -r1.1.1.3 -r1.3
--- osfsolib.c 1999/11/19 23:38:50 1.1.1.3
+++ osfsolib.c 2000/03/08 00:36:03 1.3
@@ -36,7 +36,7 @@
#include "command.h"
#include "target.h"
#include "frame.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "inferior.h"
#include "language.h"
#include "gdbcmd.h"
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
@@ -49,7 +49,7 @@
#include "command.h"
#include "target.h"
#include "frame.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "inferior.h"
#include "environ.h"
#include "language.h"
Index: source.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/source.c,v
retrieving revision 1.1.1.3
retrieving revision 1.3
diff -u -p -r1.1.1.3 -r1.3
--- source.c 2000/02/04 20:21:58 1.1.1.3
+++ source.c 2000/03/08 00:36:03 1.3
@@ -33,7 +33,7 @@
#include "gdb_stat.h"
#include <fcntl.h>
#include "gdbcore.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "symfile.h"
#include "objfiles.h"
#include "annotate.h"
Index: symtab.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/symtab.c,v
retrieving revision 1.1.1.4
retrieving revision 1.3
diff -u -p -r1.1.1.4 -r1.3
--- symtab.c 2000/03/07 18:42:17 1.1.1.4
+++ symtab.c 2000/03/08 00:36:03 1.3
@@ -30,7 +30,7 @@
#include "objfiles.h"
#include "gdbcmd.h"
#include "call-cmds.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "expression.h"
#include "language.h"
#include "demangle.h"
Index: Makefile.in
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/Makefile.in,v
retrieving revision 1.1.1.9
diff -u -p -r1.1.1.9 Makefile.in
--- Makefile.in 2000/03/07 18:42:08 1.1.1.9
+++ Makefile.in 2000/03/08 23:48:52
@@ -114,6 +114,11 @@ LIBIBERTY = ../libiberty/libiberty.a
MMALLOC = @MMALLOC@
MMALLOC_CFLAGS = @MMALLOC_CFLAGS@
+# We are using our own version of REGEX now to be consistent across
+# machines.
+REGEX = @REGEX@
+REGEX_CFLAGS = @REGEX_CFLAGS@
+
# Where is the BFD library? Typically in ../bfd.
BFD_DIR = ../bfd
BFD = $(BFD_DIR)/libbfd.a
@@ -271,7 +276,8 @@ INTERNAL_WARN_CFLAGS = \
$(CFLAGS) $(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) \
$(GDB_CFLAGS) $(OPCODES_CFLAGS) $(READLINE_CFLAGS) \
$(BFD_CFLAGS) $(MMALLOC_CFLAGS) $(INCLUDE_CFLAGS) \
- $(INTL_CFLAGS) $(TUI_CFLAGS) $(ENABLE_CFLAGS) $(GDB_WARN_CFLAGS)
+ $(INTL_CFLAGS) $(TUI_CFLAGS) $(ENABLE_CFLAGS) \
+ $(REGEX_CFLAGS) $(GDB_WARN_CFLAGS)
INTERNAL_CFLAGS = $(INTERNAL_WARN_CFLAGS) $(GDB_WERROR_CFLAGS)
# LDFLAGS is specifically reserved for setting from the command line
@@ -283,11 +289,6 @@ INTERNAL_CFLAGS = $(INTERNAL_WARN_CFLAGS
INTERNAL_LDFLAGS = $(CFLAGS) $(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) $(LDFLAGS) $(CONFIG_LDFLAGS) @HLDFLAGS@
HLDENV = @HLDENV@
-# We are using our own version of REGEX now to be consistent across
-# machines.
-REGEX = gnu-regex.o
-REGEX1 = gnu-regex.o
-
# If your system is missing alloca(), or, more likely, it's there but
# it doesn't work, then refer to libiberty.
@@ -308,7 +309,7 @@ CDEPS = $(XM_CDEPS) $(TM_CDEPS) $(NAT_CD
$(OPCODES) $(MMALLOC) $(INTL_DEPS) $(LIBIBERTY) $(CONFIG_DEPS)
ADD_FILES = $(REGEX) $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
-ADD_DEPS = $(REGEX1) $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
+ADD_DEPS = $(REGEX) $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
VERSION = 20000204
DIST=gdb
Index: configure.in
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/configure.in,v
retrieving revision 1.1.1.6
diff -u -p -r1.1.1.6 configure.in
--- configure.in 2000/03/07 18:42:10 1.1.1.6
+++ configure.in 2000/03/09 21:50:46
@@ -505,6 +505,36 @@ if test x$want_mmalloc = xtrue; then
MMALLOC='../mmalloc/libmmalloc.a'
fi
+AC_ARG_WITH(included-regex,
+[ --with-included-regex Use included regex],
+[case "${withval}" in
+ yes) want_included_regex=true ;;
+ no) want_included_regex=false;;
+ *) AC_MSG_ERROR(bad value ${withval} for GDB with-included-regex option) ;;
+esac],[want_included_regex=false])dnl
+
+REGEX="gnu-regex.o"
+REGEX_CFLAGS="-DUSE_INCLUDED_REGEX"
+if test $want_included_regex = false; then
+ AC_MSG_CHECKING(for GNU regex)
+ AC_CACHE_VAL(gdb_cv_have_gnu_regex,
+[AC_TRY_COMPILE([#include <gnu-versions.h>
+#include <sys/types.h>
+#include <regex.h>],
+[#if !defined _GNU_REGEX_INTERFACE_VERSION || !defined __GLIBC__ || __GLIBC__ < 2
+#error No valid GNU regex.
+#endif
+],
+ [gdb_cv_have_gnu_regex=yes],
+ [gdb_cv_have_gnu_regex=no])])
+ AC_MSG_RESULT($gdb_cv_have_gnu_regex)
+ if test $gdb_cv_have_gnu_regex = yes; then
+ REGEX=
+ REGEX_CFLAGS=
+ fi
+fi
+AC_SUBST(REGEX)
+AC_SUBST(REGEX_CFLAGS)
# In the Cygwin environment, we need some additional flags.
AC_CACHE_CHECK([for cygwin], gdb_cv_os_cygwin,
--- /dev/null Tue May 5 13:32:27 1998
+++ gdb_regex.h Thu Mar 9 13:31:26 2000
@@ -0,0 +1,7 @@
+#ifndef _GDB_REGEX_H
+#ifdef USE_INCLUDED_REGEX
+#include "gnu-regex.h"
+#else
+#include <regex.h>
+#endif
+#endif /* _GDB_REGEX_H */
From hjl@lucon.org Thu Mar 09 14:09:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: muller@cerbere.u-strasbg.fr
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: A new patch for regex
Date: Thu, 09 Mar 2000 14:09:00 -0000
Message-id: <20000309140937.A8350@lucon.org>
References: <20000309135848.A8287@lucon.org> <3.0.6.32.20000309230751.00a67390@ics.u-strasbg.fr>
X-SW-Source: 2000-03/msg00196.html
Content-length: 7570
On Thu, Mar 09, 2000 at 11:07:51PM +0100, muller@cerbere.u-strasbg.fr wrote:
> >+#ifndef _GDB_REGEX_H
>
> Not that I want to be picky but
> Isn't there a little
> #define _GDB_REGEX_H
> missing here ??
> Otherwise I don't understand anymore
> why all headers are surrounded by ifdefs
>
Ooops. Thanks. Here is a new one.
H.J.
---
2000-03-09 H.J. Lu <hjl@gnu.org>
* gdb_regex.h: New. Include "regex.h" if USE_INCLUDED_REGEX
is defined and <regex.h> otherwise.
* irix5-nat.c: Include "gdb_regex.h" instead of "gnu-regex.h".
* monitor.c: Likewise.
* osfsolib.c: Likewise.
* solib.c: Likewise.
* source.c: Likewise.
* symtab.c: Likewise.
* Makefile.in (REGEX): Changed to @REGEX@.
(REGEX_CFLAGS): New.
(REGEX1): Removed.
(ADD_DEPS): Use $(REGEX) instead of $(REGEX1).
(INTERNAL_WARN_CFLAGS): Add $(REGEX_CFLAGS).
* configure.in (--with-included-regex): New switch.
(REGEX): New. Subsstitue @REGEX@ in Makefile.in.
(REGEX_CFLAGS): New. Subsstitue @REGEX_CFLAGS@ in Makefile.in.
* configure: Regenerated.
Index: irix5-nat.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/irix5-nat.c,v
retrieving revision 1.1.1.3
retrieving revision 1.3
diff -u -p -r1.1.1.3 -r1.3
--- irix5-nat.c 1999/11/19 23:38:46 1.1.1.3
+++ irix5-nat.c 2000/03/08 00:36:03 1.3
@@ -278,7 +278,7 @@ fetch_core_registers (core_reg_sect, cor
#include "objfiles.h"
#include "command.h"
#include "frame.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "inferior.h"
#include "language.h"
#include "gdbcmd.h"
Index: monitor.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/monitor.c,v
retrieving revision 1.1.1.5
retrieving revision 1.3
diff -u -p -r1.1.1.5 -r1.3
--- monitor.c 2000/03/07 18:42:14 1.1.1.5
+++ monitor.c 2000/03/08 00:36:03 1.3
@@ -50,7 +50,7 @@
#include "monitor.h"
#include "gdbcmd.h"
#include "inferior.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "dcache.h"
#include "srec.h"
Index: osfsolib.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/osfsolib.c,v
retrieving revision 1.1.1.3
retrieving revision 1.3
diff -u -p -r1.1.1.3 -r1.3
--- osfsolib.c 1999/11/19 23:38:50 1.1.1.3
+++ osfsolib.c 2000/03/08 00:36:03 1.3
@@ -36,7 +36,7 @@
#include "command.h"
#include "target.h"
#include "frame.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "inferior.h"
#include "language.h"
#include "gdbcmd.h"
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
@@ -49,7 +49,7 @@
#include "command.h"
#include "target.h"
#include "frame.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "inferior.h"
#include "environ.h"
#include "language.h"
Index: source.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/source.c,v
retrieving revision 1.1.1.3
retrieving revision 1.3
diff -u -p -r1.1.1.3 -r1.3
--- source.c 2000/02/04 20:21:58 1.1.1.3
+++ source.c 2000/03/08 00:36:03 1.3
@@ -33,7 +33,7 @@
#include "gdb_stat.h"
#include <fcntl.h>
#include "gdbcore.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "symfile.h"
#include "objfiles.h"
#include "annotate.h"
Index: symtab.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/symtab.c,v
retrieving revision 1.1.1.4
retrieving revision 1.3
diff -u -p -r1.1.1.4 -r1.3
--- symtab.c 2000/03/07 18:42:17 1.1.1.4
+++ symtab.c 2000/03/08 00:36:03 1.3
@@ -30,7 +30,7 @@
#include "objfiles.h"
#include "gdbcmd.h"
#include "call-cmds.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "expression.h"
#include "language.h"
#include "demangle.h"
Index: Makefile.in
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/Makefile.in,v
retrieving revision 1.1.1.9
diff -u -p -r1.1.1.9 Makefile.in
--- Makefile.in 2000/03/07 18:42:08 1.1.1.9
+++ Makefile.in 2000/03/08 23:48:52
@@ -114,6 +114,11 @@ LIBIBERTY = ../libiberty/libiberty.a
MMALLOC = @MMALLOC@
MMALLOC_CFLAGS = @MMALLOC_CFLAGS@
+# We are using our own version of REGEX now to be consistent across
+# machines.
+REGEX = @REGEX@
+REGEX_CFLAGS = @REGEX_CFLAGS@
+
# Where is the BFD library? Typically in ../bfd.
BFD_DIR = ../bfd
BFD = $(BFD_DIR)/libbfd.a
@@ -271,7 +276,8 @@ INTERNAL_WARN_CFLAGS = \
$(CFLAGS) $(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) \
$(GDB_CFLAGS) $(OPCODES_CFLAGS) $(READLINE_CFLAGS) \
$(BFD_CFLAGS) $(MMALLOC_CFLAGS) $(INCLUDE_CFLAGS) \
- $(INTL_CFLAGS) $(TUI_CFLAGS) $(ENABLE_CFLAGS) $(GDB_WARN_CFLAGS)
+ $(INTL_CFLAGS) $(TUI_CFLAGS) $(ENABLE_CFLAGS) \
+ $(REGEX_CFLAGS) $(GDB_WARN_CFLAGS)
INTERNAL_CFLAGS = $(INTERNAL_WARN_CFLAGS) $(GDB_WERROR_CFLAGS)
# LDFLAGS is specifically reserved for setting from the command line
@@ -283,11 +289,6 @@ INTERNAL_CFLAGS = $(INTERNAL_WARN_CFLAGS
INTERNAL_LDFLAGS = $(CFLAGS) $(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) $(LDFLAGS) $(CONFIG_LDFLAGS) @HLDFLAGS@
HLDENV = @HLDENV@
-# We are using our own version of REGEX now to be consistent across
-# machines.
-REGEX = gnu-regex.o
-REGEX1 = gnu-regex.o
-
# If your system is missing alloca(), or, more likely, it's there but
# it doesn't work, then refer to libiberty.
@@ -308,7 +309,7 @@ CDEPS = $(XM_CDEPS) $(TM_CDEPS) $(NAT_CD
$(OPCODES) $(MMALLOC) $(INTL_DEPS) $(LIBIBERTY) $(CONFIG_DEPS)
ADD_FILES = $(REGEX) $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
-ADD_DEPS = $(REGEX1) $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
+ADD_DEPS = $(REGEX) $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
VERSION = 20000204
DIST=gdb
Index: configure.in
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/configure.in,v
retrieving revision 1.1.1.6
diff -u -p -r1.1.1.6 configure.in
--- configure.in 2000/03/07 18:42:10 1.1.1.6
+++ configure.in 2000/03/09 21:50:46
@@ -505,6 +505,36 @@ if test x$want_mmalloc = xtrue; then
MMALLOC='../mmalloc/libmmalloc.a'
fi
+AC_ARG_WITH(included-regex,
+[ --with-included-regex Use included regex],
+[case "${withval}" in
+ yes) want_included_regex=true ;;
+ no) want_included_regex=false;;
+ *) AC_MSG_ERROR(bad value ${withval} for GDB with-included-regex option) ;;
+esac],[want_included_regex=false])dnl
+
+REGEX="gnu-regex.o"
+REGEX_CFLAGS="-DUSE_INCLUDED_REGEX"
+if test $want_included_regex = false; then
+ AC_MSG_CHECKING(for GNU regex)
+ AC_CACHE_VAL(gdb_cv_have_gnu_regex,
+[AC_TRY_COMPILE([#include <gnu-versions.h>
+#include <sys/types.h>
+#include <regex.h>],
+[#if !defined _GNU_REGEX_INTERFACE_VERSION || !defined __GLIBC__ || __GLIBC__ < 2
+#error No valid GNU regex.
+#endif
+],
+ [gdb_cv_have_gnu_regex=yes],
+ [gdb_cv_have_gnu_regex=no])])
+ AC_MSG_RESULT($gdb_cv_have_gnu_regex)
+ if test $gdb_cv_have_gnu_regex = yes; then
+ REGEX=
+ REGEX_CFLAGS=
+ fi
+fi
+AC_SUBST(REGEX)
+AC_SUBST(REGEX_CFLAGS)
# In the Cygwin environment, we need some additional flags.
AC_CACHE_CHECK([for cygwin], gdb_cv_os_cygwin,
--- /dev/null Tue May 5 13:32:27 1998
+++ gdb_regex.h Thu Mar 9 14:06:44 2000
@@ -0,0 +1,8 @@
+#ifndef _GDB_REGEX_H
+#define _GDB_REGEX_H
+#ifdef USE_INCLUDED_REGEX
+#include "gnu-regex.h"
+#else
+#include <regex.h>
+#endif
+#endif /* _GDB_REGEX_H */
From ezannoni@cygnus.com Thu Mar 09 15:01:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Mini patch
Date: Thu, 09 Mar 2000 15:01:00 -0000
Message-id: <14536.11577.901730.689173@kwikemart.cygnus.com>
X-SW-Source: 2000-03/msg00197.html
Content-length: 1290
I just checked this in.
Elena
Index: minsyms.c
===================================================================
RCS file: /cvs/src/src/gdb/minsyms.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -c -r1.2 -r1.3
*** minsyms.c 2000/03/07 04:33:52 1.2
--- minsyms.c 2000/03/09 22:58:49 1.3
***************
*** 667,672 ****
--- 667,674 ----
/* FIXME: This info, if it remains, needs its own field. */
MSYMBOL_INFO (msymbol) = info; /* FIXME! */
+ /* The hash pointers must be cleared! If they're not,
+ MSYMBOL_HASH_ADD will NOT add this msymbol to the hash table. */
msymbol->hash_next = NULL;
msymbol->demangled_hash_next = NULL;
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.120
retrieving revision 1.121
diff -c -r1.120 -r1.121
*** ChangeLog 2000/03/09 21:55:39 1.120
--- ChangeLog 2000/03/09 22:58:49 1.121
***************
*** 1,3 ****
--- 1,7 ----
+ 2000-03-06 Elena Zannoni <ezannoni@kwikemart.cygnus.com>
+
+ * minsyms.c (prim_record_minimal_symbol_and_info): Add comment.
+
2000-02-25 Scott Bambrough <scottb@netwinder.org>
* gdb.base/long_long.exp: Correct test suite failure when printing
From kingdon@redhat.com Thu Mar 09 15:23:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE
Cc: kevinb@cygnus.com, Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: solib.c: Clean fix to get rid of severe Solaris 2.7 sparc regressions
Date: Thu, 09 Mar 2000 15:23:00 -0000
Message-id: <200003092322.SAA01952@devserv.devel.redhat.com>
References: <200003090940.KAA32291@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-03/msg00198.html
Content-length: 124
> Good idea, thanks. Here is a revised patch which gets rid of all
> CORE_ADDR pointer casts in solib.c.
Looks good to me.
From ac131313@cygnus.com Thu Mar 09 16:52:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [MAINT] Devolve responsibilities
Date: Thu, 09 Mar 2000 16:52:00 -0000
Message-id: <38C84733.C86136C9@cygnus.com>
X-SW-Source: 2000-03/msg00199.html
Content-length: 1579
Just to close this, I've committed the attatched.
Andrew
Fri Mar 10 11:44:55 2000 Andrew Cagney <cagney@b1.cygnus.com>
* MAINTAINERS: Devolve responsibility for domain maintenance.
Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.22
diff -p -r1.22 MAINTAINERS
*** MAINTAINERS 2000/03/09 03:32:09 1.22
--- MAINTAINERS 2000/03/10 00:41:50
*************** Peter Schauer Peter.Schauer@regent.e-t
*** 14,27 ****
Note individuals who maintain parts of the debugger need approval to
check in changes outside of the immediate domain that they maintain.
! If there is no maintainer for a given domain then the problem falls to
! the head maintainer.
! If there are several maintainers for a given domain then the problem
! falls to the first maintainer. The second and third maintainers are
! firstly known to have expertise in the given domain and secondly are
! available to step in if the first maintainer is to be absent for any
! reason.
Target/Architecture:
--- 14,25 ----
Note individuals who maintain parts of the debugger need approval to
check in changes outside of the immediate domain that they maintain.
! If there is no maintainer for a given domain then the responsibility
! falls to the head maintainer.
! If there are several maintainers for a given domain then
! responsibility falls to the first maintainer. The first maintainer is
! free to devolve that responsibility among the other maintainers.
Target/Architecture:
From eliz@delorie.com Fri Mar 10 05:47:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] GDB command-line switches and annotations docs
Date: Fri, 10 Mar 2000 05:47:00 -0000
Message-id: <200003101347.IAA21898@indy.delorie.com>
X-SW-Source: 2000-03/msg00200.html
Content-length: 25252
Here are patches to gdb.texinfo and annotate.texi which add indexing
to command-line switches, document some switches that were not in the
manual, and make annotate.texi part of GDB manual.
(Are there plans to make gdbmi.texi be part of the manual as well?)
--- gdb/doc/gdb.t~0 Tue Jan 18 03:15:04 2000
+++ gdb/doc/gdb.texinfo Fri Mar 10 15:27:42 2000
@@ -153,6 +153,7 @@
* Command Line Editing:: Command Line Editing
* Using History Interactively:: Using History Interactively
* Installing GDB:: Installing GDB
+* Annotations:: @value{GDBN}'s annotations interface.
* Index:: Index
@end menu
@@ -749,22 +750,34 @@
(If you prefer, you can flag option arguments with @samp{--} rather
than @samp{-}, though we illustrate the more usual convention.)
+@c NOTE: the @cindex entries here use double dashes (actually, triple
+@c dashes, but that's because of makeinfo formatting of indices) ON
+@c PURPOSE. This way, both those who look for -foo and --foo in the
+@c index, will find it.
+
@table @code
@item -symbols @var{file}
@itemx -s @var{file}
+@cindex ---symbols
+@cindex -s
Read symbol table from file @var{file}.
@item -exec @var{file}
@itemx -e @var{file}
+@cindex ---exec
+@cindex -e
Use file @var{file} as the executable file to execute when appropriate,
and for examining pure data in conjunction with a core dump.
@item -se @var{file}
+@cindex ---se
Read symbol table from file @var{file} and use it as the executable
file.
@item -core @var{file}
@itemx -c @var{file}
+@cindex ---core
+@cindex -c
Use file @var{file} as a core dump to examine.
@item -c @var{number}
@@ -774,15 +787,21 @@
@item -command @var{file}
@itemx -x @var{file}
+@cindex ---command
+@cindex -x
Execute @value{GDBN} commands from file @var{file}. @xref{Command
Files,, Command files}.
@item -directory @var{directory}
@itemx -d @var{directory}
+@cindex ---directory
+@cindex -d
Add @var{directory} to the path to search for source files.
@item -m
@itemx -mapped
+@cindex ---mapped
+@cindex -m
@emph{Warning: this option depends on operating system facilities that are not
supported on all systems.}@*
If memory-mapped files are available on your system through the @code{mmap}
@@ -800,6 +819,8 @@
@item -r
@itemx -readnow
+@cindex ---readnow
+@cindex -r
Read each symbol file's entire symbol table immediately, rather than
the default, which is to read it incrementally as it is needed.
This makes startup slower, but makes future operations faster.
@@ -825,6 +846,8 @@
@table @code
@item -nx
@itemx -n
+@cindex ---nx
+@cindex -n
Do not execute commands found in any initialization files (normally
called @file{.gdbinit}, or @file{gdb.ini} on PCs). Normally,
@value{GDBN} executes the commands in these files after all the command
@@ -832,11 +855,16 @@
files}.
@item -quiet
+@itemx -silent
@itemx -q
+@cindex ---quite
+@cindex ---silent
+@cindex -q
``Quiet''. Do not print the introductory and copyright messages. These
messages are also suppressed in batch mode.
@item -batch
+@cindex ---batch
Run in batch mode. Exit with status @code{0} after processing all the
command files specified with @samp{-x} (and all commands from
initialization files, if not inhibited with @samp{-n}). Exit with
@@ -858,21 +886,28 @@
@item -nowindows
@itemx -nw
+@cindex ---nowindows
+@cindex -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
interface. If no GUI is available, this option has no effect.
@item -windows
@itemx -w
+@cindex ---windows
+@cindex -w
If @value{GDBN} includes a GUI, then this option requires it to be
used if possible.
@item -cd @var{directory}
+@cindex ---cd
Run @value{GDBN} using @var{directory} as its working directory,
instead of the current directory.
@item -fullname
@itemx -f
+@cindex ---fullname
+@cindex -f
@sc{gnu} Emacs sets this option when it runs @value{GDBN} as a
subprocess. It tells @value{GDBN} to output the full file name and line
number in a standard, recognizable fashion each time a stack frame is
@@ -883,17 +918,60 @@
@samp{\032} characters as a signal to display the source code for the
frame.
+@item -epoch
+@cindex ---epoch
+The Epoch Emacs-@value{GDBN} interface sets this option when it runs
+@value{GDBN} as a subprocess. It tells @value{GDBN} to modify its print
+routines so as to allow Epoch to display values of expressions in a
+separate window.
+
+@item -annotate @var{level}
+@cindex ---annotate
+This option sets the @dfn{annotation level} inside @value{GDBN}. Its
+effect is identical to using @samp{set annotate @var{level}}
+(@pxref{Annotations}).
+Annotation level controls how much information does @value{GDBN} print
+together with its prompt, values of expressions, source lines, and other
+types of output. Level 0 is the normal, level 1 is for use when
+@value{GDBN} is run as a subprocess of @sc{gnu} Emacs, level 2 is the
+maximum annotation suitable for programs that control @value{GDBN}.
+
+@item -async
+@cindex ---async
+Use the asynchronous event loop for the command-line interface.
+@value{GDBN} processes all events, such as user keyboard input, via a
+special event loop. This allows @value{GDBN} to accept and process user
+commands in parallel with the debugged process being
+run@footnote{@value{GDBN} built with @sc{djgpp} tools for
+MS-DOS/MS-Windows supports this mode of operation, but the event loop is
+suspended when the debuggee runs.}, so you don't need to wait for
+control to return to @value{GDBN} before you type the next command.
+
+When the standard input is connected to a terminal device, @value{GDBN}
+uses the asynchronous event loop by default, unless disabled by the
+@samp{-noasync} option.
+
+@item -noasync
+@cindex ---noasync
+Disable the asynchronous event loop for the command-line interface.
+
@item -baud @var{bps}
@itemx -b @var{bps}
+@cindex ---baud
+@cindex -b
Set the line speed (baud rate or bits per second) of any serial
interface used by @value{GDBN} for remote debugging.
@item -tty @var{device}
+@itemx -t @var{device}
+@cindex ---tty
+@cindex -t
Run using @var{device} for your program's standard input and output.
@c FIXME: kingdon thinks there is more to -tty. Investigate.
@c resolve the situation of these eventually
@c @item -tui
+@c @cindex ---tui
@c Use a Terminal User Interface. For information, use your Web browser to
@c read the file @file{TUI.html}, which is usually installed in the
@c directory @code{/opt/langtools/wdb/doc} on HP-UX systems. Do not use
@@ -901,11 +979,38 @@
@c @value{GDBN} under @sc{gnu} Emacs}).
@c @item -xdb
+@c @cindex ---xdb
@c Run in XDB compatibility mode, allowing the use of certain XDB commands.
@c For information, see the file @file{xdb_trans.html}, which is usually
@c installed in the directory @code{/opt/langtools/wdb/doc} on HP-UX
@c systems.
+@item -interpreter @var{interp}
+@cindex ---interpreter
+Use the interpreter @var{interp} for interface with the controlling
+program or device. This option is meant to be set by programs which
+communicate with @value{GDBN} using it as a back end. For example,
+@samp{--interpreter=mi} causes @value{GDBN} to use the @dfn{gdbmi
+interface}.
+@c FIXME: There should be an @xref here to the GDB/MI docs, but
+@c gdbmi.texi doesn't have a single node to reference!
+
+@item -write
+@cindex ---write
+Open the executable and core files for both reading and writing. This
+is equivalent to the @samp{set write on} command inside @value{GDBN}
+(@pxref{Patching}).
+
+@item -statistics
+@cindex ---statistics
+This option causes @value{GDBN} to print statistics about time and
+memory usage after it completes each command and returns to the prompt.
+
+@item -version
+@cindex ---version
+This option causes @value{GDBN} to print its version number and
+no-warranty blurb, and exit.
+
@end table
@node Quitting GDB
@@ -12488,6 +12593,8 @@
There are many other options available as well, but they are generally
needed for special purposes only.
+
+@include annotate.texi
@node Index
@unnumbered Index
--- gdb/doc/annotate.t~0 Fri Apr 16 03:54:46 1999
+++ gdb/doc/annotate.texi Fri Mar 10 11:53:06 2000
@@ -1,85 +1,93 @@
-\input texinfo @c -*-texinfo-*-
-@c %**start of header
-@setfilename annotate.info
-@settitle GDB Annotations
-@setchapternewpage off
-@c %**end of header
-
-@set EDITION 0.5
-@set DATE May 1994
-
-@ifinfo
-This file documents GDB annotations.
-
-This is Edition @value{EDITION}, @value{DATE}, of @cite{GDB
-Annotations}. Copyright 1994 Free Software Foundation
-
-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.
-
-@ignore
-Permission is granted to process this file through TeX and print the
-results, provided the printed document carries copying permission
-notice identical to this one except for the removal of this paragraph
-(this paragraph not being relevant to the printed manual).
-
-@end ignore
-Permission is granted to copy and distribute modified versions of this
-manual under the conditions for verbatim copying, provided also that the
-entire resulting derived work is distributed under the terms of a
-permission notice identical to this one.
-
-Permission is granted to copy and distribute translations of this manual
-into another language, under the above conditions for modified versions.
-@end ifinfo
-
-@titlepage
-@title GDB Annotations
-@subtitle Edition @value{EDITION}
-@subtitle @value{DATE}
-@author Cygnus Support
-@page
-@vskip 0pt plus 1filll
-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.
-
-Copyright @copyright{} 1994 Free Software Foundation
-@end titlepage
-
-@ifinfo
-@node Top
-@top GDB Annotations
-
-This file describes annotations in GDB, the GNU symbolic debugger.
-Annotations are designed to interface GDB to graphical user interfaces
-or other similar programs which want to interact with GDB at a
+@c \input texinfo @c -*-texinfo-*-
+@c @c %**start of header
+@c @setfilename annotate.info
+@c @settitle GDB Annotations
+@c @setchapternewpage off
+@c @c %**end of header
+
+@c @set EDITION 0.5
+@c @set DATE May 1994
+
+@c @ifinfo
+@c This file documents GDB annotations.
+
+@c This is Edition @value{EDITION}, @value{DATE}, of @cite{GDB
+@c Annotations}. Copyright 1994 Free Software Foundation
+
+@c Permission is granted to make and distribute verbatim copies of
+@c this manual provided the copyright notice and this permission notice
+@c are preserved on all copies.
+@c @end ignore
+
+@c @ignore
+@c Permission is granted to process this file through TeX and print the
+@c results, provided the printed document carries copying permission
+@c notice identical to this one except for the removal of this paragraph
+@c (this paragraph not being relevant to the printed manual).
+
+@c @end ignore
+@c Permission is granted to copy and distribute modified versions of this
+@c manual under the conditions for verbatim copying, provided also that the
+@c entire resulting derived work is distributed under the terms of a
+@c permission notice identical to this one.
+
+@c Permission is granted to copy and distribute translations of this manual
+@c into another language, under the above conditions for modified versions.
+@c @end ifinfo
+
+@c @titlepage
+@c @title GDB Annotations
+@c @subtitle Edition @value{EDITION}
+@c @subtitle @value{DATE}
+@c @author Cygnus Support
+@c @page
+@c @vskip 0pt plus 1filll
+@c Permission is granted to make and distribute verbatim copies of
+@c this manual provided the copyright notice and this permission notice
+@c are preserved on all copies.
+
+@c Copyright @copyright{} 1994 Free Software Foundation
+@c @end titlepage
+
+@c @ifinfo
+@c @node Top
+@c @top GDB Annotations
+
+@syncodeindex fn cp
+
+@node Annotations
+@chapter @value{GDBN} Annotations
+
+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
This is Edition @value{EDITION}, @value{DATE}.
+@end ignore
@menu
-* General:: What annotations are; the general syntax.
-* Server:: Issuing a command without affecting user state.
-* Values:: Values are marked as such.
-* Frames:: Stack frames are annotated.
-* Displays:: GDB can be told to display something periodically.
-* Prompting:: Annotations marking GDB's need for input.
+* Annotations Overview:: What annotations are; the general syntax.
+* Server Prefix:: Issuing a command without affecting user state.
+* Value Annotations:: Values are marked as such.
+* Frame Annotations:: Stack frames are annotated.
+* Displays:: @value{GDBN} can be told to display something periodically.
+* Prompting:: Annotations marking @value{GDBN}'s need for input.
* Errors:: Annotations for error messages.
* Breakpoint Info:: Information on breakpoints.
* Invalidation:: Some annotations describe things now invalid.
-* Running:: Whether the program is running, how it stopped, etc.
-* Source:: Annotations describing source code.
+* Annotations for Running::
+ Whether the program is running, how it stopped, etc.
+* Source Annotations:: Annotations describing source code.
* TODO:: Annotations which might be added in the future.
-* Index:: Index
@end menu
-@end ifinfo
-@node General
-@chapter What is an Annotation?
+@node Annotations Overview
+@section What is an Annotation?
+@cindex annotations
-To produce annotations, start GDB with the @code{--annotate=2} option.
+To produce annotations, start @value{GDBN} with the @code{--annotate=2} option.
Annotations start with a newline character, two @samp{control-z}
characters, and the name of the annotation. If there is no additional
@@ -90,20 +98,22 @@
cannot contain newline characters.
Any output not beginning with a newline and two @samp{control-z}
-characters denotes literal output from GDB. Currently there is no need
-for GDB to output a newline followed by two @samp{control-z} characters,
+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 GDB with annotations is:
+A simple example of starting up @value{GDBN} with annotations is:
-@example
+@smallexample
$ gdb --annotate=2
-GDB is free software and you are welcome to 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.
-GDB 4.12.3 (sparc-sun-sunos4.1.3),
-Copyright 1994 Free Software Foundation, Inc.
+GNU GDB 5.0
+Copyright 1998 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
(gdb)
@@ -112,29 +122,31 @@
^Z^Zpost-prompt
$
-@end example
+@end smallexample
-Here @samp{quit} is input to GDB; the rest is output from GDB. The three
+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 GDB.
+character) are annotations; the rest is output from @value{GDBN}.
-@node Server
-@chapter The Server Prefix
+@node Server Prefix
+@section The Server Prefix
+@cindex server prefix for annotations
-To issue a command to GDB without affecting certain aspects of the state
+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
-GDB's notion of which command to repeat if @key{RET} is pressed on a
+@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 the @code{print} command.
-@node Values
-@chapter Values
+@node Value Annotations
+@section Values
-When a value is printed in various contexts, GDB uses annotations to
+@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
@@ -172,7 +184,7 @@
@findex arg-name-end
@findex arg-value
@findex arg-end
-When GDB prints an argument to a function (for example, in the output
+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
@@ -195,7 +207,7 @@
@findex field-name-end
@findex field-value
@findex field-end
-When printing a structure, GDB annotates it as follows:
+When printing a structure, @value{GDBN} annotates it as follows:
@example
^Z^Zfield-begin @var{value-flags}
@@ -212,7 +224,7 @@
(such as @samp{=}), and @var{value-flags} and @var{the-value} have the
same meanings as in a @code{value-history-begin} annotation.
-When printing an array, GDB annotates it as follows:
+When printing an array, @value{GDBN} annotates it as follows:
@example
^Z^Zarray-section-begin @var{array-index} @var{value-flags}
@@ -257,11 +269,12 @@
^Z^Zarray-section-end
@end example
-@node Frames
-@chapter Frames
+@node Frame Annotations
+@section Frames
-Whenever GDB prints a frame, it annotates it. For example, this applies
-to frames printed when GDB stops, output from commands such as
+@cindex annotations for frames
+Whenever @value{GDBN} prints a frame, it annotates it. For example, this applies
+to frames printed when @value{GDBN} stops, output from commands such as
@code{backtrace} or @code{up}, etc.
@findex frame-begin
@@ -296,7 +309,7 @@
@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 GDB to a
+that this frame is associated with a function call made by @value{GDBN} to a
function in the program being debugged.
@item
@@ -347,7 +360,7 @@
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
to the frame, with parentheses around them (each argument is annotated
-individually as well @pxref{Values}).
+individually as well, @pxref{Value Annotations}).
@findex frame-source-begin
@findex frame-source-file
@@ -374,7 +387,7 @@
file (the first line is line 1).
@findex frame-where
-If GDB prints some information about where the frame is from (which
+If @value{GDBN} prints some information about where the frame is from (which
library, which load segment, etc.; currently only done on the RS/6000),
it is annotated with
@@ -391,7 +404,7 @@
@end itemize
@node Displays
-@chapter Displays
+@section Displays
@findex display-begin
@findex display-number-end
@@ -400,7 +413,8 @@
@findex display-expression-end
@findex display-value
@findex display-end
-When GDB is told to display something using the @code{display} command,
+@cindex annotations for display
+When @value{GDBN} is told to display something using the @code{display} command,
the results of the display are annotated:
@example
@@ -428,9 +442,10 @@
and @var{value} is the actual value being displayed.
@node Prompting
-@chapter Annotation for GDB Input
+@section Annotation for @value{GDBN} Input
-When GDB prompts for input, it annotates this fact so it is possible
+@cindex annotations for prompts
+When @value{GDBN} prompts for input, it annotates this fact so it is possible
to know when to send output, when the output from a given command is
over, etc.
@@ -455,60 +470,61 @@
@findex prompt
@findex post-prompt
@item prompt
-When GDB is prompting for a command (the main GDB prompt).
+When @value{GDBN} is prompting for a command (the main @value{GDBN} prompt).
@findex pre-commands
@findex commands
@findex post-commands
@item commands
-When GDB prompts for a set of commands, like in the @code{commands}
+When @value{GDBN} prompts for a set of commands, like in the @code{commands}
command. The annotations are repeated for each command which is input.
@findex pre-overload-choice
@findex overload-choice
@findex post-overload-choice
@item overload-choice
-When GDB wants the user to select between various overloaded functions.
+When @value{GDBN} wants the user to select between various overloaded functions.
@findex pre-query
@findex query
@findex post-query
@item query
-When GDB wants the user to confirm a potentially dangerous operation.
+When @value{GDBN} wants the user to confirm a potentially dangerous operation.
@findex pre-prompt-for-continue
@findex prompt-for-continue
@findex post-prompt-for-continue
@item prompt-for-continue
-When GDB is asking the user to press return to continue. Note: Don't
+When @value{GDBN} is asking the user to press return to continue. Note: Don't
expect this to work well; instead use @code{set height 0} to disable
prompting. This is because the counting of lines is buggy in the
presence of annotations.
@end table
@node Errors
-@chapter Errors
+@section Errors
+@cindex annotations for errors, warnings and interrupts
@findex quit
@example
^Z^Zquit
@end example
-This annotation occurs right before GDB responds to an interrupt.
+This annotation occurs right before @value{GDBN} responds to an interrupt.
@findex error
@example
^Z^Zerror
@end example
-This annotation occurs right before GDB responds to an error.
+This annotation occurs right before @value{GDBN} responds to an error.
-Quit and error annotations indicate that any annotations which GDB was
+Quit and error annotations indicate that any annotations which @value{GDBN} was
in the middle of may end abruptly. For example, if a
@code{value-history-begin} annotation is followed by a @code{error}, one
cannot expect to receive the matching @code{value-history-end}. One
cannot expect not to receive it either, however; an error annotation
-does not necessarily mean that GDB is immediately returning all the way
+does not necessarily mean that @value{GDBN} is immediately returning all the way
to the top level.
@findex error-begin
@@ -526,8 +542,9 @@
@c range_error(), and possibly other places.
@node Breakpoint Info
-@chapter Information on Breakpoints
+@section Information on Breakpoints
+@cindex annotations for breakpoints
The output from the @code{info breakpoints} command is annotated as follows:
@findex breakpoints-headers
@@ -582,8 +599,9 @@
@end example
@node Invalidation
-@chapter Invalidation Notices
+@section Invalidation Notices
+@cindex annotations for invalidation messages
The following annotations say that certain pieces of state may have
changed.
@@ -601,12 +619,13 @@
deleted a breakpoint.
@end table
-@node Running
-@chapter Running the Program
+@node Annotations for Running
+@section Running the Program
+@cindex annotations for running programs
@findex starting
@findex stopping
-When the program starts executing due to a GDB command such as
+When the program starts executing due to a @value{GDBN} command such as
@code{step} or @code{continue},
@example
@@ -657,7 +676,7 @@
@findex signal
@item ^Z^Zsignal
-The syntax of this annotation is just like @code{signalled}, but GDB is
+The syntax of this annotation is just like @code{signalled}, but @value{GDBN} is
just saying that the program received the signal, not that it was
terminated with it.
@@ -670,8 +689,9 @@
The program hit watchpoint number @var{number}.
@end table
-@node Source
-@chapter Displaying Source
+@node Source Annotations
+@section Displaying Source
+@cindex annotations for source display
@findex source
The following annotation is used instead of displaying source code:
@@ -693,7 +713,7 @@
depend on the language).
@node TODO
-@chapter Annotations We Might Want in the Future
+@section Annotations We Might Want in the Future
@format
- target-invalid
@@ -709,9 +729,11 @@
notices.
@end format
+@ignore
@node Index
@unnumbered Index
@printindex fn
+@end ignore
-@bye
+@c @bye
From kingdon@redhat.com Fri Mar 10 06:16:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] GDB command-line switches and annotations docs
Date: Fri, 10 Mar 2000 06:16:00 -0000
Message-id: <bwvnauczt.fsf@rtl.cygnus.com>
References: <200003101347.IAA21898@indy.delorie.com>
X-SW-Source: 2000-03/msg00201.html
Content-length: 508
> +@c NOTE: the @cindex entries here use double dashes (actually, triple
> +@c dashes, but that's because of makeinfo formatting of indices) ON
The way to handle the makeinfo formatting issue is "@cindex
@code{--test}" rather than "@cindex ---test"; the latter is an em dash
in the printed manual rather than two "-" characters. I just tried
the former in both info and TeX and it seems to do the right thing.
> +@cindex ---quite
Typo ("quite" should be "quiet").
Other than that I didn't see problems.
From ezannoni@cygnus.com Fri Mar 10 07:24:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] GDB command-line switches and annotations docs
Date: Fri, 10 Mar 2000 07:24:00 -0000
Message-id: <14537.5048.99180.910863@kwikemart.cygnus.com>
References: <200003101347.IAA21898@indy.delorie.com>
X-SW-Source: 2000-03/msg00202.html
Content-length: 2075
Eli Zaretskii writes:
>
> Here are patches to gdb.texinfo and annotate.texi which add indexing
> to command-line switches, document some switches that were not in the
> manual, and make annotate.texi part of GDB manual.
>
> (Are there plans to make gdbmi.texi be part of the manual as well?)
>
Eventually yes (Andrew?), right now it is not in prime time form yet. It is
still very rough work in progress.
> +
> +@item -async
> +@cindex ---async
> +Use the asynchronous event loop for the command-line interface.
> +@value{GDBN} processes all events, such as user keyboard input, via a
> +special event loop. This allows @value{GDBN} to accept and process user
> +commands in parallel with the debugged process being
> +run@footnote{@value{GDBN} built with @sc{djgpp} tools for
> +MS-DOS/MS-Windows supports this mode of operation, but the event loop is
> +suspended when the debuggee runs.}, so you don't need to wait for
> +control to return to @value{GDBN} before you type the next command.
> +
> +When the standard input is connected to a terminal device, @value{GDBN}
> +uses the asynchronous event loop by default, unless disabled by the
> +@samp{-noasync} option.
> +
> +@item -noasync
> +@cindex ---noasync
> +Disable the asynchronous event loop for the command-line interface.
> +
I was planning on removing the -async option, it is now redundant.
Maybe I should just go ahead and do it now.
The --noasync stays there for the moment but my hope is that it will
eventually not be necessary anymore. As far as the footnote goes,
that behavior is what you get in all the platforms and configurations
at the moment not just djgpp. The target side is not hooked up to the
event loop yet (except for a 'clone' of the remote target, called
'async'). So I would modify the above entry to specify that the event
loop right now involves only user events, not target ones. Eventually
it will deal with target side too, but each target needs to be
converted. The behavior you describe is the ultimate goal, we are only
about 50% there.
Elena
From scottb@netwinder.org Fri Mar 10 07:47:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: Michael Snyder <msnyder@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: store_floating() and arm-tdep.c
Date: Fri, 10 Mar 2000 07:47:00 -0000
Message-id: <38C917C1.3E6E2C19@netwinder.org>
References: <1000229000345.ZM15006@ocotillo.lan> <38BCE46B.CD7889B5@cygnus.com> <1000302074643.ZM19182@ocotillo.lan> <38C7BF53.731F8CF6@redhat.com> <38C7C9A4.3566EC87@netwinder.org> <38C7F23D.61AF@cygnus.com>
X-SW-Source: 2000-03/msg00203.html
Content-length: 1429
> Scott Bambrough wrote:
> >
> > 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.
>
Michael Snyder wrote:
>
> Hmm, the new thread_db module should be pretty
> target-independent (correct me if I'm wrong).
Ok. I attempted to put the linuxthreads support in last night. It was
relatively painless, but I have reached a stumbling block with glibc 2.1.2. In
gdb_proc_service.h there are the following two definitions:
#ifndef HAVE_PRGREGSET_T
typedef gregset_t prgregset_t; /* BOGUS BOGUS BOGUS */
#endif
#ifndef HAVE_PRFPREGSET_T
typedef fpregset_t prfpregset_t; /* BOGUS BOGUS BOGUS */
#endif
The BOGUS comments are accurate. Neither gregset_t or fpregset_t are defined in
<sys/procfs.h>. prgregset_t and prfpregset_t are also used in gdb_threads_db.h
as well without checking the defines from config.h. I'm trying this on 2.1.3
ATM, but for the most part, the installed base of users is using 2.1.2 on ARM
Linux. Any thoughts on how I could get around this?
Scott
--
Scott Bambrough - Software Engineer
REBEL.COM http://www.rebel.com
NetWinder http://www.netwinder.org
From cgf@cygnus.com Fri Mar 10 09:31:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [robert.melchers@drives.eurotherm.co.uk: set architecture sh2, causes core dump on latest build 20000305.]
Date: Fri, 10 Mar 2000 09:31:00 -0000
Message-id: <20000310123052.I7903@cygnus.com>
X-SW-Source: 2000-03/msg00204.html
Content-length: 1309
This was sent to the insight mailing list. Does it look correct?
cgf
----- Forwarded message from Robert <robert.melchers@drives.eurotherm.co.uk> -----
From: "Robert" <robert.melchers@drives.eurotherm.co.uk>
To: <insight@sourceware.cygnus.com>
Subject: set architecture sh2, causes core dump on latest build 20000305.
Date: Fri, 10 Mar 2000 10:09:12 -0000
Importance: Normal
With GNU gdb 20000305 "--host=i686-pc-cygwin --target=sh-coff" the command "set architecture sh2",
causes a core dump.
I believe it is because the sh_processor_type_table[] in sh-tdep.c does not include an entry for the
sh2. Adding an entry fixes the problem.
The sh1 and sh2 processors share the same register names.
The following snippet shows the necessary changes.
Robert.
*** sh-tdep.bak Thu Feb 24 03:31:45 2000
--- sh-tdep.c Thu Mar 09 17:10:05 2000
***************
*** 102,115 ****
--- 102,119 ----
sh_processor_type_table[] =
{
{
sh_reg_names, bfd_mach_sh
}
,
{
+ sh_reg_names, bfd_mach_sh2
+ }
+ ,
+ {
sh3_reg_names, bfd_mach_sh3
}
,
{
sh3e_reg_names, bfd_mach_sh3e
}
,
----- End forwarded message -----
--
cgf@cygnus.com Cygnus Solutions, a Red Hat company
http://sourcware.cygnus.com/ http://www.redhat.com/
From eliz@delorie.com Fri Mar 10 09:43:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kingdon@redhat.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] GDB command-line switches and annotations docs
Date: Fri, 10 Mar 2000 09:43:00 -0000
Message-id: <200003101742.MAA22063@indy.delorie.com>
References: <200003101347.IAA21898@indy.delorie.com> <bwvnauczt.fsf@rtl.cygnus.com>
X-SW-Source: 2000-03/msg00205.html
Content-length: 25651
> > +@c NOTE: the @cindex entries here use double dashes (actually, triple
> > +@c dashes, but that's because of makeinfo formatting of indices) ON
>
> The way to handle the makeinfo formatting issue is "@cindex
> @code{--test}" rather than "@cindex ---test"; the latter is an em dash
> in the printed manual rather than two "-" characters.
Here are the revised changes. I converted all the "@cindex -x"
entries to the "@cindex @code{-x}" as well, for typeface uniformity.
--- gdb/doc/gdb.t~0 Tue Jan 18 03:15:04 2000
+++ gdb/doc/gdb.texinfo Fri Mar 10 16:39:30 2000
@@ -153,6 +153,7 @@
* Command Line Editing:: Command Line Editing
* Using History Interactively:: Using History Interactively
* Installing GDB:: Installing GDB
+* Annotations:: @value{GDBN}'s annotations interface.
* Index:: Index
@end menu
@@ -749,22 +750,33 @@
(If you prefer, you can flag option arguments with @samp{--} rather
than @samp{-}, though we illustrate the more usual convention.)
+@c NOTE: the @cindex entries here use double dashes ON PURPOSE. This
+@c way, both those who look for -foo and --foo in the index, will find
+@c it.
+
@table @code
@item -symbols @var{file}
@itemx -s @var{file}
+@cindex @code{--symbols}
+@cindex @code{-s}
Read symbol table from file @var{file}.
@item -exec @var{file}
@itemx -e @var{file}
+@cindex @code{--exec}
+@cindex @code{-e}
Use file @var{file} as the executable file to execute when appropriate,
and for examining pure data in conjunction with a core dump.
@item -se @var{file}
+@cindex @code{--se}
Read symbol table from file @var{file} and use it as the executable
file.
@item -core @var{file}
@itemx -c @var{file}
+@cindex @code{--core}
+@cindex @code{-c}
Use file @var{file} as a core dump to examine.
@item -c @var{number}
@@ -774,15 +786,21 @@
@item -command @var{file}
@itemx -x @var{file}
+@cindex @code{--command}
+@cindex @code{-x}
Execute @value{GDBN} commands from file @var{file}. @xref{Command
Files,, Command files}.
@item -directory @var{directory}
@itemx -d @var{directory}
+@cindex @code{--directory}
+@cindex @code{-d}
Add @var{directory} to the path to search for source files.
@item -m
@itemx -mapped
+@cindex @code{--mapped}
+@cindex @code{-m}
@emph{Warning: this option depends on operating system facilities that are not
supported on all systems.}@*
If memory-mapped files are available on your system through the @code{mmap}
@@ -800,6 +818,8 @@
@item -r
@itemx -readnow
+@cindex @code{--readnow}
+@cindex @code{-r}
Read each symbol file's entire symbol table immediately, rather than
the default, which is to read it incrementally as it is needed.
This makes startup slower, but makes future operations faster.
@@ -825,6 +845,8 @@
@table @code
@item -nx
@itemx -n
+@cindex @code{--nx}
+@cindex @code{-n}
Do not execute commands found in any initialization files (normally
called @file{.gdbinit}, or @file{gdb.ini} on PCs). Normally,
@value{GDBN} executes the commands in these files after all the command
@@ -832,11 +854,16 @@
files}.
@item -quiet
+@itemx -silent
@itemx -q
+@cindex @code{--quiet}
+@cindex @code{--silent}
+@cindex @code{-q}
``Quiet''. Do not print the introductory and copyright messages. These
messages are also suppressed in batch mode.
@item -batch
+@cindex @code{--batch}
Run in batch mode. Exit with status @code{0} after processing all the
command files specified with @samp{-x} (and all commands from
initialization files, if not inhibited with @samp{-n}). Exit with
@@ -858,21 +885,28 @@
@item -nowindows
@itemx -nw
+@cindex @code{--nowindows}
+@cindex @code{-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
interface. If no GUI is available, this option has no effect.
@item -windows
@itemx -w
+@cindex @code{--windows}
+@cindex @code{-w}
If @value{GDBN} includes a GUI, then this option requires it to be
used if possible.
@item -cd @var{directory}
+@cindex @code{--cd}
Run @value{GDBN} using @var{directory} as its working directory,
instead of the current directory.
@item -fullname
@itemx -f
+@cindex @code{--fullname}
+@cindex @code{-f}
@sc{gnu} Emacs sets this option when it runs @value{GDBN} as a
subprocess. It tells @value{GDBN} to output the full file name and line
number in a standard, recognizable fashion each time a stack frame is
@@ -883,17 +917,60 @@
@samp{\032} characters as a signal to display the source code for the
frame.
+@item -epoch
+@cindex @code{--epoch}
+The Epoch Emacs-@value{GDBN} interface sets this option when it runs
+@value{GDBN} as a subprocess. It tells @value{GDBN} to modify its print
+routines so as to allow Epoch to display values of expressions in a
+separate window.
+
+@item -annotate @var{level}
+@cindex @code{--annotate}
+This option sets the @dfn{annotation level} inside @value{GDBN}. Its
+effect is identical to using @samp{set annotate @var{level}}
+(@pxref{Annotations}).
+Annotation level controls how much information does @value{GDBN} print
+together with its prompt, values of expressions, source lines, and other
+types of output. Level 0 is the normal, level 1 is for use when
+@value{GDBN} is run as a subprocess of @sc{gnu} Emacs, level 2 is the
+maximum annotation suitable for programs that control @value{GDBN}.
+
+@item -async
+@cindex @code{--async}
+Use the asynchronous event loop for the command-line interface.
+@value{GDBN} processes all events, such as user keyboard input, via a
+special event loop. This allows @value{GDBN} to accept and process user
+commands in parallel with the debugged process being
+run@footnote{@value{GDBN} built with @sc{djgpp} tools for
+MS-DOS/MS-Windows supports this mode of operation, but the event loop is
+suspended when the debuggee runs.}, so you don't need to wait for
+control to return to @value{GDBN} before you type the next command.
+
+When the standard input is connected to a terminal device, @value{GDBN}
+uses the asynchronous event loop by default, unless disabled by the
+@samp{-noasync} option.
+
+@item -noasync
+@cindex @code{--noasync}
+Disable the asynchronous event loop for the command-line interface.
+
@item -baud @var{bps}
@itemx -b @var{bps}
+@cindex @code{--baud}
+@cindex @code{-b}
Set the line speed (baud rate or bits per second) of any serial
interface used by @value{GDBN} for remote debugging.
@item -tty @var{device}
+@itemx -t @var{device}
+@cindex @code{--tty}
+@cindex @code{-t}
Run using @var{device} for your program's standard input and output.
@c FIXME: kingdon thinks there is more to -tty. Investigate.
@c resolve the situation of these eventually
@c @item -tui
+@c @cindex @code{--tui}
@c Use a Terminal User Interface. For information, use your Web browser to
@c read the file @file{TUI.html}, which is usually installed in the
@c directory @code{/opt/langtools/wdb/doc} on HP-UX systems. Do not use
@@ -901,11 +978,38 @@
@c @value{GDBN} under @sc{gnu} Emacs}).
@c @item -xdb
+@c @cindex @code{--xdb}
@c Run in XDB compatibility mode, allowing the use of certain XDB commands.
@c For information, see the file @file{xdb_trans.html}, which is usually
@c installed in the directory @code{/opt/langtools/wdb/doc} on HP-UX
@c systems.
+@item -interpreter @var{interp}
+@cindex @code{--interpreter}
+Use the interpreter @var{interp} for interface with the controlling
+program or device. This option is meant to be set by programs which
+communicate with @value{GDBN} using it as a back end. For example,
+@samp{--interpreter=mi} causes @value{GDBN} to use the @dfn{gdbmi
+interface}.
+@c FIXME: There should be an @xref here to the GDB/MI docs, but
+@c gdbmi.texi doesn't have a single node to reference!
+
+@item -write
+@cindex @code{--write}
+Open the executable and core files for both reading and writing. This
+is equivalent to the @samp{set write on} command inside @value{GDBN}
+(@pxref{Patching}).
+
+@item -statistics
+@cindex @code{--statistics}
+This option causes @value{GDBN} to print statistics about time and
+memory usage after it completes each command and returns to the prompt.
+
+@item -version
+@cindex @code{--version}
+This option causes @value{GDBN} to print its version number and
+no-warranty blurb, and exit.
+
@end table
@node Quitting GDB
@@ -12488,6 +12592,8 @@
There are many other options available as well, but they are generally
needed for special purposes only.
+
+@include annotate.texi
@node Index
@unnumbered Index
--- gdb/doc/annotate.t~0 Fri Apr 16 03:54:46 1999
+++ gdb/doc/annotate.texi Fri Mar 10 11:53:06 2000
@@ -1,85 +1,93 @@
-\input texinfo @c -*-texinfo-*-
-@c %**start of header
-@setfilename annotate.info
-@settitle GDB Annotations
-@setchapternewpage off
-@c %**end of header
-
-@set EDITION 0.5
-@set DATE May 1994
-
-@ifinfo
-This file documents GDB annotations.
-
-This is Edition @value{EDITION}, @value{DATE}, of @cite{GDB
-Annotations}. Copyright 1994 Free Software Foundation
-
-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.
-
-@ignore
-Permission is granted to process this file through TeX and print the
-results, provided the printed document carries copying permission
-notice identical to this one except for the removal of this paragraph
-(this paragraph not being relevant to the printed manual).
-
-@end ignore
-Permission is granted to copy and distribute modified versions of this
-manual under the conditions for verbatim copying, provided also that the
-entire resulting derived work is distributed under the terms of a
-permission notice identical to this one.
-
-Permission is granted to copy and distribute translations of this manual
-into another language, under the above conditions for modified versions.
-@end ifinfo
-
-@titlepage
-@title GDB Annotations
-@subtitle Edition @value{EDITION}
-@subtitle @value{DATE}
-@author Cygnus Support
-@page
-@vskip 0pt plus 1filll
-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.
-
-Copyright @copyright{} 1994 Free Software Foundation
-@end titlepage
-
-@ifinfo
-@node Top
-@top GDB Annotations
-
-This file describes annotations in GDB, the GNU symbolic debugger.
-Annotations are designed to interface GDB to graphical user interfaces
-or other similar programs which want to interact with GDB at a
+@c \input texinfo @c -*-texinfo-*-
+@c @c %**start of header
+@c @setfilename annotate.info
+@c @settitle GDB Annotations
+@c @setchapternewpage off
+@c @c %**end of header
+
+@c @set EDITION 0.5
+@c @set DATE May 1994
+
+@c @ifinfo
+@c This file documents GDB annotations.
+
+@c This is Edition @value{EDITION}, @value{DATE}, of @cite{GDB
+@c Annotations}. Copyright 1994 Free Software Foundation
+
+@c Permission is granted to make and distribute verbatim copies of
+@c this manual provided the copyright notice and this permission notice
+@c are preserved on all copies.
+@c @end ignore
+
+@c @ignore
+@c Permission is granted to process this file through TeX and print the
+@c results, provided the printed document carries copying permission
+@c notice identical to this one except for the removal of this paragraph
+@c (this paragraph not being relevant to the printed manual).
+
+@c @end ignore
+@c Permission is granted to copy and distribute modified versions of this
+@c manual under the conditions for verbatim copying, provided also that the
+@c entire resulting derived work is distributed under the terms of a
+@c permission notice identical to this one.
+
+@c Permission is granted to copy and distribute translations of this manual
+@c into another language, under the above conditions for modified versions.
+@c @end ifinfo
+
+@c @titlepage
+@c @title GDB Annotations
+@c @subtitle Edition @value{EDITION}
+@c @subtitle @value{DATE}
+@c @author Cygnus Support
+@c @page
+@c @vskip 0pt plus 1filll
+@c Permission is granted to make and distribute verbatim copies of
+@c this manual provided the copyright notice and this permission notice
+@c are preserved on all copies.
+
+@c Copyright @copyright{} 1994 Free Software Foundation
+@c @end titlepage
+
+@c @ifinfo
+@c @node Top
+@c @top GDB Annotations
+
+@syncodeindex fn cp
+
+@node Annotations
+@chapter @value{GDBN} Annotations
+
+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
This is Edition @value{EDITION}, @value{DATE}.
+@end ignore
@menu
-* General:: What annotations are; the general syntax.
-* Server:: Issuing a command without affecting user state.
-* Values:: Values are marked as such.
-* Frames:: Stack frames are annotated.
-* Displays:: GDB can be told to display something periodically.
-* Prompting:: Annotations marking GDB's need for input.
+* Annotations Overview:: What annotations are; the general syntax.
+* Server Prefix:: Issuing a command without affecting user state.
+* Value Annotations:: Values are marked as such.
+* Frame Annotations:: Stack frames are annotated.
+* Displays:: @value{GDBN} can be told to display something periodically.
+* Prompting:: Annotations marking @value{GDBN}'s need for input.
* Errors:: Annotations for error messages.
* Breakpoint Info:: Information on breakpoints.
* Invalidation:: Some annotations describe things now invalid.
-* Running:: Whether the program is running, how it stopped, etc.
-* Source:: Annotations describing source code.
+* Annotations for Running::
+ Whether the program is running, how it stopped, etc.
+* Source Annotations:: Annotations describing source code.
* TODO:: Annotations which might be added in the future.
-* Index:: Index
@end menu
-@end ifinfo
-@node General
-@chapter What is an Annotation?
+@node Annotations Overview
+@section What is an Annotation?
+@cindex annotations
-To produce annotations, start GDB with the @code{--annotate=2} option.
+To produce annotations, start @value{GDBN} with the @code{--annotate=2} option.
Annotations start with a newline character, two @samp{control-z}
characters, and the name of the annotation. If there is no additional
@@ -90,20 +98,22 @@
cannot contain newline characters.
Any output not beginning with a newline and two @samp{control-z}
-characters denotes literal output from GDB. Currently there is no need
-for GDB to output a newline followed by two @samp{control-z} characters,
+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 GDB with annotations is:
+A simple example of starting up @value{GDBN} with annotations is:
-@example
+@smallexample
$ gdb --annotate=2
-GDB is free software and you are welcome to 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.
-GDB 4.12.3 (sparc-sun-sunos4.1.3),
-Copyright 1994 Free Software Foundation, Inc.
+GNU GDB 5.0
+Copyright 1998 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
(gdb)
@@ -112,29 +122,31 @@
^Z^Zpost-prompt
$
-@end example
+@end smallexample
-Here @samp{quit} is input to GDB; the rest is output from GDB. The three
+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 GDB.
+character) are annotations; the rest is output from @value{GDBN}.
-@node Server
-@chapter The Server Prefix
+@node Server Prefix
+@section The Server Prefix
+@cindex server prefix for annotations
-To issue a command to GDB without affecting certain aspects of the state
+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
-GDB's notion of which command to repeat if @key{RET} is pressed on a
+@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 the @code{print} command.
-@node Values
-@chapter Values
+@node Value Annotations
+@section Values
-When a value is printed in various contexts, GDB uses annotations to
+@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
@@ -172,7 +184,7 @@
@findex arg-name-end
@findex arg-value
@findex arg-end
-When GDB prints an argument to a function (for example, in the output
+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
@@ -195,7 +207,7 @@
@findex field-name-end
@findex field-value
@findex field-end
-When printing a structure, GDB annotates it as follows:
+When printing a structure, @value{GDBN} annotates it as follows:
@example
^Z^Zfield-begin @var{value-flags}
@@ -212,7 +224,7 @@
(such as @samp{=}), and @var{value-flags} and @var{the-value} have the
same meanings as in a @code{value-history-begin} annotation.
-When printing an array, GDB annotates it as follows:
+When printing an array, @value{GDBN} annotates it as follows:
@example
^Z^Zarray-section-begin @var{array-index} @var{value-flags}
@@ -257,11 +269,12 @@
^Z^Zarray-section-end
@end example
-@node Frames
-@chapter Frames
+@node Frame Annotations
+@section Frames
-Whenever GDB prints a frame, it annotates it. For example, this applies
-to frames printed when GDB stops, output from commands such as
+@cindex annotations for frames
+Whenever @value{GDBN} prints a frame, it annotates it. For example, this applies
+to frames printed when @value{GDBN} stops, output from commands such as
@code{backtrace} or @code{up}, etc.
@findex frame-begin
@@ -296,7 +309,7 @@
@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 GDB to a
+that this frame is associated with a function call made by @value{GDBN} to a
function in the program being debugged.
@item
@@ -347,7 +360,7 @@
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
to the frame, with parentheses around them (each argument is annotated
-individually as well @pxref{Values}).
+individually as well, @pxref{Value Annotations}).
@findex frame-source-begin
@findex frame-source-file
@@ -374,7 +387,7 @@
file (the first line is line 1).
@findex frame-where
-If GDB prints some information about where the frame is from (which
+If @value{GDBN} prints some information about where the frame is from (which
library, which load segment, etc.; currently only done on the RS/6000),
it is annotated with
@@ -391,7 +404,7 @@
@end itemize
@node Displays
-@chapter Displays
+@section Displays
@findex display-begin
@findex display-number-end
@@ -400,7 +413,8 @@
@findex display-expression-end
@findex display-value
@findex display-end
-When GDB is told to display something using the @code{display} command,
+@cindex annotations for display
+When @value{GDBN} is told to display something using the @code{display} command,
the results of the display are annotated:
@example
@@ -428,9 +442,10 @@
and @var{value} is the actual value being displayed.
@node Prompting
-@chapter Annotation for GDB Input
+@section Annotation for @value{GDBN} Input
-When GDB prompts for input, it annotates this fact so it is possible
+@cindex annotations for prompts
+When @value{GDBN} prompts for input, it annotates this fact so it is possible
to know when to send output, when the output from a given command is
over, etc.
@@ -455,60 +470,61 @@
@findex prompt
@findex post-prompt
@item prompt
-When GDB is prompting for a command (the main GDB prompt).
+When @value{GDBN} is prompting for a command (the main @value{GDBN} prompt).
@findex pre-commands
@findex commands
@findex post-commands
@item commands
-When GDB prompts for a set of commands, like in the @code{commands}
+When @value{GDBN} prompts for a set of commands, like in the @code{commands}
command. The annotations are repeated for each command which is input.
@findex pre-overload-choice
@findex overload-choice
@findex post-overload-choice
@item overload-choice
-When GDB wants the user to select between various overloaded functions.
+When @value{GDBN} wants the user to select between various overloaded functions.
@findex pre-query
@findex query
@findex post-query
@item query
-When GDB wants the user to confirm a potentially dangerous operation.
+When @value{GDBN} wants the user to confirm a potentially dangerous operation.
@findex pre-prompt-for-continue
@findex prompt-for-continue
@findex post-prompt-for-continue
@item prompt-for-continue
-When GDB is asking the user to press return to continue. Note: Don't
+When @value{GDBN} is asking the user to press return to continue. Note: Don't
expect this to work well; instead use @code{set height 0} to disable
prompting. This is because the counting of lines is buggy in the
presence of annotations.
@end table
@node Errors
-@chapter Errors
+@section Errors
+@cindex annotations for errors, warnings and interrupts
@findex quit
@example
^Z^Zquit
@end example
-This annotation occurs right before GDB responds to an interrupt.
+This annotation occurs right before @value{GDBN} responds to an interrupt.
@findex error
@example
^Z^Zerror
@end example
-This annotation occurs right before GDB responds to an error.
+This annotation occurs right before @value{GDBN} responds to an error.
-Quit and error annotations indicate that any annotations which GDB was
+Quit and error annotations indicate that any annotations which @value{GDBN} was
in the middle of may end abruptly. For example, if a
@code{value-history-begin} annotation is followed by a @code{error}, one
cannot expect to receive the matching @code{value-history-end}. One
cannot expect not to receive it either, however; an error annotation
-does not necessarily mean that GDB is immediately returning all the way
+does not necessarily mean that @value{GDBN} is immediately returning all the way
to the top level.
@findex error-begin
@@ -526,8 +542,9 @@
@c range_error(), and possibly other places.
@node Breakpoint Info
-@chapter Information on Breakpoints
+@section Information on Breakpoints
+@cindex annotations for breakpoints
The output from the @code{info breakpoints} command is annotated as follows:
@findex breakpoints-headers
@@ -582,8 +599,9 @@
@end example
@node Invalidation
-@chapter Invalidation Notices
+@section Invalidation Notices
+@cindex annotations for invalidation messages
The following annotations say that certain pieces of state may have
changed.
@@ -601,12 +619,13 @@
deleted a breakpoint.
@end table
-@node Running
-@chapter Running the Program
+@node Annotations for Running
+@section Running the Program
+@cindex annotations for running programs
@findex starting
@findex stopping
-When the program starts executing due to a GDB command such as
+When the program starts executing due to a @value{GDBN} command such as
@code{step} or @code{continue},
@example
@@ -657,7 +676,7 @@
@findex signal
@item ^Z^Zsignal
-The syntax of this annotation is just like @code{signalled}, but GDB is
+The syntax of this annotation is just like @code{signalled}, but @value{GDBN} is
just saying that the program received the signal, not that it was
terminated with it.
@@ -670,8 +689,9 @@
The program hit watchpoint number @var{number}.
@end table
-@node Source
-@chapter Displaying Source
+@node Source Annotations
+@section Displaying Source
+@cindex annotations for source display
@findex source
The following annotation is used instead of displaying source code:
@@ -693,7 +713,7 @@
depend on the language).
@node TODO
-@chapter Annotations We Might Want in the Future
+@section Annotations We Might Want in the Future
@format
- target-invalid
@@ -709,9 +729,11 @@
notices.
@end format
+@ignore
@node Index
@unnumbered Index
@printindex fn
+@end ignore
-@bye
+@c @bye
From eliz@delorie.com Fri Mar 10 10:09:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] GDB command-line switches and annotations docs
Date: Fri, 10 Mar 2000 10:09:00 -0000
Message-id: <200003101809.NAA22092@indy.delorie.com>
References: <14537.5048.99180.910863@kwikemart.cygnus.com>
X-SW-Source: 2000-03/msg00206.html
Content-length: 1342
Elena Zannoni writes:
> > (Are there plans to make gdbmi.texi be part of the manual as well?)
> >
>
> Eventually yes (Andrew?), right now it is not in prime time form yet. It is
> still very rough work in progress.
IMHO, it is much better to link between the two right now, and make
any necessary corrections later. As far as I could see, gdbmi.texi is
in quite a good shape, it just lacks a few menus and @node lines to
make it a valid Texinfo file. Most of the work can be done in Emacs
automatically.
The current situation, where a large part opf the package is not
documented at all, is IMHO much worse.
I can throw together a few patches as outlined above, if that would
help.
> I was planning on removing the -async option, it is now redundant.
It's much easier to remove part of the docs than to write it ;-)
Anyway, if -noasync stays, you will need some of what I wrote under
its description.
> The behavior you describe is the ultimate goal, we are only
> about 50% there.
The truth is, I still don't know enough about the event loop's
interaction with the target side to write the docs about it. But I
thought there was no better way to get attention to its being
undocumented than to throw some patches on you-all ;-). I do think
that refining the description should be the job of someone who knows
the fine details.
^ permalink raw reply [flat|nested] 2+ messages in thread