From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philippe GIACINTI To: Michael Snyder Cc: Philippe GIACINTI , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] minor fixes in remote.c Date: Mon, 20 Mar 2000 23:38:00 -0000 Message-id: <14551.9944.573865.671433@gargle.gargle.HOWL> References: <14549.49859.878539.158465@gargle.gargle.HOWL> <38D6B3B4.1F73@cygnus.com> X-SW-Source: 2000-03/msg00413.html Michael Snyder 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 To: Kevin Buettner 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 To: Jim Blandy 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> <38C223E1.43260416@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 To: Eli Zaretskii , Mark Kettenis 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/ 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 To: Stephane Carrez 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" 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 * 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 -#else +#endif #include #include -#endif #include #include #include @@ -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; } @@ -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 To: Eli Zaretskii 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: 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 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> 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 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 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 To: Andrew Cagney 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 > > > > * 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{} > > ! @tab A single thread id > > ! @item > > ! @tab reply @code{m}@var{,}@var{...} > > ! @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{} > > ! @tab > > ! @item > > ! @tab > > ! @tab > > ! Where @var{} 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 To: Michael Snyder 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 To: Eli Zaretskii 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 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 To: Michael Snyder Cc: John David Anglin , gdb-patches@sourceware.cygnus.com Subject: Re: Initialization of hpux_threads Date: Tue, 21 Mar 2000 11:17:00 -0000 Message-id: 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 >> >> * 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