[PATCH] Fix {get, set}rlimit decoding with unreliable SIZEOF_RLIM_T

[Dmitry V. Levin]

Hi,

On Fri, May 02, 2014 at 02:15:41PM +0100, James Hogan wrote:
> When strace is built with large file support definitions in CFLAGS (as
> may be provided by buildroot) the C library headers may expose a 64-bit
> rlim_t even though the struct rlimit fields used by the system call
> interface are only 32-bit. The SIZEOF_RLIM_T will then be 8 which
> results in bad decoding of the getrlimit and setrlimit syscalls.

If SIZEOF_RLIM_T cannot be relied upon, it shouldn't be used, and its
definition has to be removed as well.

> This is fixed by removing the "#if SIZEOF_RLIM_T == 4 ||
> SUPPORTED_PERSONALITIES > 1" conditional, since the remaining code
> already handles multiple personalities based on the value of
> current_wordsize, which is set correctly even for a single personality.

I have two questions wrt this patch:

1. Removing the conditional would result with print_rlimit32 defined for
all architectures, including pure 64bit ones.  I suppose we need a check
like this anyway:

#if PERSONALITY0_WORDSIZE == 4 || \
    (SUPPORTED_PERSONALITIES > 1 && PERSONALITY1_WORDSIZE == 4) || \
    (SUPPORTED_PERSONALITIES > 2 && PERSONALITY2_WORDSIZE == 4)

2. I'm not sure about architectures where kernel wordsize is 8 but user
wordsize is 4 (like x32 and mips n32); what's the correct rlim_t for these
architectures?


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20140514/efe3afbe/attachment.bin>