Q: can rlim_t be a long long type on linux
vapier at gentoo.org
Mon Mar 19 00:48:33 UTC 2012
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"
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the Strace-devel