Date: Wed, 29 May 1996 15:56:32 EST From: "Kaleb S. KEITHLEY" <kaleb@x.org> To: Terry Lambert <terry@lambert.org> Cc: hackers@freefall.FreeBSD.org Subject: Re: Forgiving select() call. Message-ID: <199605291956.PAA23238@exalt.x.org> In-Reply-To: Your message of Wed, 29 May 1996 11:39:06 EST. <199605291839.LAA13936@phaeton.artisoft.com>
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. No Terry, you look. Why don't you try this stuff for yourself instead of making wild assed guesses and amazing assertions like "truss is lying." > > 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. Is this just guessing on your part? > Whatever is in the frigging kernel is decoding *select* arguments > (not *poll* arguments) off the user stack. You haven't proven that the select arguments are being decoded in the kernel at all. > That makes it *select*, in my book. As opposed to what truss says the kernel is doing. Truss seems to get everything else right. Is this just an astronomically huge coincidence that truss is broken when it comes to select? Even if it is there, who really gives a fuck? It isn't there for mere mortals to use, so for all practical purposes, it isn't there. You can't write a native mode program that references select that won't use poll. You can't write a native mode program that uses the syscall interface and get anything except poll. But the reality is, it ain't there. > > > 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. HELLO! HELLO TERRY! IS THERE ANYONE HOME? Have you actually run the a SunOS binary on Solaris or are you just talking out of your ass? Even though it's statically linked, truss shows that more than a few shared libraries are loaded from /usr/4lib and /usr/ucblib. It even loads /usr/lib/libc at runtime. You can't prove that the traps aren't fixed up by the loader or the ABI runtime before the code is executed. Do tell, is truss is lying again? > > > 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. This has nothing to do with whether select is better or worse than poll. Darken my email doorstep no more with this crap. -- Kaleb KEITHLEY
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605291956.PAA23238>