This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Fri, Jan 01, 2016 at 11:05:04PM -0500, Mike Frysinger wrote: > On 31 Dec 2015 23:28, Aurelien Jarno wrote: > > I have found some times to investigate. It seems there is no issue, my > > bad. I just discovered that on s390x, syscalls numbers above 256 are > > actually a a call to syscall 0 with the syscall number passed in > > register %r1. My version of strace was not aware of the new syscalls > > and presented them as syscall setup(). Sorry for the false alert. > > is this a bug in strace ? does it not handle `svc 0` insns correctly ? > if so, we should fix that. i assumed the kernel would put the correct > NR into the r1 register regardless of how the syscall was invoked, but > maybe i'm being naive. It's https://bugs.debian.org/485979 strace assumes that syscall number on s390/s390x is available in %r2, which is correct both for "svc NR" and "svc 0 %r1=NR" methods unless NR >= kernel's NR_syscalls. In the latter case, %r2 is set to 0 but the original value that was stored in %r1 is also available for a tracer. I've pushed a fix (strace commit v4.11-159-g1763fa5) for this longstanding issue. -- ldv
Attachment:
pgp5nikVuGiur.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |