## Re: strace seg with select and -ve nfds

 Re: strace seg with select and -ve nfds From: Denys Vlasenko - 2013-11-06 10:55:14 ```On 11/05/2013 07:27 PM, Dr. David Alan Gilbert wrote: > * Denys Vlasenko (dvlasenk@...) wrote: >> 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:( > > Yeh that's kind of related to the question I asked in my 1st post; > since we're getting passed args here as long* and this is actually > an int does this work at all on BE machines? > Is there GET_ARG_INT thing in strace this routine should be using? You misunderstood me. The question is not about arg being longs or ints - that is properly covered (or else EVERY syscall would be horribly broken). I'm talking about the long[] arrays pointed by arg[1,2,3]. In 32-bit process, those arrays have 32-bit "longs". If strace is 64-bit, strace's "longs" are 64-bit. Finding an Nth bit via long_array[fd / BITS_PER_LONG] & (1UL << (fd % BITS_PER_LONG)) works if we have a correct idea about sizeof(long), and it also works correctly on little endian even if we don't: fd = 32 if long is 32-bit: long_array[1] & (1 << 0) -- checks bit 0 in 4th byte if long is 64-bit: long_array[0] & (1 << 32) -- checks bit 0 in 4th byte But on big-endian we have a disaster fd = 32 if long is 32-bit: long_array[1] & (1 << 0) -- checks bit 0 in 7th byte if long is 64-bit: long_array[0] & (1 << 32) -- checks bit 0 in 3rd byte NOT THE SAME! > Yeh mixed ABI is hard - and things mix ABI in different ways, > some systems have to have it in different processes (in which > case two strace binaries might do it) This won't work if you want to strace across execve which execs a different-bitness process. ```