On Fri, Nov 08, 2013 at 12:27:18PM +0100, Denys Vlasenko wrote: > On 11/06/2013 01:06 AM, Dmitry V. Levin wrote: > > Looks like all FD_ISSET implementations just test the n-th bit in the > > array of long ints. I've pushed a commit with yet another FD_ISSET > > implementation that hopefully does the same. > > > >> On the related note, how are we doing in "stracing 32-bit app > >> with 64-bit strace on a big-endian machine" case? > >> In that case, sizeof(long) is important... > >> I dread to think about that:( > > > > We cannot make things worse than they were since the beginning. :) > > Testing each bit with FD_ISSET is silly in any case, so I attempted to fix > both "bit-endian wordsize bug" and performance problem in one go, > by introducing a next_set_bit() function which just gives us > a next bit's position. > > It skips over entire zero bytes. By using bytes instead of words, > it can walk bytes in big-endian sequence suitable for current_wordsize > without the need of awkward code to access a runtime-variable-width word. > > It also skips zero bytes even in not-fully zeroed words, > which may be a win on speed. > > Run-tested, although I do not have the environment to reproduce > the bit-endian wordsize bug. > > Dmitry, please review. > Patch #2 just syncs up select decoding in pathtrace.c with the main one.
Nice fix, thanks. There is a typo in comment, though. :) -- ldv
pgpLhQ6Cgz2_5.pgp
Description: PGP signature
------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________ Strace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/strace-devel
