Q: can rlim_t be a long long type on linux

[Mike Frysinger]

On Saturday 17 March 2012 13:17:30 Dmitry V. Levin wrote:
> On Fri, Mar 16, 2012 at 05:45:51PM -0400, Mike Frysinger wrote:
> > On Friday 16 March 2012 16:18:33 Andreas Schwab wrote:
> > > "Dmitry V. Levin" writes:
> > > > Is it correct that rlim_t cannot be a long long type on linux,
> > > > or am I missing something?
> > > 
> > > x32 is going to be the first.
> > 
> > mips/n32 doesn't ?
> 
> btw, how one can reliably identify that kind of information
> just looking at the kernel?

i'm not sure.  when we get into ABI's that don't follow the common 32bit/64bit 
split behavior, it can get ugly fast.  on the mips side, all those _MIPS_SZxxx 
defines are coming from gcc itself.

for our purposes, not sure if it'd be best to just start a local doc that 
listed the sizes/etc... for target arches/abis.

> For example, we have an oddness in file.c with several different
> definitions of sys_lseek, one for HAVE_LONG_LONG_OFF_T, another for
> !HAVE_LONG_LONG_OFF_T, and yet another one for LINUX_MIPSN32 where
> off_t is actually emulated via "long long".  How could it be that
> off_t is not a "long long" type but lseek takes a "long long"
> argument?

my guess is that the mips logic is attempting to handle strace compiled as one 
ABI but to trace another.  if you build it as o32, then the LONG_LONG_OFF_T 
detection will have no bearing at all if you trace an n64 or n32 binary.  or 
built an n32 strace and attempted to trace an o32 ELF.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20120318/ebdf6f8c/attachment.bin>