On 27 Feb 2015 00:36, Dmitry V. Levin wrote: > On Thu, Feb 26, 2015 at 02:16:13PM -0500, Mike Frysinger wrote: > > The parisc kernel has some legacy baggage here and decodes the 64bit > > field in the reverse order. Handle it in strace too. > > > > * fanotify.c [HPPA] (sys_fanotify_mark): Reverse the mask bits. > > --- > > fanotify.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/fanotify.c b/fanotify.c > > index e421b01..63816b8 100644 > > --- a/fanotify.c > > +++ b/fanotify.c > > @@ -52,6 +52,10 @@ sys_fanotify_mark(struct tcb *tcp) > > * but kernel uses the lower 32 bits only. > > */ > > argn = getllval(tcp, &mask, 2); > > +#ifdef HPPA > > + /* Parsic is weird. See arch/parisc/kernel/sys_parisc32.c. */ > > + mask = (mask << 32) | (mask >> 32); > > +#endif > > Really weird. What if they stop using sys_parisc32.c?
then things would go back to the way they were ;). this shim was added in response to what glibc was doing for a long time, so i don't expect them to rebreak the ABI: commit ab8a261ba5e2dd9206da640de5870cc31d568a7c Author: Helge Deller <del...@gmx.de> Date: Thu Jul 10 18:07:17 2014 +0200 parisc: fix fanotify_mark() syscall on 32bit compat kernel On parisc we can not use the existing compat implementation for fanotify_mark() because for the 64bit mask parameter the higher and lower 32bits are ordered differently than what the compat function expects from big endian architectures. Specifically: It finally turned out, that on hppa we end up with different assignments of parameters to kernel arguments depending on if we call the glibc wrapper function int fanotify_mark (int __fanotify_fd, unsigned int __flags, uint64_t __mask, int __dfd, const char *__pathname); or directly calling the syscall manually syscall(__NR_fanotify_mark, ...) Reason is, that the syscall() function is implemented as C-function and because we now have the sysno as first parameter in front of the other parameters the compiler will unexpectedly add an empty paramenter in front of the u64 value to ensure the correct calling alignment for 64bit values. This means, on hppa you can't simply use syscall() to call the kernel fanotify_mark() function directly, but you have to use the glibc function instead. This patch fixes the kernel in the hppa-arch specifc coding to adjust the parameters in a way as if userspace calls the glibc wrapper function fanotify_mark(). > BTW, syscall names defined in linux/hppa/syscallent.h are out of sync with > arch/parisc/include/uapi/asm/unistd.h; this is why stat32-v.test fails > there. And it's not a recent regression, we just didn't tested these > things before. did you want me to go through it ? -mike
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel