This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: HAVE_POLL is not enough


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
> > 
> 

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]