[prev in list] [next in list] [prev in thread] [next in thread] 

List:       strace
Subject:    Re: strace on 64 bit host can't trace reads() of 32-bit app?
From:       "Dmitry V. Levin" <ldv () altlinux ! org>
Date:       2011-02-18 1:01:25
Message-ID: 20110218010125.GA13843 () altlinux ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

[Attachment #5 (application/pgp-signature)]

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb

_______________________________________________
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel


[prev in list] [next in list] [prev in thread] [next in thread]