Date: Wed, 29 May 1996 11:39:06 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: kaleb@x.org (Kaleb S. KEITHLEY) Cc: terry@lambert.org, hackers@freefall.freebsd.org Subject: Re: Forgiving select() call. Message-ID: <199605291839.LAA13936@phaeton.artisoft.com> In-Reply-To: <199605290115.VAA20117@exalt.x.org> from "Kaleb S. KEITHLEY" at May 28, 96 09:15:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Trace it on a SunOS 4.1.3 *box*. > > Obviously it will say select on a 4.1.3 box. So what? The question > that has led us down this primrose path is whether Solaris has select. Look. The thing is going to push *select* arguments on the stack, and then trap 93. This won't change when you run it under ABI emulation as opposed to running it in it's native environment. Whatever is in the frigging kernel is decoding *select* arguments (not *poll* arguments) off the user stack. That makes it *select*, in my book. > > A statically linked 4.1.3 binary will trap the select(2) stub through > > trap entry 93. > > What evidence do you have that it's even trapping? Everything could be > handled in the library and truss could be telling the truth -- that it's > using poll. We do know how truss works. It traps, and inspects the > processor state to see what triggered the trap. I disassembled it and saw "trap". Pretty damn obvious. The library isn't going to change because it's *statically* (HELLO, *STATICALLY*) linked. > > Poll's merits are on the basis of an improper implementation of select. > > Well, that's the first time *that* has come up. Pray tell, now what's > wrong with select. It blows it's shorts afer FD_SETSIZE fd's in the most recent release, but not in -current. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605291839.LAA13936>