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>, ac131313 at cygnus dot com
- Subject: RE: HAVE_POLL is not enough
- From: Donn Terry <donnte at microsoft dot com>
- Date: Wed, 1 Mar 2000 09:27:26 -0800
- Cc: ezannoni at cygnus dot com, gdb-patches at sourceware dot cygnus dot com
I'm in a similar boat, except that:
Only poll() works some places (/proc).
Only select() works other places (pty/tty).
(This is a consequence of a "step in the right
direction", but the 2d step hasn't happened yet.)
Writing the /proc stuff to dynamically switch would
be a pain (at best).
The test really belongs in configure, but lacking
that it probably belongs in the manually configured
header files. (Something along the lines of
(for the default):
#ifdef HAVE_POLL
#define USE_POLL_ON_PROC
#define USE_POLL_ON_TTY
#else
#undef USE_POLL_ON_PROC
#undef USE_POLL_ON_TTY
#endif
For special cases (using mine as an example):
#undef USE_POLL_ON_TTY
#undef USE_POLL_ON_PROC // Just for error prevention
#define USE_POLL_ON_PROC
Donn Terry
Speaking only for myself, of course.
> -----Original Message-----
> From: Philippe De Muyter [mailto:phdm@macqel.be]
> Sent: None
> To: ac131313@cygnus.com
> Cc: ezannoni@cygnus.com; gdb-patches@sourceware.cygnus.com
> Subject: Re: HAVE_POLL is not enough
>
>
> 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'.
>
> > > 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
> >
>