bug-hurd: Could somebody please take a look at this?
On Thu, Nov 20, 2003 at 03:00:04AM +0100, Frank Heckenbach wrote:
> > On Wed, Nov 19, 2003 at 04:26:48AM +0100, Frank Heckenbach wrote:
> > > I suppose so. If you can get the arguments and return value of the
> > > libc function select() (it should be called exactly once), this
> > > might be just as good, i.e.:
> >
> > (gdb) b rts.c:2003
> > Breakpoint 1 at $806523a: file
> > /var/lib/buildd/build/mbanck/gcc-3.3-3.3.2ds5/src/gcc/p/rts/rts.c, line 2003.
> > (gdb) r /bin/sh
> > Starting program:
> > /var/lib/buildd/build/mbanck/gcc-3.3-3.3.2ds5/build/gcc/p/test/a.out /bin/sh
> >
> > Breakpoint 1, _p_SelectHandle (Count=1, Events=0x1017a10,
> > MicroSeconds=72472659677413377)
> > at /var/lib/buildd/build/mbanck/gcc-3.3-3.3.2ds5/src/gcc/p/rts/rts.c:2003
> > 2003 Result = select (n, &readfds, &writefds, &exceptfds, ptimeout);
> > Current language: auto; currently c
> > (gdb) p n
> > $1 = 9
> > (gdb) p readfds
> > $2 = {fds_bits = {256, 0, 0, 0, 0, 0, 0, 0}}
> > (gdb) p writefds
> > $3 = {fds_bits = {0, 0, 0, 0, 0, 0, 0, 0}}
> > (gdb) p exceptfds
> > $4 = {fds_bits = {0, 0, 0, 0, 0, 0, 0, 0}}
> > (gdb) p *ptimeout
> > $5 = {tv_sec = 0, tv_usec = 0}
> > (gdb) n
> > 2004 for (i = 0; i < Count; i++)
> > (gdb) p Result
> > $6 = 16873856
>
> This number looks odd, but it might be due to debugging an optimized
> program (provided you built the compiler with optimizations). Please
> try (at this point) `fin', and note the returned value.
(gdb) n
2004 for (i = 0; i < Count; i++)
(gdb) p Result
$2 = 16873856
(gdb) fin
Run till exit from #0 _p_SelectHandle (Count=1, Events=0x1017a10,
MicroSeconds=72472659677413377)
at
/var/lib/buildd/build/mbanck/gcc-3.3-3.3.2ds5/src/gcc/p/rts/rts.c:2004
_p_Select (Events=0x1017a94, Low=1, Count=1, MicroSeconds=0)
at
/var/lib/buildd/build/mbanck/gcc-3.3-3.3.2ds5/src/gcc/p/rts/file.c:1823
1823 for (i = 0; i < Count; i++)
Value returned is $3 = 0
> If it's still such a strange number, then something's wrong here.
>
> If it's 0 (which I suppose), then there might be something strange
> about the Hurd's behaviour of select:
>
> One file to test for reading is given (which is readable in fact),
> and the timeout is 0. I'd expect select to return "readable" then.
>
> I'm not sure if that's the official behaviour (which might be
> difficult to define, since select isn't even POSIX AFAIK), but the
> Linux manpage says:
>
> : timeout is an upper bound on the amount of time elapsed
> : before select returns. It may be zero, causing select to
> : return immediately.
>
> If it didn't test any files in case of zero timeout, this would at
> least be useless.
>
> This might have to be discussed with the Hurd developers then.
> Here's a C program which should test the equivalent thing (gives 1
> on my Linux box, will probably give 0 on the Hurd). If the Hurd's
> behaviour is correct (or acceptable), we'll have to change the test
> program (try with `IOSelectRead (s, 1)' then).
>
> #include <sys/time.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <unistd.h>
> #include <stdio.h>
>
> int main ()
> {
> int f = open ("/bin/sh", O_RDONLY);
> fd_set r;
> struct timeval t;
> t.tv_sec = t.tv_usec = 0;
> FD_ZERO (&r);
> FD_SET (f, &r);
> printf ("%i\n", select (f + 1, &r, NULL, NULL, &t));
> return 0;
> }
That program indeed returns '0' on my GNU/Hurd box and '1' on my
GNU/Linux box.
Michael
PS: The gpc test program in question is:
The gpc test program in question is:
program fjf663;
uses GPC;
var
f: ^Text;
s: array [1 .. 1] of PAnyFile;
begin
if (ParamStr (1) = '') or (ParamStr (1) = '-') then
begin
WriteLn ('failed: ParamStr (1) is empty');
Halt
end;
repeat
New (f);
Reset (f^, ParamStr (1))
until FileHandle (f^) >= 8;
s[1] := f;
case IOSelectRead (s, 0) of
1: WriteLn ('OK');
-1: WriteLn ('SKIPPED: IOSelectRead not supported on this system');
else WriteLn ('failed')
end
end.
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
