* Re: [PATCH] minor fixes in remote.c
[not found] ` <38D6B3B4.1F73@cygnus.com>
@ 2000-03-20 23:38 ` Philippe GIACINTI
0 siblings, 0 replies; only message in thread
From: Philippe GIACINTI @ 2000-03-20 23:38 UTC (permalink / raw)
To: Michael Snyder; +Cc: Philippe GIACINTI, gdb-patches
Michael Snyder <msnyder@cygnus.com> wrote:
> Philippe GIACINTI wrote:
> >
> > Hi,
> >
> > Here is a patch including minor fixes in file gdb/remote.c:
> >
> > * remote.c (record_currthread): must call `set_thread' to change
> > general thread, in order to let stub know we have changed it.
> > * remote.c (remote_read_bytes): when we need to read more memory
> > than max buffer size, we have to reserve space for leading $ and
> > trailing # + checksum (i.e.: 4 char)
> >
> > ---------------------------------------------------------------
> > --- insight-20000314.old/gdb/remote.c Fri Feb 18 18:00:18 2000
> > +++ insight-20000314/gdb/remote.c Fri Mar 17 09:00:54 2000
> > @@ -742,7 +742,7 @@
> > record_currthread (currthread)
> > int currthread;
> > {
> > - general_thread = currthread;
> > + set_thread (currthread,1);
> >
> > /* If this is a new thread, add it to GDB's thread list.
> > If we leave it up to WFI to do this, bad things will happen. */
>
> Philippe,
>
> I don't understand why this change should be necessary.
> The only context from which this function, remote_currthread,
> is called is when the remote target sends GDB a message telling
> GDB that the current thread has changed. Why should GDB then
> need to turn around and pass the same information back to
> the remote target? I should take it for granted that the
> remote target already knows this (having just told it to us).
>
Michael,
According to the remote protocol, the remote side only has to know the
`general' and `continue' threads, there is no notion of `current' thread.
In the current implementation of gdbserver, there is no current thread, and it
works because the stub code always gets info from the same thread
(`inferior_pid'). In a multi-threaded context it is not possible without being
informed that the `general' thread has changed.
IMHO it is a good thing not to have to record the current thread in the remote
side and let the host side (gdb) decide which thread will be inspected and
which thread will continue, it will otherwise be a useless limitation of the
protocol. This way it could be possible to inspect one thread without changing
the current thread in gdb ...
Best regards.
--
Philippe Giacinti - Alcatel Business Systems - PCD/SMB/SWPCC - CC S0645
1, route du Dr Albert Schweitzer - 67408 Illkirch Cedex - FRANCE
Tel: +33 (0)3.90.67.62.10 - Fax: +33 (0)3.90.67.77.93
mailto:Philippe.Giacinti@sxb.bsf.alcatel.fr
From ac131313@cygnus.com Tue Mar 21 00:30:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] solib.c, symfile.c, symtab.h, and target.h changes
Date: Tue, 21 Mar 2000 00:30:00 -0000
Message-id: <38D73309.E25D2F0E@cygnus.com>
References: <1000318022821.ZM8341@ocotillo.lan>
X-SW-Source: 2000-03/msg00414.html
Content-length: 2389
Kevin Buettner wrote:
(yes, I'm the target vector maintainer. Thanks for the ping :-)
> The difficult part was choosing names for the new functions and
> deciding which header file should be used to declare the new
> functions. I ended up putting them next to the declaration of
> build_section_table() in target.h. target.h was the best choice
> for the following reasons:
The names are fine (make that pretty good).
>
> 1) The prototype for build_section_addr_info_from_section_table()
> refers to struct section_table *. This type is declared in
> target.h.
FYI,
I consider it legitimate to use:
struct section_table;
extern struct section_addr_info
*build_section_addr_info_from_section_table (const? struct section_table
*start, const const? section_table *end);
(An asside, this is why I also suggest people avoid ``typedef struct''
:-).
> 2) The return type for build_section_addr_info_from_section_table()
> is struct section_addr_info *. This type is declared in symtab.h.
> But target.h includes symtab.h. So this type is available to
> target.h as well.
I'll add that to my list of things to fix :-)
> 3) target.h already has a declaration for a function dealing with
> struct section_table *.
FYI, (and totally off the topic ...)
gdbarch is going to be broken into gdbarch.[hc] and gdbarch-utils.[hc].
target.[hc] is going to suffer a similar fate. Anything in target.[hc]
not directly relevant to the target vector is going to end up being
given the boot (to another file). Why? Any plan
multi-arching/multi-targeting GDB becomes just that bit more feasible if
the target vector is purged of all its current junk.
Anyway I'd rather target.[hc] didn't accumulate any more fluff.
(sorry, delete rant)
> Jim B. "pre-approved" me for checking in the changes to solib.c,
> symtab.h, and symfile.c. It's not clear to me who the maintainer
> for target.h is, so I'm seeking approval for those changes. (My
> guess is that Andrew is the maintainer by default.)
I'd suggest having the definitions in the header file that best
corresponds to the .c file that contains the functions implementation.
My guess is that symtab.h/symtab.c might be the best candidates since
symtab.h defines the struct that the function is building/freeing.
However one of the other files would proably be equally suitable.
enjoy,
Andrew
From ac131313@cygnus.com Tue Mar 21 00:48:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: gdbarch_free
Date: Tue, 21 Mar 2000 00:48:00 -0000
Message-id: <38D73738.925043DF@cygnus.com>
References: <200002282302.SAA13215@zwingli.cygnus.com> <38BB1A9A.61A680AA@cygnus.com> <npg0ualjj3.fsf@zwingli.cygnus.com> <38C223E1.43260416@cygnus.com> <npk8j49nv0.fsf@zwingli.cygnus.com> <nphfe89jwc.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-03/msg00415.html
Content-length: 1480
Jim Blandy wrote:
>
> > > > > >From memory, I figured that if an _initialize* function failed to create
> > > > > a gdbarch the process was somewhat hosed and calling internal_error()
> > > > > was probably the best thing to do.
> > >
> > > > This situation could arise if someone adds support for a new variant
> > > > of my architecture, but hasn't updated GDB yet.
> > >
> > > So the real question is, is this an internal_error() and how should
> > > it be handled? I can be convinced either way on this :-)
> >
> > No, it's okay, I'll just drop the memory. I withdraw the patch.
>
> Well, actually...
:-)
> I don't think this is an internal error. It's simply a case where GDB
> has been given an executable that it doesn't recognize. That
> executable may have been produced by a completely different toolchain.
Ah, I'd not thought of it that way. Yes, very good point. While I can
try to insist that GDB / BFD are kept consistent, I can't impose that
requirement on the real world.
Your change is approved.
I'll see about clarifying the spec for gdbarch_init_ftype so that it
makes it clear that not recognizing the architecture is common and
should be handled cleanly.
As a second issue, there should be a test that checks that BFD/GDB are
in sync with regard to architecture changes. Something like a test that
first queries GDB for all supported architectures and then feeds each
back to GDB.. Anyone interested in learning how to write tests? :-)
Andrew
From ac131313@cygnus.com Tue Mar 21 01:11:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>, Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Linux sigtramp detection code moved to its proper place
Date: Tue, 21 Mar 2000 01:11:00 -0000
Message-id: <38D73C78.4B2B3562@cygnus.com>
References: <200003201529.KAA10589@indy.delorie.com>
X-SW-Source: 2000-03/msg00416.html
Content-length: 1338
Eli Zaretskii wrote:
>
> > What would you suggest for a non-buggy Tar program to do, exactly?
> >
> > Simply overwrite the files, possibly asking confirmation from the
> > user. This shouldn't be a problem, since the DJGPP native port
> > doesn't need i386-linux-nat.c nor i386-linux-tdep.c.
>
> The users don't know whether these files are or aren't needed. So
> they might overwrite the wrong files, and mess up the build beyond
> any recognition.
As Eli notes, the average user doesn't know if a warning during an
unpack is legetimate or not. Having things unpack without warnings both
improves the out-of-box experience and reduces the number of apparently
silly (but actually legetimate) e-mail questions. Having the build
issue GCC warnings for things that won't/can't be fixed fixed is equally
confusing.
By way of an olive branch ;-) Is there anything that the nightly
snapshots (short term) and/or testsuite (medium/long term) can do to
ensure that the relevant djgpp files are always up-to-date?
As a suggestion from left field, I've wondered if gdb.base/selftest.exp
should be moved to gdb.wb/selftest.exp (wb == white box) so that people
can freely add additional white box tests to GDB. Checking consistency
between config/djgpp/<that-file> and the GDB sources could be part of
that testsuite.
enjoy,
Andrew
From ac131313@cygnus.com Tue Mar 21 02:11:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Stephane Carrez <Stephane.Carrez@worldnet.fr>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
Date: Tue, 21 Mar 2000 02:11:00 -0000
Message-id: <38D74A9E.A85ED8EC@cygnus.com>
References: <38D4DCB0.88313CB2@worldnet.fr> <38D5B6E0.50FF6A5E@cygnus.com> <38D68C56.856CB00C@worldnet.fr>
X-SW-Source: 2000-03/msg00417.html
Content-length: 1887
Stephane Carrez wrote:
>
> Hi Andrew,
>
> Andrew Cagney wrote:
> >
> > Stephane Carrez wrote:
> > >
> > > Hi!
> > >
> > > One part of the patch for dwarf2 correction with 16-bit target has
> > > been lost. If you are still not convinced by the fix, have a look
> > > at gas/dwarf2dbg.c in out_set_addr() where we obtain the address
> > > size in a good way.
> > >
> > > Can you integrate it?
> >
> > FYI,
> >
> > My reading of the thread from when this patch was last posted is that it
> > wasn't clear that this was a bug and the change was the correct thing to
> > do.
> >
> For me, it's a bug. The address size specified in dwarf2 is 16 and
> because we use arch_size which corresponds to the ELF32/ELF64 size,
> gdb stops reading with an error (dwarf2read.c:983):
>
> if (address_size < address_significant_size)
> {
> error ("Dwarf Error: bad address size (%ld) in compilation unit header (offset 0x%lx +
> 11).",
> (long) cu_header.addr_size,
> (long) (beg_of_comp_unit - dwarf_info_buffer));
>
As far as I know, the dwarf2 and elf information are both ment to be
self contained. There shouldn't be any need to refer to some arbitrary
bfd table to determine what is going on. If the info says that an
address is 16 bits for a given section then it sounds like GDB should
just believe it.
As JimK suggested:
> Or to put it another way, specifically what went wrong on the 68HC11
> if you didn't change dwarf2read.c? If it was just the "Dwarf Error:
> bad address size" error, what happens if you just comment out that
> check?
Rather than diging values out of archures I think the possibility of:
cu_header.address_size < elf-header.address_size
should be documented as being just as legetimate (sarcasm :-) as:
cu_header.address_size > elf-header.address_size
and the check either replaced or removed.
Andrew
From 3diff@gnu.org Tue Mar 21 07:03:00 2000
From: Brian Youmans <3diff@gnu.org>
To: shebs@apple.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: GDB manual and @smallbook
Date: Tue, 21 Mar 2000 07:03:00 -0000
Message-id: <200003211503.KAA05848@delysid.gnu.org>
References: <200003031956.OAA23859@delysid.gnu.org> <38D6C407.19309BA1@apple.com>
X-SW-Source: 2000-03/msg00418.html
Content-length: 256
Thanks!
Whenever there is a finished version of the manual that you don't really
expect to change before the release, I'd like a copy, or just a pointer.
We are out of stock, and it would be good to put this into print ASAP.
- Brian Y., FSF office staff
From phdm@macqel.be Tue Mar 21 08:00:00 2000
From: "Philippe De Muyter" <phdm@macqel.be>
To: ac131313@cygnus.com (Andrew Cagney)
Cc: ezannoni@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: HAVE_POLL is not enough - RFA
Date: Tue, 21 Mar 2000 08:00:00 -0000
Message-id: <200003211559.QAA16996@mail.macqel.be>
References: <38D5BE1D.7BB02C99@cygnus.com>
X-SW-Source: 2000-03/msg00419.html
Content-length: 18695
Andrew Cagney wrote :
> if (use_poll)
> {
> #if HAVE_POLL
> ...
> #else
> internal_error (...);
> #endif
> }
> else
> {
> }
I have done that. OK to commit ?
Tue Mar 21 16:49:38 2000 Philippe De Muyter <phdm@macqel.be>
* event-loop.c (sys/types.h): File now included unconditionally.
(use_poll): New variable, initialized to HAVE_POLL.
(gdb_notifier): poll- and select-versions merged.
(add_file_handler): If HAVE_POLL, check whether poll is usable,
and reset `use_poll' if not.
(create_file_handler): Select poll- or select-version according to
`use_poll'.
(delete_file_handler, handle_file_event): Likewise.
(gdb_wait_for_event, poll_timers): Likewise.
Index: gdb/event-loop.c
===================================================================
RCS file: /cvs/src/src/gdb/event-loop.c,v
retrieving revision 1.4
diff -u -p -r1.4 event-loop.c
--- event-loop.c 2000/03/20 19:59:38 1.4
+++ event-loop.c 2000/03/21 15:39:29
@@ -25,10 +25,9 @@
#include "event-top.h"
#ifdef HAVE_POLL
#include <poll.h>
-#else
+#endif
#include <sys/types.h>
#include <string.h>
-#endif
#include <errno.h>
#include <setjmp.h>
#include <sys/time.h>
@@ -166,36 +165,21 @@ event_queue;
/* As of 1999-04-30 only the input file descriptor is registered with the
event loop. */
-#ifdef HAVE_POLL
-/* Poll based implementation of the notifier. */
+/* Do we use poll or select ? */
+static unsigned char use_poll = HAVE_POLL;
static struct
{
/* Ptr to head of file handler list. */
file_handler *first_file_handler;
+#ifdef HAVE_POLL
/* Ptr to array of pollfd structures. */
struct pollfd *poll_fds;
- /* Number of file descriptors to monitor. */
- int num_fds;
-
/* Timeout in milliseconds for calls to poll(). */
- int timeout;
-
- /* Flag to tell whether the timeout value shuld be used. */
- int timeout_valid;
- }
-gdb_notifier;
-
-#else /* ! HAVE_POLL */
-
-/* Select based implementation of the notifier. */
-
-static struct
- {
- /* Ptr to head of file handler list. */
- file_handler *first_file_handler;
+ int poll_timeout;
+#endif
/* Masks to be used in the next call to select.
Bits are set in response to calls to create_file_handler. */
@@ -204,19 +188,18 @@ static struct
/* What file descriptors were found ready by select. */
fd_set ready_masks[3];
- /* Number of valid bits (highest fd value + 1). */
+ /* Number of file descriptors to monitor. (for poll) */
+ /* Number of valid bits (highest fd value + 1). (for select) */
int num_fds;
/* Time structure for calls to select(). */
- struct timeval timeout;
+ struct timeval select_timeout;
- /* Flag to tell whether the timeout struct should be used. */
+ /* Flag to tell whether the timeout should be used. */
int timeout_valid;
}
gdb_notifier;
-#endif /* HAVE_POLL */
-
/* Structure associated with a timer. PROC will be executed at the
first occasion after WHEN. */
struct gdb_timer
@@ -384,7 +367,7 @@ process_event (void)
}
free ((char *) event_ptr);
- /* Now call the procedure associted with the event. */
+ /* Now call the procedure associated with the event. */
(*proc) (fd);
return 1;
}
@@ -473,10 +456,30 @@ void
add_file_handler (int fd, handler_func * proc, gdb_client_data client_data)
{
#ifdef HAVE_POLL
- create_file_handler (fd, POLLIN, proc, client_data);
+ struct pollfd fds;
+#endif
+
+ if (use_poll)
+ {
+#ifdef HAVE_POLL
+ fds.fd = fd;
+ fds.events = POLLIN;
+ if (poll (&fds, 1, 0) == 1 && (fds.revents & POLLNVAL))
+ use_poll = 0;
#else
- create_file_handler (fd, GDB_READABLE | GDB_EXCEPTION, proc, client_data);
+ internal_error ("event-loop.c : use_poll without HAVE_POLL");
+#endif /* HAVE_POLL */
+ }
+ if (use_poll)
+ {
+#ifdef HAVE_POLL
+ create_file_handler (fd, POLLIN, proc, client_data);
+#else
+ internal_error ("event-loop.c : use_poll without HAVE_POLL");
#endif
+ }
+ else
+ create_file_handler (fd, GDB_READABLE | GDB_EXCEPTION, proc, client_data);
}
/* Add a file handler/descriptor to the list of descriptors we are
@@ -512,48 +515,49 @@ create_file_handler (int fd, int mask, h
file_ptr->ready_mask = 0;
file_ptr->next_file = gdb_notifier.first_file_handler;
gdb_notifier.first_file_handler = file_ptr;
-#ifdef HAVE_POLL
- gdb_notifier.num_fds++;
-#endif
}
file_ptr->proc = proc;
file_ptr->client_data = client_data;
file_ptr->mask = mask;
+ if (use_poll)
+ {
#ifdef HAVE_POLL
-
- if (gdb_notifier.poll_fds)
- gdb_notifier.poll_fds =
- (struct pollfd *) realloc (gdb_notifier.poll_fds,
- (gdb_notifier.num_fds) * sizeof (struct pollfd));
- else
- gdb_notifier.poll_fds =
- (struct pollfd *) xmalloc (sizeof (struct pollfd));
- (gdb_notifier.poll_fds + gdb_notifier.num_fds - 1)->fd = fd;
- (gdb_notifier.poll_fds + gdb_notifier.num_fds - 1)->events = mask;
- (gdb_notifier.poll_fds + gdb_notifier.num_fds - 1)->revents = 0;
-
-#else /* ! HAVE_POLL */
-
- if (mask & GDB_READABLE)
- FD_SET (fd, &gdb_notifier.check_masks[0]);
- else
- FD_CLR (fd, &gdb_notifier.check_masks[0]);
-
- if (mask & GDB_WRITABLE)
- FD_SET (fd, &gdb_notifier.check_masks[1]);
+ gdb_notifier.num_fds++;
+ if (gdb_notifier.poll_fds)
+ gdb_notifier.poll_fds =
+ (struct pollfd *) realloc (gdb_notifier.poll_fds,
+ (gdb_notifier.num_fds) * sizeof (struct pollfd));
+ else
+ gdb_notifier.poll_fds =
+ (struct pollfd *) xmalloc (sizeof (struct pollfd));
+ (gdb_notifier.poll_fds + gdb_notifier.num_fds - 1)->fd = fd;
+ (gdb_notifier.poll_fds + gdb_notifier.num_fds - 1)->events = mask;
+ (gdb_notifier.poll_fds + gdb_notifier.num_fds - 1)->revents = 0;
+#else
+ internal_error ("event-loop.c : use_poll without HAVE_POLL");
+#endif /* HAVE_POLL */
+ }
else
- FD_CLR (fd, &gdb_notifier.check_masks[1]);
+ {
+ if (mask & GDB_READABLE)
+ FD_SET (fd, &gdb_notifier.check_masks[0]);
+ else
+ FD_CLR (fd, &gdb_notifier.check_masks[0]);
- if (mask & GDB_EXCEPTION)
- FD_SET (fd, &gdb_notifier.check_masks[2]);
- else
- FD_CLR (fd, &gdb_notifier.check_masks[2]);
+ if (mask & GDB_WRITABLE)
+ FD_SET (fd, &gdb_notifier.check_masks[1]);
+ else
+ FD_CLR (fd, &gdb_notifier.check_masks[1]);
- if (gdb_notifier.num_fds <= fd)
- gdb_notifier.num_fds = fd + 1;
+ if (mask & GDB_EXCEPTION)
+ FD_SET (fd, &gdb_notifier.check_masks[2]);
+ else
+ FD_CLR (fd, &gdb_notifier.check_masks[2]);
-#endif /* HAVE_POLL */
+ if (gdb_notifier.num_fds <= fd)
+ gdb_notifier.num_fds = fd + 1;
+ }
}
/* Remove the file descriptor FD from the list of monitored fd's:
@@ -580,51 +584,56 @@ delete_file_handler (int fd)
if (file_ptr == NULL)
return;
+ if (use_poll)
+ {
#ifdef HAVE_POLL
- /* Create a new poll_fds array by copying every fd's information but the
- one we want to get rid of. */
+ /* Create a new poll_fds array by copying every fd's information but the
+ one we want to get rid of. */
- new_poll_fds =
- (struct pollfd *) xmalloc ((gdb_notifier.num_fds - 1) * sizeof (struct pollfd));
+ new_poll_fds =
+ (struct pollfd *) xmalloc ((gdb_notifier.num_fds - 1) * sizeof (struct pollfd));
- for (i = 0, j = 0; i < gdb_notifier.num_fds; i++)
- {
- if ((gdb_notifier.poll_fds + i)->fd != fd)
+ for (i = 0, j = 0; i < gdb_notifier.num_fds; i++)
{
- (new_poll_fds + j)->fd = (gdb_notifier.poll_fds + i)->fd;
- (new_poll_fds + j)->events = (gdb_notifier.poll_fds + i)->events;
- (new_poll_fds + j)->revents = (gdb_notifier.poll_fds + i)->revents;
- j++;
+ if ((gdb_notifier.poll_fds + i)->fd != fd)
+ {
+ (new_poll_fds + j)->fd = (gdb_notifier.poll_fds + i)->fd;
+ (new_poll_fds + j)->events = (gdb_notifier.poll_fds + i)->events;
+ (new_poll_fds + j)->revents = (gdb_notifier.poll_fds + i)->revents;
+ j++;
+ }
}
+ free (gdb_notifier.poll_fds);
+ gdb_notifier.poll_fds = new_poll_fds;
+ gdb_notifier.num_fds--;
+#else
+ internal_error ("event-loop.c : use_poll without HAVE_POLL");
+#endif /* HAVE_POLL */
}
- free (gdb_notifier.poll_fds);
- gdb_notifier.poll_fds = new_poll_fds;
- gdb_notifier.num_fds--;
-
-#else /* ! HAVE_POLL */
-
- if (file_ptr->mask & GDB_READABLE)
- FD_CLR (fd, &gdb_notifier.check_masks[0]);
- if (file_ptr->mask & GDB_WRITABLE)
- FD_CLR (fd, &gdb_notifier.check_masks[1]);
- if (file_ptr->mask & GDB_EXCEPTION)
- FD_CLR (fd, &gdb_notifier.check_masks[2]);
+ else
+ {
+ if (file_ptr->mask & GDB_READABLE)
+ FD_CLR (fd, &gdb_notifier.check_masks[0]);
+ if (file_ptr->mask & GDB_WRITABLE)
+ FD_CLR (fd, &gdb_notifier.check_masks[1]);
+ if (file_ptr->mask & GDB_EXCEPTION)
+ FD_CLR (fd, &gdb_notifier.check_masks[2]);
- /* Find current max fd. */
+ /* Find current max fd. */
- if ((fd + 1) == gdb_notifier.num_fds)
- {
- gdb_notifier.num_fds--;
- for (i = gdb_notifier.num_fds; i; i--)
+ if ((fd + 1) == gdb_notifier.num_fds)
{
- if (FD_ISSET (i - 1, &gdb_notifier.check_masks[0])
- || FD_ISSET (i - 1, &gdb_notifier.check_masks[1])
- || FD_ISSET (i - 1, &gdb_notifier.check_masks[2]))
- break;
+ gdb_notifier.num_fds--;
+ for (i = gdb_notifier.num_fds; i; i--)
+ {
+ if (FD_ISSET (i - 1, &gdb_notifier.check_masks[0])
+ || FD_ISSET (i - 1, &gdb_notifier.check_masks[1])
+ || FD_ISSET (i - 1, &gdb_notifier.check_masks[2]))
+ break;
+ }
+ gdb_notifier.num_fds = i;
}
- gdb_notifier.num_fds = i;
}
-#endif /* HAVE_POLL */
/* Deactivate the file descriptor, by clearing its mask,
so that it will not fire again. */
@@ -676,36 +685,43 @@ handle_file_event (int event_file_desc)
/* See if the desired events (mask) match the received
events (ready_mask). */
-#ifdef HAVE_POLL
- error_mask = POLLHUP | POLLERR | POLLNVAL;
- mask = (file_ptr->ready_mask & file_ptr->mask) |
- (file_ptr->ready_mask & error_mask);
- error_mask_returned = mask & error_mask;
-
- if (error_mask_returned != 0)
+ if (use_poll)
{
- /* Work in progress. We may need to tell somebody what
- kind of error we had. */
- if (error_mask_returned & POLLHUP)
- printf_unfiltered ("Hangup detected on fd %d\n", file_ptr->fd);
- if (error_mask_returned & POLLERR)
- printf_unfiltered ("Error detected on fd %d\n", file_ptr->fd);
- if (error_mask_returned & POLLNVAL)
- printf_unfiltered ("Invalid or non-`poll'able fd %d\n", file_ptr->fd);
- file_ptr->error = 1;
+#ifdef HAVE_POLL
+ error_mask = POLLHUP | POLLERR | POLLNVAL;
+ mask = (file_ptr->ready_mask & file_ptr->mask) |
+ (file_ptr->ready_mask & error_mask);
+ error_mask_returned = mask & error_mask;
+
+ if (error_mask_returned != 0)
+ {
+ /* Work in progress. We may need to tell somebody what
+ kind of error we had. */
+ if (error_mask_returned & POLLHUP)
+ printf_unfiltered ("Hangup detected on fd %d\n", file_ptr->fd);
+ if (error_mask_returned & POLLERR)
+ printf_unfiltered ("Error detected on fd %d\n", file_ptr->fd);
+ if (error_mask_returned & POLLNVAL)
+ printf_unfiltered ("Invalid or non-`poll'able fd %d\n", file_ptr->fd);
+ file_ptr->error = 1;
+ }
+ else
+ file_ptr->error = 0;
+#else
+ internal_error ("event-loop.c : use_poll without HAVE_POLL");
+#endif /* HAVE_POLL */
}
else
- file_ptr->error = 0;
-#else /* ! HAVE_POLL */
- if (file_ptr->ready_mask & GDB_EXCEPTION)
{
- printf_unfiltered ("Exception condition detected on fd %d\n", file_ptr->fd);
- file_ptr->error = 1;
+ if (file_ptr->ready_mask & GDB_EXCEPTION)
+ {
+ printf_unfiltered ("Exception condition detected on fd %d\n", file_ptr->fd);
+ file_ptr->error = 1;
+ }
+ else
+ file_ptr->error = 0;
+ mask = file_ptr->ready_mask & file_ptr->mask;
}
- else
- file_ptr->error = 0;
- mask = file_ptr->ready_mask & file_ptr->mask;
-#endif /* HAVE_POLL */
/* Clear the received events for next time around. */
file_ptr->ready_mask = 0;
@@ -731,9 +747,7 @@ gdb_wait_for_event (void)
file_handler *file_ptr;
gdb_event *file_event_ptr;
int num_found = 0;
-#ifdef HAVE_POLL
int i;
-#endif
/* Make sure all output is done before getting another event. */
gdb_flush (gdb_stdout);
@@ -742,108 +756,114 @@ gdb_wait_for_event (void)
if (gdb_notifier.num_fds == 0)
return -1;
+ if (use_poll)
+ {
#ifdef HAVE_POLL
- num_found =
- poll (gdb_notifier.poll_fds,
- (unsigned long) gdb_notifier.num_fds,
- gdb_notifier.timeout_valid ? gdb_notifier.timeout : -1);
-
- /* Don't print anything if we get out of poll because of a
- signal. */
- if (num_found == -1 && errno != EINTR)
- perror_with_name ("Poll");
-
-#else /* ! HAVE_POLL */
-
- gdb_notifier.ready_masks[0] = gdb_notifier.check_masks[0];
- gdb_notifier.ready_masks[1] = gdb_notifier.check_masks[1];
- gdb_notifier.ready_masks[2] = gdb_notifier.check_masks[2];
-
- num_found = select (gdb_notifier.num_fds,
- & gdb_notifier.ready_masks[0],
- & gdb_notifier.ready_masks[1],
- & gdb_notifier.ready_masks[2],
- gdb_notifier.timeout_valid
- ? &gdb_notifier.timeout : NULL);
-
- /* Clear the masks after an error from select. */
- if (num_found == -1)
- {
- FD_ZERO (&gdb_notifier.ready_masks[0]);
- FD_ZERO (&gdb_notifier.ready_masks[1]);
- FD_ZERO (&gdb_notifier.ready_masks[2]);
- /* Dont print anything is we got a signal, let gdb handle it. */
- if (errno != EINTR)
- perror_with_name ("Select");
- }
+ num_found =
+ poll (gdb_notifier.poll_fds,
+ (unsigned long) gdb_notifier.num_fds,
+ gdb_notifier.timeout_valid ? gdb_notifier.poll_timeout : -1);
+
+ /* Don't print anything if we get out of poll because of a
+ signal. */
+ if (num_found == -1 && errno != EINTR)
+ perror_with_name ("Poll");
+#else
+ internal_error ("event-loop.c : use_poll without HAVE_POLL");
#endif /* HAVE_POLL */
+ }
+ else
+ {
+ gdb_notifier.ready_masks[0] = gdb_notifier.check_masks[0];
+ gdb_notifier.ready_masks[1] = gdb_notifier.check_masks[1];
+ gdb_notifier.ready_masks[2] = gdb_notifier.check_masks[2];
+ num_found = select (gdb_notifier.num_fds,
+ & gdb_notifier.ready_masks[0],
+ & gdb_notifier.ready_masks[1],
+ & gdb_notifier.ready_masks[2],
+ gdb_notifier.timeout_valid
+ ? &gdb_notifier.select_timeout : NULL);
+ /* Clear the masks after an error from select. */
+ if (num_found == -1)
+ {
+ FD_ZERO (&gdb_notifier.ready_masks[0]);
+ FD_ZERO (&gdb_notifier.ready_masks[1]);
+ FD_ZERO (&gdb_notifier.ready_masks[2]);
+ /* Dont print anything is we got a signal, let gdb handle it. */
+ if (errno != EINTR)
+ perror_with_name ("Select");
+ }
+ }
+
/* Enqueue all detected file events. */
+ if (use_poll)
+ {
#ifdef HAVE_POLL
+ for (i = 0; (i < gdb_notifier.num_fds) && (num_found > 0); i++)
+ {
+ if ((gdb_notifier.poll_fds + i)->revents)
+ num_found--;
+ else
+ continue;
- for (i = 0; (i < gdb_notifier.num_fds) && (num_found > 0); i++)
- {
- if ((gdb_notifier.poll_fds + i)->revents)
- num_found--;
- else
- continue;
+ for (file_ptr = gdb_notifier.first_file_handler;
+ file_ptr != NULL;
+ file_ptr = file_ptr->next_file)
+ {
+ if (file_ptr->fd == (gdb_notifier.poll_fds + i)->fd)
+ break;
+ }
+
+ if (file_ptr)
+ {
+ /* Enqueue an event only if this is still a new event for
+ this fd. */
+ if (file_ptr->ready_mask == 0)
+ {
+ file_event_ptr = create_file_event (file_ptr->fd);
+ async_queue_event (file_event_ptr, TAIL);
+ }
+ }
+ file_ptr->ready_mask = (gdb_notifier.poll_fds + i)->revents;
+ }
+#else
+ internal_error ("event-loop.c : use_poll without HAVE_POLL");
+#endif /* HAVE_POLL */
+ }
+ else
+ {
for (file_ptr = gdb_notifier.first_file_handler;
- file_ptr != NULL;
+ (file_ptr != NULL) && (num_found > 0);
file_ptr = file_ptr->next_file)
{
- if (file_ptr->fd == (gdb_notifier.poll_fds + i)->fd)
- break;
- }
+ int mask = 0;
- if (file_ptr)
- {
+ if (FD_ISSET (file_ptr->fd, &gdb_notifier.ready_masks[0]))
+ mask |= GDB_READABLE;
+ if (FD_ISSET (file_ptr->fd, &gdb_notifier.ready_masks[1]))
+ mask |= GDB_WRITABLE;
+ if (FD_ISSET (file_ptr->fd, &gdb_notifier.ready_masks[2]))
+ mask |= GDB_EXCEPTION;
+
+ if (!mask)
+ continue;
+ else
+ num_found--;
+
/* Enqueue an event only if this is still a new event for
this fd. */
+
if (file_ptr->ready_mask == 0)
{
file_event_ptr = create_file_event (file_ptr->fd);
async_queue_event (file_event_ptr, TAIL);
}
+ file_ptr->ready_mask = mask;
}
-
- file_ptr->ready_mask = (gdb_notifier.poll_fds + i)->revents;
}
-
-#else /* ! HAVE_POLL */
-
- for (file_ptr = gdb_notifier.first_file_handler;
- (file_ptr != NULL) && (num_found > 0);
- file_ptr = file_ptr->next_file)
- {
- int mask = 0;
-
- if (FD_ISSET (file_ptr->fd, &gdb_notifier.ready_masks[0]))
- mask |= GDB_READABLE;
- if (FD_ISSET (file_ptr->fd, &gdb_notifier.ready_masks[1]))
- mask |= GDB_WRITABLE;
- if (FD_ISSET (file_ptr->fd, &gdb_notifier.ready_masks[2]))
- mask |= GDB_EXCEPTION;
-
- if (!mask)
- continue;
- else
- num_found--;
-
- /* Enqueue an event only if this is still a new event for
- this fd. */
-
- if (file_ptr->ready_mask == 0)
- {
- file_event_ptr = create_file_event (file_ptr->fd);
- async_queue_event (file_event_ptr, TAIL);
- }
- file_ptr->ready_mask = mask;
- }
-
-#endif /* HAVE_POLL */
-
return 0;
}
\f
@@ -1125,12 +1145,19 @@ poll_timers (void)
/* Now we need to update the timeout for select/ poll, because we
don't want to sit there while this timer is expiring. */
+ if (use_poll)
+ {
#ifdef HAVE_POLL
- gdb_notifier.timeout = delta.tv_sec * 1000;
+ gdb_notifier.poll_timeout = delta.tv_sec * 1000;
#else
- gdb_notifier.timeout.tv_sec = delta.tv_sec;
- gdb_notifier.timeout.tv_usec = delta.tv_usec;
-#endif
+ internal_error ("event-loop.c : use_poll without HAVE_POLL");
+#endif /* HAVE_POLL */
+ }
+ else
+ {
+ gdb_notifier.select_timeout.tv_sec = delta.tv_sec;
+ gdb_notifier.select_timeout.tv_usec = delta.tv_usec;
+ }
gdb_notifier.timeout_valid = 1;
}
else
From jimb@zwingli.cygnus.com Tue Mar 21 08:45:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: hjl@lucon.org, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Tue, 21 Mar 2000 08:45:00 -0000
Message-id: <npya7c6zn7.fsf@zwingli.cygnus.com>
References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org> <200003091210.HAA19857@indy.delorie.com>
X-SW-Source: 2000-03/msg00420.html
Content-length: 1326
> 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).
I hasten to point out that it's not *my* trick. :) That's just the
way the watchpoint code works.
Eli's test of the value's type is incorrect if the watch expression
contains a structure comparison, like (foo == bar) || (something
else), where foo and bar are structures. In that case, there will be
a value of type "struct", not at the end of the value list, but which
should be watched in its entirety.
To say that "nothing in GDB's code suggests that this assumption will
hold" is too passive. We should instead say, "Nothing in GDB's code
suggests that it would be difficult to make this assumption hold;
therefore, since it would be useful if it did hold, we will extend the
description of struct value with the requirement that non-lazy values
should contain only the portions of the objects actually used."
From eliz@delorie.com Tue Mar 21 10:17:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: jimb@cygnus.com
Cc: kettenis@wins.uva.nl, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: minor watchpoint code cleanup
Date: Tue, 21 Mar 2000 10:17:00 -0000
Message-id: <200003211817.NAA12429@indy.delorie.com>
References: <200003180006.TAA26919@zwingli.cygnus.com> <200003190944.EAA07454@indy.delorie.com> <200003192255.e2JMtcs00643@delius.kettenis.local> <200003200958.EAA09356@indy.delorie.com> <np7lex8j1u.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-03/msg00421.html
Content-length: 463
> Yes, yes, but does anyone have comments on my little patch? :)
Sorry, you are right.
I think this patch is a good idea, but I have one minor suggestion.
Instead of these two lines:
! size = (len > 4) ? 4 : len;
! size = size_try_array[size - 1][align];
I would suggest to write this:
size = size_try_array[len > 4 ? 3 : len - 1][align];
The reason is that IMHO we should avoid making a variable (`size')
serve two puproses at the same time.
From eliz@delorie.com Tue Mar 21 10:19:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ezannoni@cygnus.com
Cc: phdm@macqel.be, ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: HAVE_POLL is not enough - RFA
Date: Tue, 21 Mar 2000 10:19:00 -0000
Message-id: <200003211815.NAA12423@indy.delorie.com>
References: <200003181028.LAA30913@mail.macqel.be> <200003182226.RAA07052@indy.delorie.com> <14550.33984.488206.90007@kwikemart.cygnus.com>
X-SW-Source: 2000-03/msg00423.html
Content-length: 257
> I committed Eli's patch below.
Thanks!
It seems apology is in order: my previous message implied that I
posted that patch some time ago, while in reality I simply forgot to
post it. So there was nothing wrong with Elena not taking care of it.
Sorry!
From eliz@delorie.com Tue Mar 21 10:19:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: msnyder@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: gdb.texinfo broken?
Date: Tue, 21 Mar 2000 10:19:00 -0000
Message-id: <200003211819.NAA12435@indy.delorie.com>
References: <38D6CF69.6844@cygnus.com>
X-SW-Source: 2000-03/msg00422.html
Content-length: 328
> Following the recent spate of patches to gdb.texinfo,
> I find that I cannot build gdb.info; it's been a long
> time since I tried, so I do not know exactly when or
> with what patch it broke.
Can you post the error mesage(s) you get from "make info"? perhaps
they are descriptive enough to identify the offending line(s).
From msnyder@cygnus.com Tue Mar 21 10:46:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Document the ThreadInfo remote protocol queries
Date: Tue, 21 Mar 2000 10:46:00 -0000
Message-id: <38D7C38C.6CB0@cygnus.com>
References: <200003202316.PAA07888@cleaver.cygnus.com> <38D6FCE2.EBD9830F@cygnus.com>
X-SW-Source: 2000-03/msg00424.html
Content-length: 3697
Andrew Cagney wrote:
>
> Michael Snyder wrote:
> >
> > The following patch adds documentation to gdb.texinfo for the new
> > remote protocol queries "ThreadInfo" and "ThreadExtraInfo"
> > described in my previous patch.
> >
> > 2000-03-20 Michael Snyder <msnyder@cleaver.cygnus.com>
> >
> > * gdb.texinfo: Add new queries ThreadInfo and ThreadExtraInfo.
>
> > ! @item all thread ids
> > ! @tab @code{q}@code{fThreadInfo}
> > ! @item
> > ! @tab @code{q}@code{sThreadInfo}
> > @tab
> > + Obtain a list of active thread ids from the target (OS). Since there
> > + may be too many active threads to fit into one reply packet, this query
> > + works iteratively: it may require more than one query/reply sequence to
> > + obtain the entire list of threads. The first query of the sequence will
> > + be the @code{qf}@code{ThreadInfo} query; subsequent queries in the
> > + sequence will be the @code{qs}@code{ThreadInfo} query.
> > @item
> > ! @tab
> > ! @tab NOTE: replaces the @code{qL} query (see below).
> > @item
> > ! @tab reply @code{m}@var{<id>}
> > ! @tab A single thread id
> > ! @item
> > ! @tab reply @code{m}@var{<id>,}@var{<id>...}
> > ! @tab a comma-separated list of thread ids
> > ! @item
> > ! @tab reply @code{l}
> > ! @tab (lower case 'el') denotes end of list.
> > ! @item
> > ! @tab
> > ! @tab
> > ! In response to each query, the target will reply with a list of one
> > ! or more thread ids, in big-endian hex, separated by commas. GDB will
> > ! respond to each reply with a request for more thread ids (using the
> > ! @code{qs} form of the query), until the target responds with @code{l}
> > ! (lower-case el, for @code{'last'}).
> > !
> > ! @item extra thread info
> > ! @tab @code{qfThreadExtraInfo,}@var{<id>}
> > ! @tab
> > ! @item
> > ! @tab
> > ! @tab
> > ! Where @var{<id>} is a thread-id in big-endian hex.
> > ! Obtain a printable string description of a thread's attributes from
> > ! the target OS. This string may contain anything that the target OS
> > ! thinks is interesting for @value{GDBN} to tell the user about the thread.
> > ! The string is displayed in @value{GDBN}'s @samp{info threads} display.
> > ! Some examples of possible thread extra info strings are "Runnable", or
> > ! "Blocked on Mutex".
> > ! @item
> > ! @tab reply @var{XX...}
> > ! @tab
> > ! Where @var{XX...} is a hex encoding of @sc{ascii} data, comprising the
> > ! printable string containing the extra information about the thread's
> > ! attributes.
> >
> > @item query @var{LIST} or @var{threadLIST} @strong{(deprecated)}
> > @tab @code{q}@code{L}@var{startflag}@var{threadcount}@var{nextthread}
>
> An additional note on these versions of thread queries. While
> significantly better than the ``qL'' packet these commands still have
> problems. I'll add notes expanding on this. Briefly, however:
>
> o Per the query packet spec, they should be
> prefixed with a UCASE letter if they
> are to be official GDB packets.
>
> o The ``sThread..'' command assumes
> that the GDB protocol is reliable
> which it is not. GDB can re-issue
> a ``sThread'' request and this can
> lead to GDB and the target falling
> out of sync.
How about if the 'sThread' request were to be suffixed with
the last thread ID received?
> with regard to ``qfThreadExtraInfo''. As far as I know its not been
> deployed in the field. Is there any reason to not name it correctly
> from the start (``qThreadExtraInfo'')?
Only that it conflicts with the tracepoint messages,
which all begin with qT (see tracepoint.c).
Michael
From shebs@apple.com Tue Mar 21 11:12:00 2000
From: Stan Shebs <shebs@apple.com>
To: Michael Snyder <msnyder@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: gdb.texinfo broken?
Date: Tue, 21 Mar 2000 11:12:00 -0000
Message-id: <38D7C962.5698D656@apple.com>
References: <38D6CF69.6844@cygnus.com>
X-SW-Source: 2000-03/msg00426.html
Content-length: 409
Michael Snyder wrote:
>
> Following the recent spate of patches to gdb.texinfo,
> I find that I cannot build gdb.info; it's been a long
> time since I tried, so I do not know exactly when or
> with what patch it broke.
I'm pretty sure I tested with a "make info" in the objdir
the last time I checked in, but I'm not convenient to a
system I can retest this with; what error messages are you
getting?
Stan
From msnyder@cygnus.com Tue Mar 21 11:12:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: gdb.texinfo broken?
Date: Tue, 21 Mar 2000 11:12:00 -0000
Message-id: <38D7C977.FA3@cygnus.com>
References: <38D6CF69.6844@cygnus.com> <200003211819.NAA12435@indy.delorie.com>
X-SW-Source: 2000-03/msg00425.html
Content-length: 3784
Eli Zaretskii wrote:
>
> > Following the recent spate of patches to gdb.texinfo,
> > I find that I cannot build gdb.info; it's been a long
> > time since I tried, so I do not know exactly when or
> > with what patch it broke.
>
> Can you post the error mesage(s) you get from "make info"? perhaps
> they are descriptive enough to identify the offending line(s).
Sure.
%] msnyder<2>% make gdb.info
makeinfo -I
/cleaver/blade/msnyder/sourceware/src/gdb/doc/../../readline/doc -I
/cleaver/blade/msnyder/sourceware/src/gdb/doc -o ./gdb.info gdb.texinfo
Making info file `./gdb.info' from `gdb.texinfo'.
gdb.texinfo:113: No matching `@end ifnottex'.
gdb.texinfo:156: Unmatched `@end'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:52: Node
`Top' multiply defined (line 114 is first definition at).
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:53: Node
with @top as a section already exists.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:114: Here is
the @top node.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:121: Node
`Server' multiply defined (line 9531 is first definition at).
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:260: Node
`Frames' multiply defined (line 3554 is first definition at).
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:604: Node
`Running' multiply defined (line 1417 is first definition at).
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:673: Node
`Source' multiply defined (line 3845 is first definition at).
gdb.texinfo:12673: Node `Index' multiply defined (line 712 is first
definition at).
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:11874: Next
reference to nonexistent node `Annotations'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:79: Node
`General''s Next field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:9531: This
node (`Server') is the one with the bad `Prev'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:134: Node
`Values''s Next field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:3554: This
node (`Frames') is the one with the bad `Prev'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:134: Node
`Values's Prev field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:9531: This
node (`Server') has the bad Next.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:393: Node
`Displays's Prev field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:3554: This
node (`Frames') has the bad Next.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:584: Node
`Invalidation''s Next field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:1417: This
node (`Running') is the one with the bad `Prev'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:695: Node
`TODO's Prev field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:3845: This
node (`Source') has the bad Next.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:12050: Prev
reference to nonexistent node `Annotations'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:12381: Node
`Installing GDB''s Next field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:712: This
node (`Index') is the one with the bad `Prev'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:928: Cross
reference to nonexistent node `Annotations'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:145: Menu
reference to nonexistent node `Annotations'.
makeinfo: Removing output file `./gdb.info' due to errors; use --force
to preserve.
make: *** [gdb.info] Error 2
%] msnyder<3>%
From msnyder@cygnus.com Tue Mar 21 11:15:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: shebs@apple.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: gdb.texinfo broken?
Date: Tue, 21 Mar 2000 11:15:00 -0000
Message-id: <38D7CA41.3647@cygnus.com>
References: <38D6CF69.6844@cygnus.com> <38D7C962.5698D656@apple.com>
X-SW-Source: 2000-03/msg00427.html
Content-length: 3933
Stan Shebs wrote:
>
> Michael Snyder wrote:
> >
> > Following the recent spate of patches to gdb.texinfo,
> > I find that I cannot build gdb.info; it's been a long
> > time since I tried, so I do not know exactly when or
> > with what patch it broke.
>
> I'm pretty sure I tested with a "make info" in the objdir
> the last time I checked in, but I'm not convenient to a
> system I can retest this with; what error messages are you
> getting?
Not to make you hunt for my previous reply to Eli Z,
here they are again.
%] msnyder<2>% make gdb.info
makeinfo -I
/cleaver/blade/msnyder/sourceware/src/gdb/doc/../../readline/doc -I
/cleaver/blade/msnyder/sourceware/src/gdb/doc -o ./gdb.info gdb.texinfo
Making info file `./gdb.info' from `gdb.texinfo'.
gdb.texinfo:113: No matching `@end ifnottex'.
gdb.texinfo:156: Unmatched `@end'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:52: Node
`Top' multiply defined (line 114 is first definition at).
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:53: Node
with @top as a section already exists.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:114: Here is
the @top node.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:121: Node
`Server' multiply defined (line 9531 is first definition at).
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:260: Node
`Frames' multiply defined (line 3554 is first definition at).
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:604: Node
`Running' multiply defined (line 1417 is first definition at).
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:673: Node
`Source' multiply defined (line 3845 is first definition at).
gdb.texinfo:12673: Node `Index' multiply defined (line 712 is first
definition at).
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:11874: Next
reference to nonexistent node `Annotations'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:79: Node
`General''s Next field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:9531: This
node (`Server') is the one with the bad `Prev'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:134: Node
`Values''s Next field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:3554: This
node (`Frames') is the one with the bad `Prev'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:134: Node
`Values's Prev field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:9531: This
node (`Server') has the bad Next.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:393: Node
`Displays's Prev field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:3554: This
node (`Frames') has the bad Next.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:584: Node
`Invalidation''s Next field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:1417: This
node (`Running') is the one with the bad `Prev'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:695: Node
`TODO's Prev field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:3845: This
node (`Source') has the bad Next.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:12050: Prev
reference to nonexistent node `Annotations'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:12381: Node
`Installing GDB''s Next field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:712: This
node (`Index') is the one with the bad `Prev'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:928: Cross
reference to nonexistent node `Annotations'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:145: Menu
reference to nonexistent node `Annotations'.
makeinfo: Removing output file `./gdb.info' due to errors; use --force
to preserve.
make: *** [gdb.info] Error 2
%] msnyder<3>%
From guo@cup.hp.com Tue Mar 21 11:17:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: Michael Snyder <msnyder@cygnus.com>
Cc: John David Anglin <dave@hiauly1.hia.nrc.ca>, gdb-patches@sourceware.cygnus.com
Subject: Re: Initialization of hpux_threads
Date: Tue, 21 Mar 2000 11:17:00 -0000
Message-id: <Pine.LNX.4.10.10003211208350.31096-100000@hpcll168.cup.hp.com>
References: <38D2CB7D.24B6@cygnus.com>
X-SW-Source: 2000-03/msg00428.html
Content-length: 1266
On Fri, 17 Mar 2000, Michael Snyder wrote:
>John David Anglin wrote:
>>
>> Thu Mar 16 16:49:27 EST 2000 John David Anglin <dave@hiauly1.hia.nrc.ca>
>>
>> * configure.in: Don't call _initialize_hpux_thread twice.
>> * configure: Regenerated.
>>
>> --- configure.in.orig Mon Mar 6 18:30:12 2000
>> +++ configure.in Thu Mar 16 14:22:26 2000
>> @@ -330,7 +330,6 @@
>> AC_DEFINE(HAVE_HPUX_THREAD_SUPPORT)
>> CONFIG_OBS="${CONFIG_OJS} hpux-thread.o"
>> CONFIG_SRCS="${CONFIG_SRCS} hpux-thread.c"
>> - CONFIG_INITS="${CONFIG_INITS} hpux-thread.c"
>> else
>> AC_MSG_RESULT(no (suppressed because you are not using GCC))
>> fi
>
>If someone from HP will approve this, I will check it in...
>
> Michael Snyder
This looks fine. Just an observation:
CONFIG_OBS is part of DEPFILES, which is part of COMMON_OBS, which is
part of OBS, which is part of INITFILES. It looks like all three usages
of CONFIG_INITS in configure.in can be removed. Maybe you can just
remove CONFIG_INITS altogether in configure.in and Makefile.in. Since
OBS file list is already looked at by init.c rule, it really makes no
sense to maintain a CONFIG_INITS file list.
- Jimmy
^ permalink raw reply [flat|nested] only message in thread