strace seg with select and -ve nfds

[Denys Vlasenko]

On 11/05/2013 07:27 PM, Dr. David Alan Gilbert wrote:
> * Denys Vlasenko (dvlasenk at redhat.com) 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.