strace on 64 bit host can't trace reads() of 32-bit app?
Dmitry V. Levin
ldv at altlinux.org
Fri Feb 18 01:01:25 UTC 2011
On Fri, Feb 18, 2011 at 01:46:02AM +0300, Dmitry V. Levin wrote:
> On Wed, Feb 09, 2011 at 04:10:13AM +0300, Dmitry V. Levin wrote:
> > On Thu, Feb 03, 2011 at 12:10:01AM +0300, Dmitry V. Levin wrote:
> > > On Wed, Feb 02, 2011 at 02:38:29PM -0500, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > > >
> > > > Could you please confirm the limitation noted in $subject?
> > >
> > > Yes, this is a known issue I hope to fix.
> >
> > I've just pushed a fix to the git HEAD, you can find it at
> > http://strace.git.sourceforge.net/git/gitweb.cgi?p=strace/strace;a=commitdiff;h=v4.5.20-64-g65c1a81
>
> Just a few words explaining the fix.
>
> I had to replace switch(known_scno(tcp)) with a bunch of
> sysent[tcp->scno].sys_func checks because __NR_read == 0 on x86-64 and
> known_scno() consequently treats sysent[tcp->scno].native_scno
> initialized with __NR_read as uninitialized.
>
> This __NR_read case seems to be the only collision because on other
> architectures syscall number 0 is usually assigned to__NR_restart_syscall.
> Therefore, other uses of known_scno() should be safe.
Unfortunately, it is not safe. Commit v4.5.14-41-gb2f8699 demonstrates
another kind of collision: __NR_umask on i386 is the same as __NR_exit in
x86-64, but umask entry in linux/i386/syscallent.h does not define
native_scno. As result, any use of SYS_exit constant on x86-64 is unsafe.
--
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/20110218/a7392302/attachment.bin>
More information about the Strace-devel
mailing list