This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: HAVE_POLL is not enough
- To: "Philippe De Muyter" <phdm at macqel dot be>
- Subject: Re: HAVE_POLL is not enough
- From: Elena Zannoni <ezannoni at cygnus dot com>
- Date: Wed, 1 Mar 2000 14:37:35 -0500 (EST)
- Cc: ac131313 at cygnus dot com (Andrew Cagney), ezannoni at cygnus dot com, gdb-patches at sourceware dot cygnus dot com
- References: <38BCBC3F.56354ECB@cygnus.com><200003011430.PAA03609@mail.macqel.be>
Philippe De Muyter writes:
> First of all, sorry for the long delay for answers, but I am really busy
> (and more) with my day-hours work.
>
> > Elena Zannoni wrote:
> > >
> > > Philippe De Muyter writes:
> > > > With the gdb cvs tree of 2000-02-19, on m68k-motorola-sys, configure
> > > > correctly detect that we have `poll', but gdb incorrectly assumes that
> > > > `poll' can be used to wait for `stdin'. On m68k-motorola-sysv, tty's
> > > > are not stream-based and not `poll'able. Should the configure test
> > > > be enhanced ? I don't think so if we need to run a target program to check
> > > > that, because it would fail if we cross-compile gdb, but if it can be
> > > > determined by other ways, like the presence of some constants in some
> > > > header files then I would agree. We could also always compile in the `poll'
> > > > version if HAVE_POLL, but switch to the the fall-back method at run time if
> > > > poll fails with POLLNVAL.
> > > >
> > >
> > > Right now the decision on whether to run gdb with or without the event
> > > loop is determined by the user as start up, and it is not detected
> > > neither by configure or at run time. The easiest thing to do for now
>
> I did not ask explicitly to start gdb with or without the event-loop, and it
> tried automatically to use the event-loop. I don't know why but that seems
> to invalidate Elena's statement that `it is determined by the user as start up'.
>
Sorry, that was unclear, there is a --noasync switch you can start up
gdb with and that will not use the event loop, but the old command
loop. (assuming it hasn't suffered from bitrot).
Elena
> > > is probably tell the user what happened and switch to
> > > non-event-loop mode. Maybe some configury work could be done to
> > > determine whether the tty's can be pollable, I am not familiar with
> > > your system enough to know whether this is anything feasible. Sorry I
> > > cannot be of more help here.
> > > How about the 'target async' part, would that work?
> >
> > As far as I know, this problem is still present.
> >
> > Following on from Elena's comment. Is there any known work around or
> > other hack available?
> >
> > If we get really desparate there is always the option of putting:
> >
> > HOST_POLL_BROKEN
> >
> > in
> >
> > config/m68k/xm-m68kv4.h
> >
> > :-( (And yes, I'm about to get really desperate).
> >
> > Philippe, if GDB is forced to use select, does it work?
>
> If we never use poll, and always use select if it is available, I think
> we'll then have the inverse problem : platforms where some channels are
> `poll'-able, but not `select'-able.
>
> So, my idea is : at gdb startup, first poll the needed fd's one by one with
> a null or small timeout, and if one is not `poll'-able, then switch to `select'.
> I know that on m68k-motorola-sysv, `stdin' is `select'-able, so this scheme
> would work.
>
> Sorry, no time for a patch at the moment.
>
> >
> > Andrew
> >
>